用途：指导弃用旧系统、API、库或功能，并将用户安全迁移到新实现；也用于合并重复实现、清除无人维护却被依赖的僵尸代码，以及在新系统设计阶段规划生命周期。
核心原则：代码是负债，每行都有测试、文档、依赖更新与安全补丁成本；Hyrum 定律使移除困难，因为足够多的用户会依赖包括缺陷在内的可观察行为，因此弃用必须主动迁移而非仅公告；弃用规划应始于设计阶段。
弃用决策：先判断该系统是否仍有独特价值、依赖者数量、是否已有替代品、各消费者迁移成本，以及不弃用的持续维护成本。不要在没有可用替代品时弃用。弃用分建议型（迁移可选，旧系统稳定，用警告和文档推动）与强制型（存在安全问题、阻碍进展或维护成本不可持续，设硬性截止日期）；默认建议型，强制型必须提供迁移工具、文档与支持。
迁移流程：一、先构建替代品，覆盖关键用例、有文档与迁移指南、经生产验证。二、发布弃用通知，说明状态、替代品、移除日期与原因，并给出迁移指南。三、逐消费者增量迁移：识别接触点、改用替代品、验证行为一致、移除旧引用、确认无回归；谁拥有被弃用基础设施，谁负责迁移用户（Churn 规则）。四、删除旧系统前，用代表性时间窗的观测用量判断，并考虑低频与离线消费者；先准备经授权的回滚或归档，缺少近期日志不等于零消费者；确认零活跃使用后移除代码及其测试、文档与配置，归档通知但保留迁移历史可查。
常见模式：绞杀者模式（新旧并行，逐步切换流量至旧系统 0% 后移除）、适配器模式（旧接口委托新实现）、功能开关迁移（按用户逐个切换）。
僵尸代码：无人拥有却被广泛依赖，特征包括数月无提交但仍有活跃消费者、无维护者、测试失败无人修复、依赖存在已知漏洞。处理方式为指定负责人正式维护，或制定具体迁移计划后弃用。
验证清单：替代品经生产验证、迁移指南具体、所有活跃消费者已迁移并有指标或日志佐证、旧代码与文档配置完全移除、代码库无旧系统引用、归档通知且迁移历史可查。
限制：仅在上游来源与本地项目上下文明确匹配时使用；应用变更前须验证命令、生成代码、依赖、凭据与外部服务行为；示例不能替代环境专属测试、安全审查，以及破坏性或高成本操作的用户批准。资料对具体价格、平台支持等信息暂未提供。