依赖管理 3 原则 = 依赖是债务
解决什么问题：依赖失控 = 维护灾难—— 依赖是债务，必须主动管理（最小化 + 锁定 + 更新）。
业务问题
真实场景
场景 1：依赖膨胀
- 5 年前的项目
- 引入 200+ 依赖
- 50% 已知漏洞
- 升级 1 个依赖 = 破坏 10 个其他依赖
- 难以维护依赖 3 维
Direct vs Transitive（直接 vs 传递）
- 直接依赖：你写的
- 传递依赖：你依赖的依赖
Semantic Versioning：
- Major：不兼容
- Minor：向后兼容
- Patch：bug fix依赖 3 原则
1. 最小化
- 只用必要的依赖
- 评估替代（自己写 vs 引入）
- 拒绝"可能用到"
2. 锁定
- 精确版本
- hash 校验
- 可重现构建
- lockfile 提交到 git
3. 更新策略
- 主动更新（不要落后）
- 自动 PR（Dependabot / Renovate）
- 测试覆盖（兼容性）
- 跟随上游弃用SBOM（Software Bill of Materials）
记录所有依赖（含传递）
- 安全审计
- 合规（license）
- 漏洞追踪
- 标准化（SPDX / CycloneDX）工程实践
决策 1：何时引入新依赖
判断：
- 是否真的需要？
- 自己实现 vs 引入的 ROI？
- 依赖的维护活跃度？
- 依赖的依赖（传递）的健康度？
- 依赖的许可证？决策 2：如何更新依赖
策略：
- 频繁更新（小步快跑）
- 自动 PR（CI 自动测试）
- 主要版本升级 = 单独 PR
- 跟随上游弃用周期反模式 vs 正模式
| 反模式 | 正模式 |
|---|---|
| "用 ^ 就行" | lockfile 精确版本 |
| "等出问题再更新" | 主动更新 |
| "自己写一个" | 评估社区方案 |
| "测试在本机" | CI 完整测试 |
与 L 层对位
关键洞察
- 依赖是债务——每个依赖都增加维护成本。
- 最小化是硬道理——拒绝"可能用到"。
- 锁定 + 自动更新——确定性与新鲜度兼得。
- SBOM 是审计基础——记录所有依赖。
- 与 Hyrum 定律同构——传递依赖也是"实际契约"。