R1.05.1breaking-change migration path设计
破坏性变更需要迁移路径
别名: 迁移路径 · codemod · 兼容别名 · compatibility shim
概念解释
改掉公开 props、拆掉默认槽、换掉语义角色，调用点不能再按旧写法编译或运行——这就是破坏。破坏本身可以做，但必须附带一条从旧写法走到新写法的迁移路径：兼容别名、双向导出、可运行的改写脚本、或逐项对照表。没有路径的破坏等于要求所有调用点在同一天人手重写。
路径是「怎么过去」，不是版本号怎么编码破坏程度，也不是先数一遍调用点有多贵。那些是节奏和编号问题。这里只要求：旧世界到新世界之间有一条走得动的路。
机制
调用点分布在别人的仓库里。破坏一旦发出，编译器或运行时会同时在所有未改的点上报错，使用方没有中间态。路径把这一刀拆成序列：先让旧名字继续工作并指向新实现，再提供机械改写，最后才关掉旧名字。兼容别名让未改的点暂时合法；codemod 让改写可重复、可审查；对照表让改写脚本覆盖不到的语义变化（角色从按钮变成链接）仍有人能跟。
缺任何一种载体，路径就断在那一层：只有文档没有脚本，人会抄漏；只有脚本没有别名，发版当天未跑脚本的仓库全红；只有别名没有关闭点，旧写法会永远活着。路径的产品是序列，不是一句「请升级」。
边界
尚未对外发布、调用点全在同一仓库且可原子改完的内部组件，破坏可以和改写同一笔提交完成，不必做跨包路径。纯新增（只加可选 prop、只加变体）不是破坏，硬做迁移文档会制造噪音。平台强制的破坏（系统 API 被操作系统删掉）路径不在你们手里，产品能做的是跟系统日历走，并给使用方一条自己的对照。二进制协议、原生 SDK 若无法热替换别名，路径可能是「发一个并存包名」而不是「同一包里留旧导出」——载体可以换，不能没有。
怎么落地
- 每个破坏项在变更说明里写明载体：别名保留到哪、codemod 命令是什么、对照表链到哪，缺一则变更不允许合并。
- 先发带别名的版本，等改写脚本在主产品仓库跑绿，再发去掉别名的版本。
- 对脚本覆盖不到的语义变化，在对照表里按调用点类型列出旧写法 → 新写法，并配一条可运行示例。
- 验证：拿一个未改过的旧调用点，只跟路径走，不读源码，能否在别名阶段继续运行、在脚本阶段改对、在关闭阶段仍能编译。任何一步要靠「去问作者」，路径就还没铺上。