给临时方案设寿命
兼容层、灰度开关、影子表、旧接口这类临时方案，一旦没有清理条件，就会长期留在系统里，成为需要持续维护的隐性债务。治理方式是把它们当成有寿命的对象管理：登记在清单里，写明清理触发条件（调用量低于阈值、替代方案全量、迁移完成）与时间点，到期必须复核或删除，删除时保留理由。
管理三要素
| 登记 | 临时物清单，包含引入原因、负责人与清理条件 |
|---|---|
| 监控 | 调用量或使用率监控，作为到期的判断依据 |
| 执行 | 到期即处理：删除，或写明理由后重新评估延期 |
典型使用场景
- 接口版本升级：旧版本保留期间监控调用量，低于阈值后下线并移除代码
- 功能开关：全量开启并稳定运行后移除开关分支，避免永久保留两条代码路径
- 数据库迁移：影子表与双写逻辑在迁移完成后保留观察窗口，再归档删除
- 依赖替换：被替换库的适配层在新实现稳定后清理，防止两套实现长期并存
- 数据兼容字段：为了兼容存量数据预留的字段，在数据回填完成后收敛
清理清单示例
清理清单示例
# 临时物登记表（由责任人定期更新）
兼容层 v1 API 调用量 0.3%，到期 2026-06-30 → 复核后删除
开关 oldCheckout 已全量开启 30 天 → 移除分支与配置项
影子表 shadow_user 迁移完成 → 保留 90 天后归档
过渡字段 user.name_v2 回填完成度 100% → 收敛到单一字段触发条件与动作
| 触发条件 | 动作 | 风险 |
|---|---|---|
| 调用量连续低于阈值 | 公告后删除旧入口 | 仍有零散调用，需先确认长尾来源 |
| 替代方案全量稳定 | 移除旧实现与相关测试 | 过早删除会失去回退能力 |
| 开关全量开启且无回滚 | 删除开关分支 | 删错分支会影响线上，需先核对默认值 |
| 数据迁移完成 | 归档或删除影子表 | 归档前确认备份与查询需求 |
| 到期但仍有调用 | 评估延期并写明理由 | 无理由延期等于取消清理 |
删除顺序有讲究：先加弃用告警与文档标记，观察一个发布周期，再停用，最后删代码。这样调用方有时间响应，删除动作也不会直接触发线上故障。
临时物的清单本身也要有人负责：通常在债务台账里单列一节，与预算机制配合，让清理工作在排期里有位置，而不是只靠个人记性。
落地检查清单
- 每个临时方案都有负责人与清理条件
- 清单定期复核，到期项有处理结论
- 删除前确认调用量与影响范围
- 删除时同步清理配置、测试与文档