打开一个新下载的 App，不少用户都遇到过类似的场景：首启弹窗很长、勾选框默认全选，使用一个资讯浏览功能却被申请通讯录、位置、相机等一串权限。这些做法是否合规，核心标尺就是“最小必要”。本文把这条原则拆成可以逐项核对的维度，帮助企业自查 App 的收集行为是否越界。

一、“必要”怎么判断：三个可核对的维度

“必要”不是抽象概念，实务中可以从三个维度逐项核对。

• 功能绑定：收集的每类信息、申请的每个权限，都要能对应到用户正在使用的具体功能。扫码才需要相机，发送位置消息才需要定位权限；用户只是浏览资讯内容时，这两项权限都谈不上“直接相关”。
• 频次与强度：即使是必要权限，也存在收集频次与强度的问题。前台按需读取与后台静默高频采集，对个人权益的影响完全不同。能在使用时点实时处理、不留存原始数据的，就尽量不要落库留存。
• 替代方案：存在对个人权益影响更小的实现方式时，应当优先选择。例如为完成“识别设备异常”，使用随机化设备标识与指纹哈希，比明文收集完整设备清单影响更小。

二、高频争议场景自查

• 一揽子同意：隐私政策默认勾选、“不同意即不能用”，实质是剥夺了用户的选择权。同意应当由用户在充分知情的前提下自愿、明确作出。
• 超范围收集：申请的权限与当前页面功能无对应关系，或者隐私政策未逐一列明权限与功能的对应关系，都属于典型的“超出最小范围”。
• 捆绑下载：安装即申请全部权限，而不是在触发对应功能时逐项申请。
• 剪贴板与本地读取：频繁读取剪贴板、通讯录等与业务功能无关的本地数据，是检测评估中反复出现的重点问题。
• 拒绝授权即拒绝服务：用户拒绝非必要权限后，基础功能仍应可以使用。

三、落地清单：把“最小必要”做成动作

建议按以下清单逐项落地，并形成留痕：

• 权限—功能对应表：逐页面、逐功能梳理申请的权限，写明对应业务目的；表中没有对应关系的权限，一律下线或改为使用时申请。
• 弹窗分层设计：首启弹窗以简明语言说明核心处理活动，完整政策分层呈现；不设默认勾选，提供“同意”与“不同意（仅基础功能）”两条路径。
• 同意留痕：记录同意的时间、版本号与范围，便于事后证明告知的充分性。
• 版本升级重告知：新增处理目的、新增 SDK 或扩大收集范围的版本，触发重新告知与重新同意。
• 撤回与注销渠道：提供便捷的撤回同意、关闭个性化推荐与账号注销入口，并保证注销后按约定删除或匿名化处理。