用途
这是一份依赖管理实践指南，适用于准备新增、更新、审查或移除依赖的场景，依赖包括软件包、库、SDK、GitHub Action、基础镜像或内嵌代码。使用前提为已掌握 principal-engineering 技能。
主要能力
核心原则：先用尽已有资源，再审查所取，钉住所取，并记录原因。用尽顺序依次为：需求本身（投机性需求不算需求）、当前代码库（已有辅助函数、类型或模式优先复用）、标准库、平台原生能力、项目已有的依赖、自己写的少量代码。只有这六层都不满足，才考虑新增依赖。
审查要点包括：整个依赖带来的成本（传递依赖树、安装与构建体积、许可证、安全历史与供应链评分）、维护活跃度（近期发布、问题响应、可合并人数）、你实际调用的 API 面及其失败模式。优先选单一职责工具而非大而全框架。新增依赖是一项决策，需记录其用途、权衡过的替代方案及退出条件。
依赖策略由项目声明，可为完全自包含、精选白名单或审查后新增。策略应在项目规则或 CLAUDE.md 中写明；若未声明，可先假定一种策略继续，并记录该假定。
用法要点
提交 lockfile 并钉住版本；CI 中的未钉住 latest 或基础镜像存在风险。更新视同变更：重大版本升级前先读发布说明，对照测试，并为重大升级单独提交。内嵌代码需在树中保留来源与版本。
移除
职责已消失的依赖应随该职责一并移除；仅剩一个调用点时考虑自己维护这几行；已无维护但仍承重的依赖应作为有负责人和计划的风险项处理。
常见错误
小工具反射式引入、为调用一个函数安装框架、依赖包内部或私有路径、把传递依赖当自己的依赖使用、不读代码就引入依赖、内嵌代码不留来源、一次性升级所有依赖后再二分排查。
限制
资料未给出具体工具、平台、收费或价格信息。