八个小时排查。
最后定位到的问题，说出来谁都不信——三年前为了赶当年的618上线，最资深的架构师把用户登录态的校验规则直接硬编码在三个核心接口里，连个配置项都没抽。
那天凌晨两点，整个机房的烟味飘得连前台的冷萃咖啡机都挡不住。改个校验规则要翻十几个Java文件，改完还漏了三个分支，重启一次崩一次。
没人记得。
真的没人记得。
当年那位架构师在写这段代码的时候，拍着胸脯说等活动结束就重构。结果活动结束后，团队接连接了三个新的业务需求，排期表里的重构项永远排在最后面，再后来他跳去隔壁园区当技术总监了，留着这个窟窿给后面的人填。
你以为的临时方案从来不会真的临时
太多人对技术债的误解，就是觉得这是初级开发写的烂代码。
根本不是。
那次碰到的硬编码，是当时团队代码能力最强的人写的。他当时的决策完全符合短期收益：离上线只剩72小时，抽配置、做灰度至少要花两天，现在先把活动跑起来比啥都重要。
你以为上线之后抽两个下午就能补完的窟窿，会在后续每一次需求迭代里被反复叠加——加新渠道的登录要改、换支付通道要改、甚至连用户量涨了十倍触发缓存失效策略的时候，都得顺带着把这堆硬编码翻出来瞅一眼，生怕改漏了哪行就把整个系统搞崩。
很多团队管这种代码叫”祖传代码”，带着点调侃的意味，好像只要大家都小心点，就不会出问题。
技术债的利息比你想的高得多
大部分团队算技术债的成本，只算当初重构要花的人天，从来不算后续滚出来的利息。
就拿那段硬编码的例子算笔账：三年时间里，前后有17个开发碰过这段代码，每次碰都要花至少40分钟找对应的分支，算下来光找代码的时间就花了快11个工作日。更别说那次大促崩了三个小时，直接损失的GMV、赔出去的无门槛优惠券、客服接的几百个投诉电话，加起来的钱，够把整个用户中心重写三遍。
我当时蹲在机房门口啃凉掉的奥尔良汉堡的时候，刷到那位架构师的朋友圈，他在新公司的落地窗边拍咖啡，配文说”技术要为业务创造价值”。
我差点把汉堡捏扁。
技术债从来不是某个人的错，是整个团队在业务压力下做出的短期选择。但问题在于，太多团队把这种临时选择当成了长期常态，觉得只要代码能跑，就不算债。就像你刷信用卡只看当月账单，不看后面滚的分期利息，等你反应过来要还的时候，本金加利息已经能把人压得直不起腰。更离谱的是，有些团队为了不碰老代码，干脆在外面套一层新的逻辑，就像在漏雨的屋顶上贴透明胶带，贴一层漏一层，最后整个屋顶都被胶带糊得密不透风，风一吹都要晃三晃。
真要还债别搞全员重构的运动
我见过最蠢的操作，是某个团队的技术老板拍板，说停掉所有新需求，全团队花两周时间把老代码全重写。
结果呢？
两周时间根本改不完，新需求的排期全堆着，业务部门天天追在屁股后面骂，最后改到一半的代码上了线，出了三个比原来还严重的bug，最后又灰溜溜把回滚的代码拉回来。技术债没还成，还多了一堆半拉子的新债。
真要还技术债，根本不需要搞什么大张旗鼓的运动。
现在见过最落地的做法，是把技术债拆成和日常需求绑定的小项——比如这次要改用户登录的逻辑，那顺带着把原来的硬编码抽成配置项，算1个故事点，排进这次的迭代里，不单独占额外排期。还有，每轮迭代固定留15%的迭代容量留给技术债，别把所有时间都塞给新需求。
最关键的一点，别关起门来技术组自己扛债。上次那个硬编码的问题，我们把每次改代码花的时间、大促损失的钱全列成表给业务总监看，对方当场就把排期里一个无关紧要的营销小功能砍了，给技术组腾了三天时间把那个坑填上。从那之后，每次开排期会，业务部门都会主动问，这次有没有要还的债，需要腾多少空间。
说实话，没有绝对零债的完美系统，就像你家里永远有擦不完的灰，拖不完的地。但你别把灰堆到三米厚，一开门就呛得人喘不过气。
别等债滚到还不起的时候，才想起当初赶上线的那个凌晨。