Will.liu先说说我的真实感受：干这行越久，越觉得 renaming 不是“改个名而已”，而是代码维护里最被低估的重构动作。很多人看到变量名不顺眼，憋着不改，觉得“能跑就行”；也有人听到要重命名就翻工具书，“万一改崩了怎么办”。可恰恰是这种“忍一忍”的心态，让代码在半年后变成一团谁也读不懂的迷。今天这篇文章不绕弯子，就围绕“为什么必须 Renaming”这件事，把命名背后的成本、该动手的信号、安全操作的方法、以及我踩过的那些坑全部摊开讲。适合刚入行的前端/后端开发、带着老项目跑的技术负责人，以及所有被“看不懂的历史代码”折磨过的人。
1. 为什么说 Renaming 是刚需 —— 名字本身就是代码的第一份文档
1.1 坏名字的隐藏成本
我们先从一个非常朴素的问题开始：读代码的时候，你最常做的事是什么？不是理解语法，不是追踪调用链，而是“翻译名字”。看到 a 你要想这是什么，看到 data2 你要猜它和 data1 的区别，看到 handleItem 你得点进去才知道它到底处理了什么。每一次“翻译”，都是在消耗脑力。脑力是有限资源，被无意义的名字吃掉之后，留给真正业务逻辑的注意力就少了。
我们团队前年接了一个外包遗留的订单系统，里面有个核心函数叫 func doStuff(a, b string) (string, error)。调用点散落在十多个文件里，没人敢动它。后来我们花了一个下午做 Renaming，把它改成了 func reconcileOrderStatus(orderNo string, expectedStatus string) (actualStatus string, err error)。函数标签页一展开，任何人三秒钟就能明白这个函数要干什么。那次改动零逻辑变更，纯改名，但后续所有接手的人，平均理解时间从半小时降到了三分钟。这就是坏名字的隐藏成本——它不是在某个时间点让你爆一次大的，而是在每一次阅读里持续收费，收得你毫无感觉。
有人算过一笔朴素的账：一个团队每天人均读代码 3 小时，其中 20% 的时间花在“猜名字”上，那就是每天 36 分钟。十个人的团队，一天就是 6 个小时的纯浪费。一年下来，相当于一个全职员工的全部产出被名字吃掉。这个账越大的代码库越吓人。
1.2 Renaming 与“可读性税”
我在不同的技术分享里反复提到一个词，叫“可读性税”。任何一段代码在被写出来之后，每被阅读一次，如果命名清晰，阅读成本就很低；如果命名含糊，就要反复交税。Renaming 不等于“追求完美主义”，它本质上是在做一件投资回报率极高的事：一次性支付改名的成本，换取未来每一次阅读的减税。
这里要说清楚一个容易误解的点：Renaming 不是让你把所有名字都改成又长又啰嗦的“小作文”。好名字的标准是“准确 + 高效”。orderStatus 比 status 准确，比 theCurrentStatusOfTheOrderAfterPaymentVerification 高效。Renaming 的目标是把名字从“读不懂”改成“读一遍就懂”，而不是从“短”改成“长”。
还有一个常见误区是“等代码稳定了