在添加、更新、审查或移除依赖前，如何逐级耗尽现有资源…

当你准备引入、升级、审查或删除任何依赖（包、库、SDK、GitHub action、基础镜像或 vendored 代码），或需要声明项目的依赖策略时使用。

适用场景

解决思路

1. 按顺序逐级排查，停在第一个成立的层级；好的答案常常组合两级，即用已有依赖处理难的部分，再自己写几行封装：1) 需求本身——投机性需求不是需求，跳过并用一行说明；2) 当前代码库——几个文件之外的 helper、类型或模式能完成工作就复用，仓库里已有东西的第二份拷贝就是 `keeping-one-source-of-truth` 禁止的缺陷；3) 标准库——安装重复标准库功能的包之前先读它的索引；4) 平台——优先用数据库约束而非应用代码、原生控件而非 widget 库、运行时原语而非包装器；5) 项目已携带的依赖——它的传递树已经付过成本，但有两条边界：开始使用的传递依赖就是新的直接依赖，必须声明、固定到已解析版本并轻度审查，因为代码已经随包发布；还要检查复用跨越的类别，把 dev-tool 的传递依赖提升为运行时依赖会把成本转嫁给每个消费者的安装而不只是 CI；6) 自己写几行——当确实只需二十行时，拥有二十行胜过拥有陌生人的仓库；7) 只有前六层都不成立才引入新依赖，并按下面审查。
2. 审查要引入的依赖：计算整个雇佣成本——它拖入的传递树、安装和构建重量、与项目许可证的兼容性、安全历史（advisory，以及有扫描器时的供应链评分）。
3. 检查脉搏：最近发布频率、issue 如何被回应、有多少人能合并。一个承重包只有一个精疲力竭的维护者是你在主动选择的风险。
4. 阅读你将调用的部分：你依赖的 API 表面及其失败模式，而不是 README 的承诺。对别人的代码也要脚踏实地。
5. 优先选只做一件事的工具，而不是做四十件事的框架；另外三十九件事会以重量和攻击面的形式一起到来。
6. 记录决策：新依赖是一个决策——它的用途、还权衡了什么、以及在什么条件下移除它（在已安装 `recording-decisions` 的地方使用它）。
7. 声明依赖姿态：依赖容忍度像风险层级一样由项目声明——完全自包含（有些应用正确地全面禁止外部代码）、精选允许列表、或审查后添加。项目规则或 CLAUDE.md 说明采用哪种；没有说明时，问系统绝不能依赖什么，并把答案当作声明。姿态即使不方便也要遵守；改变它是记录在案的决策，而不是一次 npm install。
8. 未声明的姿态不是硬性门槛：当今天没人能回答时，在声明的假设姿态下继续，把假设记录在决策中，并用负责人跟踪声明问题。
9. 固定并证明：提交 lockfile 并固定版本；CI 或基础镜像中未固定的 `latest` 是带着别人时钟的定时炸弹。
10. 更新和其他变更一样：在 major 升级前先读 release notes（先看破坏性变更和迁移），对它运行测试（`testing-changes`），给 major 升级单独的 commit 以保持 blame 轨迹可读；成组的 patch 升级可以一起走。
11. Vendored 代码在树中携带其来源和版本；你无法更新你无法确定日期的东西。
12. 移除：工作已消失的依赖应在移除该工作的同一变更中离开；留着“以防万一”的包就是第 1 层的投机性需求的反向。
13. 当依赖只剩一个小调用点时，考虑自己拥有那几行。
14. 无人维护但承重是一个有负责人和计划的风险项，绝不是希望。
15. 避免常见错误：小工具反射——依赖树不是靠大决策增长的，而是一次一个小包，每个单独看都合理；为了调用一个函数而安装框架；依赖包的内部或私有路径，只有公开契约才是承诺；把传递依赖当作自己的来导入，今天未声明，下次 lockfile 刷新就消失，如果需要就声明它；为了不读仓库里已有的代码而添加依赖（跳过了第 2 层）；vendoring 时不记录来源，然后疑惑副本是哪个版本；一次性更新所有东西，然后二分查找哪个升级破坏了构建。

适用边界 · 注意事项

• 当项目已声明完全自包含或禁止外部代码的依赖姿态时，不要引入新依赖。
• 当需求是投机性的、当前并不需要时，不要添加依赖。
• 当只需几行代码就能完成、或仓库中已有可复用实现时，不要添加依赖。