“毛片未成年人保护”的开发重点，不是增加一个“我已满18岁”弹窗，而是建立从年龄核验、访问决策、内容审核到举报处置的完整接口链路。对于涉及成人内容的服务，未完成有效年龄核验时应默认拒绝访问；疑似未成年人参与、年龄无法确认或存在绕过迹象的内容，应进入隔离和人工复核流程，不能直接上线。
先确定保护链路和接口边界
建议把系统拆成四个相互独立的模块：年龄核验服务、策略决策服务、媒体访问网关、内容安全与举报服务。年龄核验服务只负责产生核验状态，策略服务根据地区、内容类型和账号状态作出允许或拒绝决定，媒体网关负责阻断未授权的播放和下载，内容安全服务负责上传审核、举报、下架和审计。
接口不要把身份证号码、完整出生日期或第三方核验原始材料传给播放器。播放器只需要获得短期有效的年龄状态令牌，例如“已核验成人”“未核验”“未成年人”“核验过期”或“人工复核中”。这样可以减少敏感数据在前端、CDN和业务服务之间流转。
| 状态 | 访问结果 | 说明 |
|---|---|---|
| UNVERIFIED | 拒绝 | 尚未完成有效核验 |
| VERIFIED_ADULT | 按策略允许 | 已完成适用于当前地区的成人核验 |
| VERIFIED_MINOR | 拒绝 | 确认属于未成年人 |
| EXPIRED | 拒绝 | 核验凭证超过有效期 |
| REVIEW | 拒绝或限制 | 存在年龄、身份或内容方面的不确定性 |
第一步：搭建年龄核验接口
可以先设计内部接口 POST /v1/age-assurance/sessions，用于创建一次核验会话。请求至少应包含账号标识、服务地区、核验用途和幂等键，不建议直接提交完整身份证件资料。服务端返回会话编号、核验方式、当前状态、过期时间和一次性令牌。
核验服务完成后，通过受保护的服务端回调提交结果，或由业务服务调用 GET /v1/age-assurance/sessions/{session_id} 查询状态。回调必须验证签名、时间戳和一次性事件编号，重复回调不能重复改变账号状态。
接口返回的数据应类似于：状态为 VERIFIED_ADULT、核验等级为指定等级、有效期到某个时间点，并附带唯一 trace_id。这里的核验等级必须由实际接入的合规服务定义，不能在自建接口中虚构“已通过权威认证”等能力。如果接入方只提供年龄估计，就应明确记录为年龄估计结果，不能包装成身份证明。
单纯的出生日期填写、前端勾选和支付方式判断都不适合作为唯一的年龄证明。年龄估计可以作为辅助信号，但当结果接近阈值、图像质量不足或用户提出异议时，应转入合法、透明的替代核验流程。不同地区对年龄核验、个人信息保存和未成年人服务限制的要求可能不同，策略服务应支持按地区配置，而不是把一套规则硬编码到所有用户。
第二步：让策略接口决定是否可以访问
不要让前端自行判断“已成年”后直接播放。每次播放、下载或获取原始媒体地址前，都应由服务端调用策略接口，例如 POST /v1/access/decisions。请求包括账号状态、媒体内容等级、地区、设备会话和资源动作；响应只返回允许、拒绝或复核中，以及短期有效的原因码和 trace_id。
策略规则可以采用以下优先级：确认未成年人时拒绝；年龄状态缺失、过期或无法验证时拒绝；媒体尚未完成安全审核时拒绝；账号、设备或内容触发人工复核时限制访问；只有在年龄状态、地区策略和媒体状态同时满足条件时，才返回允许。
媒体网关收到允许结果后，再签发短时效播放令牌。视频分片、原始文件和下载接口都必须验证该令牌，不能只保护页面入口。CDN源站应关闭公开访问，播放地址应绑定资源编号、账号会话和过期时间。否则用户即使无法打开页面，也可能通过历史地址、源站地址或直接下载接口绕过保护。
客户端收到拒绝结果时，只显示必要的提示，例如“当前无法访问，请完成适用的年龄核验”。不要把内部风控规则、模型分数、其他用户信息或详细拦截条件返回给客户端，避免泄露可被反复试探的决策逻辑。
第三步：为上传和存量内容增加未成年人拦截
年龄保护不能只控制观看者，也要控制内容进入系统的路径。上传接口可设计为 POST /v1/content-screening/jobs，接收资源编号、文件哈希、媒体类型、上传者账号和来源信息，返回 PENDING、PASS、QUARANTINE 或 BLOCK。
审核流程至少应包含文件哈希比对、重复内容识别、图像和视频抽帧、文本与字幕检测、账号行为信号以及人工复核。模型只能用于分流和排序，不能把“看起来像成年人”当作最终结论。涉及未成年人、年龄明显无法确认或存在强烈疑点的内容，应直接隔离，不得进入公开索引、推荐、播放或下载链路。
对于已确认的违法或严重危害未成年人安全的内容，应按照适用法律和平台内部流程执行下架、证据保全、账号处置及必要报告。原始材料应限制访问并加密保存，测试环境使用合成样本和安全测试数据，不能把真实违法材料复制到开发、演示或日志系统中。
第四步：把举报和处置做成可追踪接口
举报接口可采用 POST /v1/safety-reports，字段包括资源编号、举报类型、补充说明、提交者会话和幂等键。举报类型至少应区分“疑似未成年人”“年龄无法确认”“未经同意传播”“身份信息暴露”和“绕过年龄限制”。接口返回工单编号和当前状态，不应向举报人泄露被举报者的个人资料。
内部处置接口可以记录隔离、下架、限制传播、恢复、升级复核等动作。每个动作都应带有操作者或服务身份、规则版本、时间、资源编号和前后状态。资源删除并不等于日志删除，审计记录应保留必要的处理链路，但避免保存超出目的所需的原始个人信息。
对举报、核验回调和审核结果使用幂等键，避免网络重试造成重复工单或重复下架。所有管理接口还应使用细粒度权限控制，普通业务服务不能直接修改年龄核验结果，内容审核人员也不应默认看到完整身份材料。
部署后的验证重点
上线前应使用自动化测试覆盖关键路径：未核验账号请求播放时必须拒绝；确认未成年人时必须拒绝；核验过期后不能继续使用旧令牌；成人核验通过后只能访问允许的内容等级；直接访问CDN源站必须失败；回调重放必须失败；审核状态为隔离时不能生成播放地址；举报重复提交只能产生一个有效工单。
监控指标应围绕实际保护结果设置，包括年龄核验成功率、过期令牌拒绝率、媒体绕过访问次数、隔离内容处理时长、举报响应时长、人工复核改判率和接口异常率。发现某个设备、账号或接口持续尝试绕过年龄决策时，应提高限制等级，但不要仅凭单一设备信号永久认定用户身份。
最终可验证的结果应是：未完成有效核验的访问请求在策略层被拒绝，已确认涉及未成年人的内容在发布前被隔离，播放和下载不存在未授权直链，举报能够生成可追踪工单，年龄状态和内容处置均能通过审计日志复盘。这样的接口设计，才是“毛片未成年人保护”从页面提示落到实际系统控制的实现路径。
