通用方法 · 熟练
改名通知看懂了，改哪几处不知道？
接受期不是缓冲，是最后一段可核的时间
平台方改配置字段名，公告里往往只有一张「旧名 → 新名」的小表。看着简单，实际操作里翻车的全是另外两件事：① 同一件事的旧名散在多少处（脚本 · 流水线 · 文档 · 别人电脑上那份）；② 有几个是「类型也变了」，不只是换个字。这一页给的是「接受期工作法」：把接受期末日当倒计时，先扫出全部引用点，再按「纯改名 / 连类型一起变」分两批，最后留一次演练窗口——关键动作只有一个：在接受期内先跑一次「把旧名全部关掉」的演练，而不是等到期当天发现漏了一处。
方法 · 一图看懂
1
先把末日读成倒计时 — 接受期截止时刻是唯一硬期限：从它倒推预留出「扫引用 → 改 → 演练」的时间，别把它当缓冲
2
扫「谁在用旧名」，不是扫「谁该改」 — 脚本 · 定时任务 · 流水线配置 · 托管设置 · 台账与文档，五处都要过一遍（漏文档 = 下次接手的人照旧名改回去）
3
把「纯改名」和「连类型一起变」分开 — 前者可以批量替换后跑一遍；后者要逐条改结构（例：字符串改成 JSON 对象），⛔ 两种不能同批处理
4
留一次「关掉旧名」的演练 — 在接受期还没结束时，把旧名先停用一次，看哪些环节会报错；演练过才叫能迁移
原理 · 为什么有效
平台方愿意给一段「旧名仍然被接受」的时间，本意是给你过渡，但很多人把它理解成了宽限期——于是真正的迁移工作被推到了接受期的最后几天，而那时候已经没有空间做演练了。接受期的真正用法是当一段「可核时间」：在这段时间里，旧名和新名同时有效，你才能做一件平时做不到的事——把旧名关掉试试，看谁会炸。而「类型也变了」的那一类必须单列，因为批量替换在这里是最危险的：字符串换 JSON 对象这类改动，替换工具会认为它改完了，运行期才会发现自己拿到的是一团文本。判据一句话：改动清单里凡是「形态也变」的，一律单列、逐条改、逐条验。
适用场景
适用：① 你在用某个平台的托管配置 / 组织级设置，而它公告了一批字段改名或类型变更 ② 你的配置散落在多处（脚本 · CI · 托管后台 · 别人的机器上）③ 你需要把「旧名到期那天会发生什么」提前问清楚。⛔ 不适用：① 根本没有引用过旧名（先扫一遍确认，再决定要不要做）② 平台给了自动迁移且你能复核结果（那就把力气放在复核上，⛔ 不是重做一遍）③ 只有一次性的本地配置、不会过期也不进流水线。
自测 · 5 问
我能说出这个接受期的确切截止时刻（含时区），并从它倒推出了动手日
我扫出来的引用点里有文档与台账，不只是代码和配置
我把改动分成了两批：纯改名与连类型一起变，没有混在同一批批量替换里
我在接受期结束之前做过一次把旧名关掉的演练，知道谁会报错
改动后我回读了一遍自己的配置，确认没有「改了一半」的字段（旧名与新名同时出现在一处）
怎么上手 · 验证步骤
① 从公告里抄下接受期截止时刻，写进日历，并把动手日定在它前面留出演练时间。② 用旧字段名做一次全文搜索，把命中的五处来源分别列出来：脚本 / 定时任务 / 流水线配置 / 托管设置 / 文档台账。③ 逐条判断：纯改名，还是类型也变了；类型变了的单独放一边。④ 先改纯改名那批并跑一遍；再逐条改类型变更那批。⑤ 在接受期还没结束前，把旧名停用一次做演练，记下报错点并修完。
自检动作：把接受期末日当成今天，问自己一句——我现在把旧名全部关掉，谁会先报错？答得出来，说明引用点扫全了；答不出来，说明还有一处没被看见，而那一处会在到期当天替你回答。