登录、支付、推送、地图、统计和崩溃收集，让移动应用很难完全不依赖第三方 SDK。
问题在于，SDK 由开发集成，隐私政策常由产品或法务维护。如果双方没有共享清单，代码已经升级，披露内容仍停留在旧版本。
SDK 清单至少记录六项
| 字段 | 说明 |
|---|---|
| SDK 名称 | 可识别的正式名称 |
| 版本 | 判断行为是否变化 |
| 使用目的 | 为什么接入 |
| 收集数据 | 设备、网络或用户信息 |
| 触发时机 | 启动、登录或特定功能 |
| 官方说明 | 便于核对规则 |
只写“用于改善体验”无法解释具体数据用途。
从代码而不是记忆出发
统计时应同时检查：
- 依赖配置文件；
- 原生工程；
- 跨平台插件；
- 已移除但仍残留的库；
- SDK 间接引入的依赖；
- 正式包与测试包差异。
产品经理的记忆只能说明“计划使用什么”，安装包才能说明“实际包含什么”。
版本升级需要触发复核
SDK 更新后，权限、数据字段和初始化时机都可能变化。建议把“隐私复核”加入依赖升级流程：
升级 SDK
→ 阅读变更说明
→ 检查新增权限
→ 更新内部清单
→ 评估隐私政策
→ 重新测试授权流程
预审能发现什么
发版前可以将安装包权限、隐私政策与 SDK 清单交叉核对。初雪云提供的 App 预审服务可以作为额外检查环节，帮助发现常见的披露不一致，但最终内容必须以应用真实代码和 SDK 官方说明为依据。
不要忽略初始化时机
如果用户尚未同意隐私政策，某些 SDK 已经开始读取设备信息，即使政策文本写得完整，实际行为仍然可能不一致。
测试时要从全新安装状态观察网络请求和权限触发，而不是只检查设置页面。
明确谁来维护清单
建议由技术负责人维护依赖来源和版本，产品或合规人员补充使用目的与对外披露。每次合并新增 SDK 的代码时，都要在同一任务中更新清单。
删除 SDK 也要留下记录。先确认代码、资源和配置确实移除，再从隐私政策中调整对应内容，避免“文档先删了，安装包里仍然存在”。
对于多个 App 共用的 SDK，可以建立公司级基础清单，再由各项目标记实际启用项，减少重复整理。
总结
SDK 清单不是一次性提交材料，而是一份需要随代码维护的技术资产。
让依赖升级自动触发隐私复核，并让开发、产品和合规共用同一份记录，才能减少“政策写了，但程序不是这样运行”的风险。
