事情从一句很 innocuous 的需求开始："把首页那个按钮的文字改一下。"我估了十分钟，实际花了两个小时——因为那一行文案背后，串出了硬编码、重复定义和一层写死的跳转逻辑。把这场小型考古记下来。
连锁现场
- 第一层：文案果然只有一行，改完收工——如果我这时停下，就没有这个故事了；
- 第二层：搜索同名文案，发现它还被写死在另一个组件的空状态里，两处必须同步；
- 第三层：顺着引用继续挖，发现两处文案其实都来自同一个应该抽离的常量文件——只是从来没人抽过。
真正的修复
最后的改动是：新建常量文件、两处组件改为引用、文案本身改掉。diff 统计是 +11 −9 行，其中真正"改需求"的只有 1 行，其余 20 行都是在偿还当初"先写死再说"的债。这不是过度设计，这是把散落的真相归位。
"只改一行"的报价永远不准——准的不是行数，是这行代码连接着多少个 forgotten decisions。
沉淀下来的小习惯
- 改任何展示文案前，先全局搜索它出现几次；
- 同一个字符串出现第二次时就抽常量——这次它救了我；
- 估时的时候把"顺手重构"的诱惑当成独立任务排期，而不是塞进原任务里。
顺带一提，这次重构的"需求"后来被产品撤回了——文案改回去了，但常量化保留了下来。那 20 行成了这个项目里最划算的无效工。