1、依赖检查总览：为什么SDK发布前必须做依赖检查？
说实话，我见过太多SDK发布后出问题的案例了。十有八九，根因都出在依赖上。
你想想看，一个SDK少则依赖十几个包，多则上百个。每个包又有自己的版本号、传递依赖、兼容性边界。只要有一条依赖链断了，用户集成时就会报错。轻则编译失败，重则运行时崩溃。
我个人习惯，在每次SDK正式发布前，都会专门留出半天时间做依赖检查。这不是走形式，是真的能救命。
为什么依赖检查这么重要？
我举三个真实场景，你就明白了：
- 场景一：版本冲突 —— 你的SDK依赖了A库的v2.0，但用户的工程里已经用了A库的v1.8。两个版本不兼容，用户一编译就报符号重复。这种问题排查起来特别痛苦，用户往往第一反应是「你们的SDK有问题」。
- 场景二：传递依赖污染 —— 你的SDK依赖了B库，B库又依赖了C库的v3.0。但你的SDK里也直接引用了C库的v2.5。构建工具可能会把两个版本都拉进来，运行时到底用哪个？看运气。我在项目中遇到过，线上偶发崩溃查了两周，最后发现是传递依赖版本打架。
- 场景三：安全漏洞 —— 你的SDK依赖了一个老版本的日志库，这个库有个已知的远程代码执行漏洞。用户的安全扫描工具一跑就报警，直接导致集成被驳回。嗯，这种问题最冤，明明不是你写的代码，锅却要你来背。
一句话总结：依赖检查不是「锦上添花」，而是「生死线」。不做依赖检查的SDK发布，就像没系安全带就上路。
依赖检查的核心目标
说白了，依赖检查就三个目标：
- 兼容性 —— 确保SDK的所有依赖，在目标用户的开发环境中能正常工作。不冲突、不缺失、不重复。
- 安全性 —— 确保没有引入已知的CVE漏洞。每个依赖包都要过一遍安全扫描。
- 可追溯性 —— 确保每个依赖的版本、来源、许可证都清晰可查。出了问题能快速定位。
我的小技巧：每次发布前，我会把依赖树完整导出一份，存到发布包的docs目录里。这样用户遇到问题，可以直接对照依赖树排查。这个习惯帮我省了不少沟通成本。
依赖检查的范围
依赖检查到底要查哪些东西？我一般分成四个维度：
| 检查维度 | 检查内容 | 常见问题 |
|---|---|---|
| 直接依赖 | SDK代码中直接import/require的包 | 版本过低、已废弃、许可证不兼容 |
| 传递依赖 | 直接依赖所依赖的包（递归） | 版本冲突、重复引入、漏洞传递 |
| 系统依赖 | 操作系统级别的库、工具链、运行时 | 平台不兼容、版本不匹配 |
| 构建依赖 | 构建工具、插件、脚本 | 版本不一致导致构建结果不同 |
你可能会问：「传递依赖也要管？那得查到猴年马月？」
嗯，这里要注意。传递依赖确实查起来很繁琐，但恰恰是问题最多的地方。我曾经遇到过一个案例：SDK只依赖了5个直接包，但传递依赖展开后竟然有47个包。其中有一个日志库的传递依赖版本和用户工程冲突，导致用户每次启动App都会多打印一行警告日志。虽然不影响功能，但用户觉得「不干净」，最后还是换掉了我们的SDK。
警告：千万不要只检查直接依赖就完事。传递依赖才是真正的「暗坑」。建议使用依赖分析工具（如npm ls、mvn dependency:tree、gradle dependencies等）把整棵依赖树拉出来看一遍。
依赖检查的知识体系
为了让你更直观地理解依赖检查的全貌，我画了一张图：
什么时候做依赖检查？
我个人建议，依赖检查应该嵌入到发布流程的固定环节里：
- 每次发布前 —— 这是底线。不管是大版本还是小补丁，发布前必须过一遍依赖检查。
- 依赖变更后 —— 新增、升级、移除任何依赖后，立即做一次检查。
- 定期扫描 —— 即使没有变更，也建议每月跑一次安全扫描。新的CVE漏洞每天都在出现。
我的习惯：我会在CI/CD流水线里加一个「依赖检查」的stage。每次提交代码到release分支，自动触发检查。检查不通过，直接阻断发布。这样就不会出现「忘了检查」的情况了。
依赖检查的常见误区
最后，我列几个常见的误区，你看看自己有没有踩过：
- 误区一：只检查直接依赖 —— 传递依赖才是真正的「暗坑」，一定要展开看。
- 误区二：依赖锁定就万事大吉 —— 锁定文件只能保证构建可复现，不能保证没有漏洞和冲突。
- 误区三：依赖检查是测试团队的事 —— 依赖检查应该是开发者的责任。测试团队可以辅助，但不能替代。
- 误区四：用最新版本就一定安全 —— 最新版本可能引入新的API变更，反而导致兼容性问题。我建议用经过验证的稳定版本。
好了，这一章的内容就到这里。依赖检查这件事，说难不难，说简单也不简单。关键在于养成习惯，把它变成发布流程里不可跳过的一环。