R1.05.3deprecation window设计
废弃需要明确的时间表
别名: 废弃窗口 · 下线日期 · deprecation date · @deprecated
概念解释
源码上标 @deprecated、文档里写「不建议使用」，在交付压力下等于建议，建议会被忽略。废弃必须带一个可排期的窗口：某次发布删掉，或某个日历日之后不再存在。窗口把「将来有一天」变成计划对象——日历、CI 失败日、剩余调用点看板都有了锚点。
没有钟的废弃会永远活着，新 API 也就永远替换不完。这不是「怎么迁过去」的路径设计，也不是「两套是否该长期并存」的结构问题，而是旧名字什么时候被允许消失。
机制
使用方按截止日期做取舍。没有日期，迁移就会排在功能后面，因为功能有外部承诺，废弃只有内部愿望。标了废弃却不给删除点，静态检查也会慢慢被习惯性关掉：警告从第一天就在，第三十天它还在，于是它变成背景噪音。窗口反过来用时间制造稀缺：过了这一发，旧导出会从类型里消失，CI 会红，排期才有对手方。
窗口还要对外可见且不可口头改期。写在注释里的「下个大版本」对使用方的日历没有句柄；写在发布说明、迁移指南和包的弃用元数据里，工具才能在窗口关闭前开始计数。改期必须发新公告，不能在聊天里把删除日往后拨——否则窗口重新变成愿望。
边界
安全漏洞或法律要求的紧急删除可以短于平常窗口，但仍要给日期，哪怕日期是「hotfix 当天」，并同步所有使用方渠道。从未发布过的实验导出可以不做窗口，直接删，前提是从未出现在稳定通道的类型里。依赖外部标准冻结的 API（支付字段名）窗口可能以年计，短窗口会逼使用方违法或掉单——这时钟还是要有，只是刻度更长。内部单体仓库若能在同一提交里删光调用点，窗口可以收缩成该提交本身，但合并说明里仍要写「即日起删除」，避免分支上的人以为旧名字还在。
怎么落地
- 每个废弃项同时写下三个锚点：引入废弃警告的发布、删除的目标发布或日历日、窗口内负责清调用点的人。
- 把删除日写进包元数据和 CI：窗口关闭后，旧导出从类型中消失，残留引用必须失败，而不是继续警告。
- 定期公布剩余调用点数量，窗口过半仍未下降则升级为阻断，而不是把删除日悄悄后移。
- 验证：打开该废弃项的说明，应能读到一个具体的发布号或日期；再看 CI 配置是否在该点从警告改为错误。只有注释、没有日期和失败日，废弃就还是愿望。