升级前的依赖审计：找到隐藏在版本树里的变化
一次看似简单的开源库升级，常会引入多层传递依赖变化。直接依赖只是一棵树的入口，真正运行的还包括解析器选择出的间接包、镜像中的系统库、插件及运行时模块。依赖审计的目标不是追求零变化，而是确认每项变化都可追溯、可解释、可测试。不同生态使用的锁定机制和解析规则会变化，执行时应查阅所用工具的当前说明。
从已部署构件反向盘点
不要只看声明文件。先收集实际构建产物中的包清单、容器层信息或运行时模块列表，再与源代码中的声明和锁定结果比较。若三者不一致，应先解释差异：可能是缓存、手工安装、构建脚本条件分支，或不同平台解析结果。只有确定基线，后续差异才有意义。盘点时也要记录构建命令和环境版本，避免以后无法重现。
识别传递依赖的关键性
传递依赖不应因为“不直接调用”就被忽略。可按是否参与网络通信、数据解析、身份校验、压缩处理、编译工具链或关键启动路径来排序。对于高影响组件，阅读其版本说明并检查上游为何提升它。若上游只给出宽泛约束，构建时可能选到与本地不同的版本，因此需要在隔离环境验证解析结果，而不是依赖口头判断。
检查重复与冲突版本
同一功能库的多个版本同时存在，未必马上出错，但会增加行为不一致、体积膨胀和排查难度。应查看工具提供的依赖树或运行装载信息，判断重复版本是否处在不同隔离边界，是否会被同一进程加载。解决冲突时不要盲目强制提升最低版本；先确认所有上游组件是否支持该组合，再通过构建和功能测试验证。
将许可证以外的元数据也纳入检查
包来源、校验值、构建时间、平台架构和发布者签名状态等元数据，有助于发现构件与预期不一致。这里的重点是核对一致性，不是凭名称推断可信程度。若某个构件无法在项目发布记录中找到对应关系，应暂停扩大部署，先确认它来自哪条构建链路。对容器而言，标签可能会移动，因此更应保存本次实际使用的不可变标识。
产出一份可供决策的差异摘要
最终摘要可按新增、移除、升级、降级、版本不明和待验证分类，并标出影响路径。它应让同事无需重新解析整棵依赖树就能理解本次升级范围。审计并不能证明一切正确，但能显著降低“未意识到发生变化”的概率。