依赖债是什么
依赖债指项目被困在旧版本：安全补丁缺失、无法使用新特性、升级成本随跨度指数上升。治理方式是持续小步升级——每个迭代处理若干补丁版本，配合锁定版本与自动化测试兜底，而不是攒到必须升级时才冒险动手。
基本信息
| 典型信号 | 主版本落后多个大版本、漏洞告警长期挂着 |
|---|---|
| 治理策略 | 小步持续升级、锁定版本、测试兜底 |
| 工具支持 | 依赖更新机器人自动生成升级 PR |
| 必要配套 | 回归测试与灰度发布 |
| 常见阻力 | 升级 PR 无人评审，越积越多 |
典型使用场景
- 安全扫描报告里的依赖漏洞长期未修
- 框架停止维护，官方不再出补丁
- 想用新特性却被旧版本接口卡住
- 升级跨度太大，没人敢评估影响
- 多模块依赖版本不一致导致运行时冲突
升级节奏示例
升级节奏示例
每周：合并补丁级升级（自动测试通过即可合）
每季度：评估次版本升级，读变更日志并整理影响点
每年：评估主版本升级，专项排期与灰度验证
# 锁文件与传递依赖要一并更新，不要只升直接依赖升级节奏的设计
| 周期 | 处理范围 | 配套动作 |
|---|---|---|
| 每周 | 补丁版本 | 自动化测试通过即合并 |
| 每季度 | 次版本 | 阅读变更日志，列出影响点 |
| 每年 | 主版本 | 专项排期、灰度与回滚方案 |
升级最贵的部分不是改代码，而是验证：把验证自动化（回归测试加灰度发布），升级才能真正变小步，否则每次都变成一次大型变更。
升级 PR 堆积不处理，清单会越来越长，最后整批关闭：团队从此对升级提醒脱敏，漏洞也就一直留着。
自动合并补丁升级有前提：测试可信、流水线结论快。如果测试本身不稳定，先把流水线信任度修好，否则自动化只会带来噪声。