三十九类应用的必要信息对照表，落到字段映射和拒供路径｜洹拓科技
一、这张表的正确用法是当字段映射表
《常见类型移动互联网应用程序必要个人信息范围规定》由四部门联合印发，文号是国信办秘字〔2021〕14 号，这份规定已经在施行。它的形式很特别：用一张对照表，逐类列出 39 类常见应用类型的“基本功能服务”与对应的“必要个人信息”范围，并明确不得因用户不同意提供非必要个人信息而拒绝提供基本功能服务。规定的适用范围包括小程序在内，所以判定对象不能只盯着安装包。
“最小必要”这四个字在产品会上经常被讲成态度，但它在实现层只有一个含义：每一个字段都要能回答“用户不给这一条，基本功能是否还能完成”。过去这个问题的答案来自产品同学的判断，评审时没人能反驳也没人能验证；对照表把答案的依据从主观挪到了可核对的位置上。这就是它全部的工程价值，也是为什么不该把它当成一份要背的政策文件，而应当当成一张可以直接映射进数据库的表来用。
同时也要说清这张表没有给什么。逐类条文的原文措辞、违规情形的认定细则与罚则，都不在本次可复核的范围内，本篇不做转述，也不写任何处罚金额。能被踏实使用的，是它的结构、它对必要个人信息的定义边界、它对工具类的处理，以及那句可测试化的禁止。
二、从对照表到内部资产：定位条目、映射字段、标三态
把这张表变成内部资产，动作是三步。第一步定位：按自家应用类型在 39 类里找到对应条目，若一个产品同时具备多种功能，要按实际提供的基本功能去靠，不要挑一个对自己最宽松的类别。第二步映射：把该条目列出的必要信息逐项映射到自家系统的实际字段与存储位置，明确它落在哪张表、哪一列、是否进日志与埋点。第三步标三态：给每一个现存字段打三种状态之一，必要、非必要但提升体验、可删。
三态清单不是一句口号，它要有具体的列才能跑起来。
| 列名 | 填法要求 |
|---|---|
| 字段与来源 | 字段名，以及它由哪个页面、哪个接口或哪个权限写入 |
| 存储位置 | 库表与列、对象存储、客户端本地、日志与埋点，四类分开写 |
| 三态标记 | 必要、非必要但提升体验、可删，三选一 |
| 判定依据 | 对照表条目，或拒绝后仍可用的实测结论，二者至少有一条 |
| 下线批次 | 标为可删的字段，要写明进入哪个版本停用、哪个版本清除历史 |
判定依据那一列是关键。只写“必要”两个字没有意义，必须能指出依据来自对照表的哪一条，或者来自一次真实的拒绝测试。三态标完之后，这张清单要跟着版本走，新字段入库前先登记三态，没登记的字段不允许出现在数据库迁移脚本里，这一条最好由代码评审模板和迁移检查共同兜住。
三、消费侧与供给侧要分开处理
规定里有一个容易被跳过的限定：必要个人信息仅指消费侧用户为使用基本功能所必需的信息，不包含服务供给侧的信息，也就是司机、骑手、商家这一侧。工程上要防止两种相反的误读。
第一种误读是“对照表没管供给侧，所以供给侧随便采”。供给侧的信息量通常比消费侧大得多，涉及身份核验、位置轨迹、排班与调度，还可能牵出劳动关系与服务合同问题，它只是不在这张表的范围里，不在表里不等于已经合规。第二种误读更常见：把消费侧的判定标准直接套到供给侧，一刀砍掉调度确实依赖的字段，导致业务跑不动，然后再以“业务必需”为由把整套采集恢复回去，中间还顺手把消费侧的字段也放了回来。
处置办法是分开建清单、分开找依据。消费侧按对照表逐条映射；供给侧另立一张表，判定依据换成合同履行与劳动服务关系的必要性论证，写明每个字段服务于哪一项具体的派单、结算或安全义务。两张表由不同的人负责复核，评审会上分别过，不要在同一页 PPT 里混着讲，混着讲的结果通常是消费侧的字段被供给侧的复杂度掩护着留下。
四、工具类无须个人信息，先改三处设计
对照表把工具类应用单列出来，明确它们无须个人信息即可使用基本功能服务，被点名的类型包括手电筒、日历、指南针、拍照、浏览器、输入法、扫描件、文件传输、文档处理等。这一条对产品设计的冲击比看上去大，因为它直接让三类常见做法失去依据。
- 首屏注册墙：打开工具就要求登录才能用任何功能。
- 强制手机号登录：把手机号作为唯一入口，不提供其他路径。
- 进入即索要权限：启动流程里一次性申请通讯录、位置、相册等，理由通常是“后面会用到”。
对应的替代做法有三条。本地优先，让核心功能在设备内完成任务，云同步作为可选能力；延迟注册，把创建账号的动作推到用户主动点击云同步、跨端恢复这类真正需要身份的时刻；权限与动作绑定，用户点到哪个功能才申请哪个权限。这三条不只是合规姿态，对工具型产品它还直接影响转化率与卸载率。若业务上确实希望沉淀账号，可保留可选登录，并把游客态数据在注册后无缝迁移当作一项要开发的功能，而不是当成一句提示文案。
五、权限时序三条规则与拒绝分支的回归用例
时序比措辞更容易出问题。三条规则要写成硬约束：权限申请必须与用户的具体动作绑定；拒绝之后必须存在可用的降级路径；不得以循环弹窗施压，同一权限在同一会话内的提示次数要有上限，且用户明确拒绝后不再反复出现。
“不得因拒供非必要信息而拒绝基本功能服务”这句话是可以测试的，测试方法就是真的去拒绝。按下面这张矩阵出一组用例，每个版本跑一遍，结果留进回归清单。
| 用例维度 | 具体做法 |
|---|---|
| 对象 | 逐个非必要字段与逐项非核心权限，不合并测试 |
| 触发时机 | 首次进入、执行相关动作时、执行完毕后再次调用 |
| 拒绝形态 | 拒绝一次、连续拒绝三次、只拒绝其中一项 |
| 身份形态 | 游客态、已登录态、账号注销申请中 |
| 判定标准 | 基本功能能否走通到底，走不通时卡在哪一步 |
| 留证 | 录屏加日志，标注机型与系统版本，随版本归档 |
这里要提醒一句，拒绝分支是最常被漏测的分支。自动化用例一般沿着“允许”这条最顺的路径写，测试同学也习惯在弹窗上点允许，结果拒绝路径只在真实用户身上被第一次走通。把拒绝当作一条真实分支去维护，成本比想象低，收益是上线前就知道流程有没有设计完。如果一组用例跑下来发现某些功能确实走不通，那说明流程还没设计完，而不是用户应该配合。
六、已收集清单、SDK 连带核查与验收材料加一页
告知义务要求把处理规则以简洁清晰的方式呈现给用户，落到工程上就是一份“已收集个人信息清单”。这份清单必须由实际存储与埋点导出，而不是手写在隐私政策里。可行做法是写一个导出任务，从数据库元数据、埋点事件字典与客户端存储三个来源生成同一份结构化清单，随版本更新，标注生成时间与生成方式，再由它转译成用户可读的版本。手工维护的清单一定会和真实系统分叉，分叉之后审核问询与客户安全问卷都会答不上来。
三方 SDK 要连带核查，因为很多问题不是自家代码引入的。核查三点：SDK 采集的字段是否落在必要范围内，能否拿到它的采集清单；能不能关闭或降级，配置项在哪一层生效；告知由谁负责，隐私政策里有没有列明。这三点在选型阶段就问，比集成后再拆便宜得多，判断标准很简单，答不上采集清单的 SDK 不进主干分支。
洹拓在交付材料里固定加一页“字段与必要信息映射表”，把第二节那张三态清单按客户的应用形态裁剪后附在验收文档里。这一页同时回答两类问题：一类是应用审核与安全评估会问的“你为什么需要这个字段”，另一类是客户安全负责人会问的“你们到底存了多少”。最小必要不是一次性的整改，而是字段级的日常治理，能落到清单、时序与用例三处，它才真的被执行。