要实现“毛片未成年人保护”，不能只在页面增加一个年龄提示，也不能只依赖内容审核接口。可落地的方案应把内容识别、年龄核验、访问决策、媒体地址签发和审计记录连成一条链：内容进入系统时先完成分级，用户请求播放时再核验年龄，决策接口统一返回允许、拦截、二次核验或人工复核，未满足条件时不签发可播放的媒体地址。

下面给出一套可由开发团队自行实现的接口契约。文中的接口路径和字段是内部系统示例，不代表任何第三方服务已经提供这些能力。实际接入外部年龄核验或内容识别服务时，应以对方正式文档、适用地区规则和数据处理协议为准。

如何搭建毛片未成年人保护的基础链路？

建议先拆成五个模块，而不是让前端直接决定是否展示内容。

1. 内容分级模块：在上传、转码或发布前识别成人内容、疑似未成年人相关内容、未知内容和普通内容。
2. 年龄核验模块：只向符合条件的用户发放短期有效的核验凭证，不让客户端自行提交一个布尔值就获得权限。
3. 统一决策模块：根据用户状态、内容标签、地区、账号状态和平台策略返回最终动作。
4. 媒体访问模块：只有决策结果为允许时，才生成短时效播放地址或下载地址。
5. 审计与监控模块：记录策略版本、决策结果、失败原因和追踪编号，便于定位放行或拦截错误。

完整链路可以表达为：内容标签缺失或属于高风险类别 → 内容进入隔离区并禁止公开 → 审核或分类完成后再进入决策接口；用户未完成年龄核验 → 决策接口返回拒绝或核验要求 → 媒体服务不签发播放地址。这样，即使前端被修改，用户也无法仅靠改页面状态访问受保护资源。

先明确哪些内容必须拦截，接口判断才会稳定吗？

是的。年龄保护接口依赖稳定的内容标签。如果所有内容只使用“成人”或“非成人”两个值，系统很难处理未知内容、人工复核和疑似涉及未成年人的特殊情况。建议建立至少四类内部标签：

内容标签不能由浏览器传入后直接信任。发布服务应在服务端保存标签来源、模型或规则版本、审核状态和更新时间。例如，内容记录至少应包含 content_id、classification、review_status、policy_version 和 updated_at。当标签从 adult_restricted 变为 minor_related 时，系统应撤销已有播放地址，并让缓存立即失效。

如果识别结果涉及未成年人性化或疑似违法内容，不应继续尝试播放、转码或推荐。应将原始文件和衍生文件隔离，限制访问权限，并按照适用法律、平台应急流程和合规要求处理。普通年龄核验接口不能替代这类内容处置流程。

年龄核验完成后，访问请求应如何进入决策接口？

不要让前端调用“是否成年”的简单接口后自行判断。更稳妥的做法是由后端建立统一决策接口，例如内部使用 POST /internal/safety/decision。该路径只是示例，重点是固定请求字段和响应语义。

age_assurance 不建议只设置 is_adult=true。至少应区分 verified、unverified、expired、rejected 和 unavailable。系统还应保存核验凭证的签发时间、过期时间、签发系统和策略版本，但尽量不在普通业务日志中保存原始证件、完整人脸图像或不必要的身份信息。

接口返回什么，前端和媒体服务才不会各自放行？

决策接口应返回明确且有限的动作集合，避免前端根据模糊文案自行推断。可以使用以下响应契约：

处理逻辑应保持单向：决策结果为 allow → 后端再次确认内容状态 → 生成短时效、绑定用户和内容的媒体地址 → 播放服务验证地址后返回数据。如果决策结果为 deny，响应中不应包含原始媒体地址、备用地址或可猜测的存储路径；如果结果为 age_gate，只返回核验流程所需的信息；如果结果为 review，内容应停留在隔离状态，不能由前端把它当作允许访问。

播放地址最好绑定 subject_token、content_id、过期时间和策略版本，并设置较短有效期。CDN 或对象存储收到请求时，应验证签名和绑定关系。仅隐藏按钮、模糊封面或在前端弹窗提示，不能构成有效的未成年人保护控制。

如果核验失败或接口不可用，系统应怎样处理？

对于成人限制内容，保护策略应采用默认拒绝，而不是接口超时后继续放行。可以按以下方式处理：

• 用户未核验：返回 age_gate，不签发媒体地址。
• 核验凭证过期：返回 age_gate，要求重新完成当前允许的核验流程。
• 核验结果被拒绝：返回 deny，记录原因码，但不向客户端披露过多内部判断细节。
• 内容标签缺失：按 unknown 处理，禁止公开并转入重新分类或人工复核。
• 决策服务超时：对成人限制内容返回保护性失败，不使用长期缓存的旧允许结果。
• 内容被重新标记为高风险：撤销签名地址、清理相关缓存，并阻止后续请求。

缓存是容易被忽略的失败点。允许结果的缓存键不能只使用 content_id，至少要包含用户主体、地区、策略版本和内容状态。否则，一个已经核验的用户得到的允许结果可能被错误复用于未核验用户。拒绝结果也应设置合理的短期缓存，避免用户不断重复请求接口造成压力。

部署后怎样验证毛片未成年人保护链路没有失效？

上线前应使用测试账号、测试内容和独立环境逐项验证，不要只测试正常播放。每个用例都应记录请求编号、预期决策、实际决策、是否签发媒体地址以及审计记录是否完整。

1. 未核验账号访问成人限制内容：预期返回 age_gate 或 deny，响应中没有播放地址。
2. 核验凭证已过期：预期不能沿用旧的允许状态，系统应要求重新核验。
3. 内容标签为 unknown：预期进入隔离或复核，不得直接公开。
4. 内容标签为 minor_related：预期立即拦截，推荐、搜索、播放和下载接口均不能返回该内容。
5. 已核验用户访问允许内容：预期只获得绑定用户和内容的短时效地址，地址过期后不能继续使用。
6. 决策接口超时：预期成人限制内容保持拒绝，不因故障自动放行。
7. 修改浏览器字段：将客户端的年龄字段改为成年，预期服务端仍依据自己的核验凭证判断。
8. 策略版本更新：预期旧缓存和旧签名地址按照设定规则失效，新的请求使用新策略。

监控指标至少包括成人内容请求量、未核验拦截率、年龄核验成功率、未知标签占比、决策接口超时率、播放地址签发量、撤销量和人工复核积压量。如果“allow”数量突然上升，而核验成功率没有同步变化，应立即检查缓存键、鉴权中间件和内容标签同步任务。

最终验收标准不是页面是否出现“仅限成年人”的提示，而是：未完成核验的用户拿不到受保护媒体地址，疑似涉及未成年人的内容无法进入公开链路，接口返回能够被各服务一致解释，失败时系统默认保护，并且每次关键决策都能通过审计编号追溯。这样搭建的毛片未成年人保护机制，才具备可部署、可验证和可持续维护的基础。