我只接了 3 个 SDK，为什么隐私政策里要写十几个？
第一次写隐私政策的时候，以为很简单：接了哪几个 SDK，就写哪几个。
后来跑依赖树一看，不对。我直接依赖的只有 3 个 SDK，但这 3 个 SDK 各自又带了好几个二级依赖。加起来，包里有十几个第三方库。
每个第三方库都可能收集数据。隐私政策里要一个一个写清楚。
一、先想清楚：直接依赖和间接依赖
先把最基础的问题想明白。
| 类型 | 说明 |
|---|---|
| 直接依赖 | 你在 oh-package.json5 里写的 |
| 间接依赖 | SDK 带进来的 |
你接了 A SDK，A SDK 又依赖 B SDK。B SDK 就是间接依赖。
二、SDK BOM 清单为什么重要
隐私政策要写清楚：每个 SDK 叫什么、谁提供的、收集什么数据、用来干什么。
这就是 SDK BOM（Bill of Materials）清单。
| SDK | 提供方 | 版本 | 收集数据 | 用途 |
|---|---|---|---|---|
| 统计 SDK | 公司A | 1.0.0 | 设备信息、使用时长 | 数据分析 |
| 认证 SDK | 公司B | 2.1.0 | 账号信息 | 登录 |
| 云存储 SDK | 公司C | 1.2.0 | 文件、Token | 文件存储 |
这段代码解决什么问题：依赖树分析。
文件：oh-package.json5
用途：第三方依赖管理
接入位置：项目配置
{ "dependencies": { "stats_sdk": "1.0.0", "auth_sdk": "2.1.0", "cloud_sdk": "1.2.0" } }跑一下依赖分析：ohpm list --all，就能看到所有直接和间接依赖。
三、升级 SDK 为什么要更新隐私政策
很多人升级 SDK 版本，只改个版本号，不更新隐私政策。
不对。SDK 升级了，收集的数据可能变了。隐私政策也要跟着更新。
| 操作 | 问题 |
|---|---|
| 升级 SDK 不改隐私政策 | 隐私政策过时了 |
| 删功能但留旧依赖 | 包里还带着旧 SDK |
| SDK 权限和 App 权限两套维护 | 对不上 |
四、几个容易踩的坑
第一个坑：只登记自己主动接入的 SDK。间接依赖的 SDK 没管。
第二个坑：忽略 SDK 带进来的二级依赖。跑个依赖树才发现多了一堆。
第三个坑：升级 SDK 后隐私政策没更新。收集的数据变了，政策还是旧的。
第四个坑：删除功能但包仍残留旧依赖。包里还带着不用的 SDK。
第五个坑：SDK 权限和 App 权限清单两套维护。对不上。
第六个坑：README 写了收集信息但隐私政策没写。开发者文档和隐私政策不一致。
这次做依赖治理最大的体会是：合规不是只管自己的代码，还要管所有进包的第三方。
真正做的时候，最容易忽略的不是自己接了几个 SDK，而是这些 SDK 又带了多少东西进来。依赖树一展开，才知道真正要管的是一整张图。
