我只接了 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 又带了多少东西进来。依赖树一展开，才知道真正要管的是一整张图。