迁移成本落在使用方，节奏由调用点数量决定
别名: 调用点成本 · 迁移节奏 · migration tax · blast radius
概念解释
一次破坏性变更在库里可能只改几十行，真正要付账的是每一个调用点：产品代码里每一处标签、每一处属性、设计文件里每一处实例。调用点迁移成本（call-site migration cost）落在使用方，不落在发版的那一队人。节奏因此不由「我们这周能不能发」决定，而由「外面有多少处必须人手改」决定。调用点是一千，就有一千次打开文件、理解新旧差异、改完再验证的工作；组件只有一个，这个不对称才是成本的形状。
团队数、仓库数都不是好的分母。一个团队可以包一层壳，把一千处调用藏在壳后面，也可以把一千处散落在二十个仓库。数调用点，才能看见使用方要付的小时。
机制
库作者改接口的边际成本接近于一次重构。使用方的成本是调用点数量乘上单点理解时间。单点时间不是常数：属性改名接近查找替换，默认值翻转要重新看画面，槽位结构调整要重写子树。同一位数的「主版本」下面，实际工时可以差两个数量级，所以节奏不能只看版本号，要看被触及的调用点分布。
发版方感觉「已经给了信号」并不减轻使用方的日历。产品有自己的冻结窗口、发布列车和人员。一千处调用摊在一个迭代里会挤掉功能；摊开三个迭代，库的新能力在这段时间里对未迁移的点不可用。谁决定节奏，要看谁付工时——付工时的是调用点的主人。
边界
自动改写能覆盖的机械改名，调用点数量不再等于人手小时，节奏可以跟着工具走；工具覆盖不了的语义变化（默认值、焦点顺序）仍按点计。内部只有个位数调用、且作者与使用方是同一人时，成本回到发版方，这条不对称暂时消失。生成代码、编译期宏把调用点藏进构建图，表面上「没几处手写」，真实爆炸在生成物里，分母要改去数生成后的节点。设计系统被当成一次性脚手架、调用点本就不打算跟版本走时，谈节奏没有对象——那是放弃跟库，不是迁移慢。
怎么落地
- 破坏性方案在动手前先查调用点：按仓库、按组件、按改动种类（改名 / 默认值 / 结构）列出数量，用工时上限定节奏，不按发版方的周历定。
- 把「调用点估计」写进变更单，和破坏位数放一起；估计缺失的变更单视为不完整。
- 优先改调用点少或可被机械改写覆盖的破坏；对调用点密集且必须人手理解的，拆成多次较小的位数变化，而不是一次打包。
- 验证：对一次已完成的主版本，用搜索或编译器统计实际改动的调用点数，对照发版前估计。偏差超过一倍，下次禁止在没有新统计的情况下排期。再问三个产品仓库的负责人「这次占了你们几个迭代」——若发版方记录是「一周内跟完」，而调用点主人报的是「还在第三个迭代」，节奏的决定权就还没落到付账的人身上。