要实现“毛片未成年人保护”，不能只在页面增加一个“我已满18岁”按钮。较可靠的做法是把保护拆成四个可验证环节：内容入库审核、用户年龄与资格判断、播放授权、举报与审计。任何一环返回“未知、失败或存在未成年人线索”，系统都不应继续提供公开访问，而应转入拒绝或人工复核流程。下文给出一套可落地的内部接口契约，适用于提供合法成人内容的内容平台；涉及未成年人的性剥削内容必须拦截、下架并依运营地法律和平台流程处理。
先确定保护模型：内容状态和访问状态分开管理
开发时不要把“视频已审核”和“用户已成年”合并成一个布尔值。前者描述内容能否被平台分发，后者描述当前用户是否有权访问，两者缺一不可。建议使用独立状态，并由服务端生成最终访问决策。
| 对象 | 建议状态 | 处理含义 |
|---|---|---|
| 内容审核 | pending、approved、rejected、quarantined | 待审、允许分发、拒绝分发、隔离调查 |
| 用户年龄 | unknown、minor、adult、verification_failed | 未知、确认未成年、完成成年验证、验证失败 |
| 访问决策 | allow、deny、review | 允许、拒绝、要求进一步处理 |
| 依据版本 | policy_version | 记录作出决策时使用的规则版本，便于复盘 |
内容状态应由审核服务维护，年龄状态应由账户或资格服务维护，播放服务只接受最终授权结果。这样即使前端被修改，用户也无法绕过服务端判断直接取得视频地址。
如果平台允许上传或编辑内容：先做入库拦截，再生成播放资格
上传型平台的主要问题不是“播放页怎么遮挡”，而是未经审核的文件可能已经被公开访问。上传完成后，文件应先进入私有存储和审核队列，不得直接生成公开链接、缩略图或搜索索引。
- 上传接口只返回内部的 asset_id 和审核任务编号，不返回可长期访问的媒体地址。
- 审核前禁止出现在推荐、搜索、评论、分享和播放列表中。
- 审核服务至少检查内容分类、年龄相关线索、重复文件指纹、上传者声明和必要的人工复核结果。
- 无法判断或检测结果冲突时，状态保持为 pending 或 quarantined，不应按“暂时放行”处理。
- 只有 approved 内容才允许由播放服务签发短时效、绑定用户的播放凭证。
下面是一个推荐的内部接口示例。它是平台自定义的契约，不代表某个现成第三方接口已经提供这些能力。
| 项目 | 约定 |
|---|---|
| 请求 | POST /v1/moderation/jobs |
| 必要字段 | asset_id、uploader_id、media_sha256、declared_category、policy_version |
| 响应字段 | job_id、status、decision、reason_codes、next_action |
| 状态约束 | pending 不能播放；approved 才能进入授权判断；rejected 和 quarantined 不得公开 |
| 幂等规则 | 相同 asset_id 和规则版本重复提交时返回同一审核任务，避免重复入队 |
审核回调也应由服务端验证签名，并检查 job_id、asset_id、结果版本和时间戳。不能仅因为客户端传来“审核通过”字段，就将内容状态改为 approved。审核结果还应保留最小必要的 reason_codes，例如“年龄线索不明确”“资料不完整”或“规则命中”，避免在普通业务日志中保存敏感媒体细节。
如果平台只分发已审核内容：重点放在年龄资格和播放授权
分发型平台没有上传审核压力，但仍然不能把“视频已审核”当作“所有用户都能看”。访问判断应发生在播放凭证签发之前，而不是视频已经开始传输之后。页面可以展示标题和必要的合规提示，但受限媒体的真实地址、密钥或完整封面不应提前下发。
- 用户未登录、年龄状态 unknown 或 verification_failed 时，返回 deny 或 verification_required。
- 账户已完成成年资格确认时，还要检查地区、内容分级、账户状态和平台策略。
- 未成年人账户不能通过修改前端参数、切换设备或伪造年龄字段获得播放凭证。
- 访问资格发生变化后，已签发的凭证应能被撤销或在较短时间内失效。
- 缓存键必须区分用户资格，不能让已授权用户的响应被未授权用户复用。
播放前可以设计如下内部决策接口：
| 项目 | 约定 |
|---|---|
| 请求 | POST /v1/access/check |
| 输入 | user_id、asset_id、region、client_context、policy_version |
| 允许响应 | decision=allow、playback_token、expires_at、policy_version |
| 拒绝响应 | decision=deny、reason_code、recheckable |
| 异常响应 | decision=review 或 verification_required，不返回媒体地址 |
播放服务应把访问接口视为唯一授权来源。前端只能根据 decision 展示界面，不能自行推导“没有 reason_code 就代表允许”。当年龄服务暂时不可用时，默认应是拒绝或暂停授权，而不是为了可用性自动放行。
检测到未成年人线索或结果不确定时：隔离优先于解释
这是实现中最需要明确的分支。只要内容中出现未成年人相关线索、年龄无法确认、授权材料缺失，或自动审核与人工审核结论不一致，就应进入 quarantined 或 review 状态。此时系统的目标不是继续优化推荐，而是阻断传播并保留合规处理所需的最小审计记录。
- 立即撤销已有播放凭证，停止推荐、搜索曝光和分享传播。
- 限制原始文件、审核记录和举报资料的访问范围，只允许授权的合规与调查人员访问。
- 记录事件编号、状态变更时间、规则版本、操作者和系统决策，不在普通日志中写入敏感内容。
- 根据运营地法律、执法协作要求和平台内部流程进行报告、保存或删除，不由前端开发人员自行判断法律结论。
- 对举报人只返回“已收到并处理中”等最小信息，避免泄露受影响对象或调查细节。
这里不应设置“审核超时自动通过”的降级策略。自动分类器只能作为筛查或排序工具，不能替代必要的人工复核和法律流程；年龄识别模型也不应作为唯一放行依据，尤其不应把单次图像年龄估计当成确定的成年证明。
接口契约中必须固定的安全边界
为了让客户端、审核服务、账户服务和播放服务保持一致，建议统一以下字段和规则：
- decision 只允许预先定义的枚举值，禁止用任意字符串表达授权结果。
- reason_code 使用不暴露敏感细节的代码，例如 AGE_UNKNOWN、CONTENT_REVIEW、POLICY_BLOCK。
- request_id 和 trace_id 必须贯穿上传、审核、授权和播放日志，便于定位绕过路径。
- expires_at 由服务端生成，播放凭证设置合理的短时效，并支持主动撤销。
- 错误响应不能泄露“内容是否真实存在”或审核模型的详细规则，避免被反复试探。
- 身份信息、证件信息和年龄证明只保留完成决策所需的最小结果；原始材料的保存期限、加密和访问权限应单独制定。
若使用事件通知，可定义 content.reviewed、user.age_status_changed 和 access.revoked 等内部事件。事件消费者必须支持重复投递、乱序到达和重试，不能因为一次旧事件就把 quarantined 内容恢复为 approved。
从开发到部署的验证顺序
- 先建立状态机和数据表约束，确认哪些状态可以互相转换，尤其禁止 pending 直接变成可播放。
- 再实现审核任务接口和年龄资格接口，使用固定测试数据验证 allow、deny、review、超时和服务不可用场景。
- 接入私有存储、短时效播放凭证和撤销机制，确认前端、CDN 缓存及下载接口都不能绕过 access/check。
- 增加审计、告警和人工复核队列，重点监控异常放行、重复举报、授权失败率和状态回退。
- 上线前进行权限测试：未登录用户、未成年账户、年龄未知账户、被封禁账户和已撤销资格账户都应无法取得媒体凭证。
最终链路可以简化为：文件或内容先进入私有区，审核服务给出内容状态；用户请求播放时，账户服务提供年龄资格；授权服务同时检查内容状态和用户状态；只有两者均满足策略要求，播放服务才签发短期凭证。这样的搭建方式，才能把“毛片未成年人保护”落实为可测试、可审计、可撤销的接口行为，而不是停留在页面提示或用户自我声明上。
