依赖变更怎么审
依赖改动影响面常被低估：它带进的是别人的代码、别人的缺陷与别人的许可证。评审要点是必要性（既有依赖能否覆盖）、引入类型（运行时还是构建期）、版本与锁文件的变更是否可控、许可证是否与项目兼容，以及该依赖的维护状态与已知漏洞。
基本信息
| 必要性 | 既有依赖能否覆盖需求；引入的是运行时还是构建期依赖 |
|---|---|
| 版本与锁 | 变更是否按预期，避免无关升级混入同一个改动 |
| 许可证 | 与项目许可证的兼容性，小心传染性许可 |
| 维护与安全 | 是否活跃维护、有无已知漏洞公告 |
逐项看什么
- 新增依赖的必要性：功能是否可以用标准库或既有依赖实现。
- 传递依赖数量与体积：一个库可能顺带引入几十个间接依赖。
- 锁文件 diff：确认本次变更只包含目标依赖，没有顺带升级。
- 许可证类型：是否与项目分发方式冲突，是否需要保留声明文件。
- 维护状态：最近提交时间、未处理问题数量、是否有替代方案。
风险与检查点
| 风险 | 检查点 |
|---|---|
| 供应链 | 来源是否可信，是否锁定版本与校验值 |
| 许可证 | 与项目许可是否兼容，是否要求开源衍生代码 |
| 体积与性能 | 运行时开销、包体积、启动时间影响 |
| 维护停滞 | 长期无人维护的库出现漏洞时无人修复 |
| 锁文件噪声 | 无关升级混入，出问题难以二分定位 |
审查依赖改动的切入点
审查依赖改动的切入点
git diff -- package.json package-lock.json # 只看依赖清单与锁文件
git diff --stat -- '*lock*' # 先看锁文件规模是否异常
# 关注：新增/删除项、版本跨度、是否顺带升级了无关依赖
# 再确认：许可证文件与声明是否需要同步更新锁文件的大规模无关变更会掩盖真实改动：应要求单独提交或给出说明。
引入新依赖前先问一句「这个能力有多少是自己能写的」：为一个小功能引入一个大依赖，长期维护成本通常高于自己实现。