弃用与迁移

要解决的问题

团队里最常见的技术债不是写不出来，而是删不掉。一个 OldTaskService 跑了五年，没人敢动，没监控，扩容靠手动，但每天还有几十个调用方在依赖它。代码不是资产，是负债——维护它的每分钟都是欠下的债。更糟的是僵尸代码：六个月没提交、没有 owner、测试坏了没人修、已知漏洞没人更新。大多数团队擅长造东西，却不擅长扔东西。

技能如何工作

这个技能的工作方式很直接：先决策，再迁移，最后删除。

弃用决策五问是起点。这套系统还提供独特价值吗？有多少消费者依赖它？有替代方案吗？每个消费者的迁移成本多大？不弃用的持续运维成本是什么？五个问题回答完，弃用与否才真正有依据。

弃用类型分两种。建议型适用于旧系统稳定、迁移可选的场景，用警告和文档推动即可。强制型适用于有安全风险或不可持续的问题，必须设硬截止日，并且不能只发一纸通知——迁移工具、文档、支持缺一不可。

迁移流程遵循四步：先建好替代方案并在生产验证，再写清公告与文档，然后逐消费者增量迁移，最后确认零活跃使用后删除旧代码。数据库变更绝不在原地改列，走 Expand/Contract 四阶段：加新列可空→分批回填→切读→停用旧列并单独部署删除，每步都可独立回滚。

适用边界

这个技能不替你动手删代码，它产出的是决策结论、迁移计划和公告草稿。纯功能新增、与现有系统无替换关系的需求不在范围内。绞杀者、适配器、特性开关这些模式选哪个，取决于你的流量切分粒度和前端是否无感。