在不中断业务的前提下渐进式改造遗留系统（strangler…

当你需要现代化老旧代码库、拆分单体、升级框架或语言、降低技术债，但又不能中断线上业务时使用。

适用场景

解决思路

1. 评估系统：分析代码库、依赖、风险和业务约束，先产出依赖图和风险登记表；在进入下一步前确认所有外部集成和数据契约都已记录在案。
2. 规划迁移：设计带明确回滚策略的渐进式路线图，每个阶段都要有定义好的回滚触发条件和负责人；可参考 references/system-assessment.md 中的代码分析模板。
3. 构建安全网：在改动生产代码之前先编写特征化测试（characterization tests）和监控，目标覆盖现有行为的 80% 以上；在未修改的遗留系统上运行特征化测试套件并确认全部通过后再继续。
4. 渐进式迁移：应用 strangler fig 模式配合特性开关（feature flags），通过 facade 路由流量，逐步切换负载；每次流量递增（如 5% → 25% → 50% → 100%）后验证错误率和延迟指标仍在基线阈值内。
5. 验证与迭代：运行完整测试套件、查看监控面板，确认业务行为保持不变后再下线遗留代码；新代码必须在 100% 流量下稳定运行至少一个发布周期后，才能移除遗留路径。
6. 按上下文加载参考文档：strangler fig 模式（references/strangler-fig-pattern.md）、重构模式（references/refactoring-patterns.md）、迁移策略（references/migration-strategies.md）、遗留测试（references/legacy-testing.md）、系统评估（references/system-assessment.md）。
7. 实现 facade 路由：用环境变量或配置开关在遗留服务与新服务之间切换请求，例如 OrderServiceFacade 根据 USE_NEW_ORDER_SERVICE 决定调用 LegacyOrderService 还是 NewOrderService。
8. 实现特性开关封装：用 flag_enabled(flag_name, default) 之类的薄封装读取环境变量或配置，控制新支付网关等迁移路径的启用。
9. 编写特征化测试模板：用 pytest 参数化测试捕获遗留系统的现有行为作为 golden master，行为意外变化时立即失败并给出清晰错误信息。
10. 必须做到：迁移全程零生产中断；重构前建立 80%+ 测试覆盖；所有渐进式发布使用特性开关；实现监控与回滚流程；记录所有迁移决策与理由；保留现有业务逻辑与行为；透明沟通进度与风险。
11. 绝不能做：大爆炸式重写或替换；跳过对遗留行为的测试；无回滚能力就部署；破坏现有集成或 API；在新代码中忽视技术债；未充分验证就仓促迁移；新代码未经验证就删除遗留代码。
12. 交付物需包含：评估摘要（风险、依赖、方案）、迁移计划（阶段、回滚策略、指标）、实现代码（facade、适配器、新服务）、测试覆盖（特征化、集成、端到端）、监控设置（指标、告警、面板）。

适用边界 · 注意事项

• 不能接受任何生产中断或无法提供回滚能力的场景。
• 没有时间或资源先建立测试覆盖和监控就想直接改代码的场景。
• 需要一次性大爆炸式重写、且不允许渐进式迁移的场景。