上周跟鼓楼一家做餐饮SaaS的老陈喝精酿，他刚被产品部追着骂了半小时。原因是他们家给连锁奶茶店做的库存同步功能，上周三凌晨崩了三次，每次恢复不到两小时又挂。老陈蹲在服务器日志里扒了一整夜，最后发现是三年前为了赶618的商家上线deadline，把原本要做的分布式库存锁换成了单机内存锁。
就这。
当时赶完项目没人提，后来接手的两个开发都是看能跑就没动，直到单店开到120家，并发量上去了，内存锁的临界区直接被打穿。
没人主动提的债，才是滚雪球的根源
老陈说那堆代码，每一行都能跑通，没有低级语法错误。很多人对技术债的误解，就是把它等同于“代码写得乱”，其实根本不是。真正的技术债，是你为了赶进度、躲麻烦、抢功能优先级，主动或者被动选了一个“现在能用，但未来要付出额外成本补窟窿”的方案。
老陈他们团队之前根本没把这种选择算成“债”。当时上线的KPI是“7天内接满20家奶茶店客户”，谁要是提“要再花3天把分布式锁的逻辑补完”，估计会被产品按在地上问“你知道晚上线一天要丢多少合同吗”。
换你是产品经理，你也得急。
但话说回来，这债从来不会因为你假装看不见就消失。它会在你最忙的时候跳出来——比如赶上国庆奶茶店爆单，库存系统崩了，所有门店的珍珠、奶茶杯库存数对不上，商家要赔到哭，你总不能跟客户说“三年前我们赶进度省了三天，现在要你赔这个钱”吧？
别拿“还技术债”当摸鱼的挡箭牌
之前在河西见过一个做在线教育的团队，技术负责人上来就给老板提了个“三个月全量重构核心排课系统”的计划，理由是“现在的代码技术债太多”。结果三个月里，产品需求卡着上不了，家长端还出了好几次课表同步错的问题，最后老板直接把技术负责人开了。
为什么？因为他根本没算清楚，哪些债是真的要马上还的，哪些是可以放一放的。
技术债的成本从来不是按代码行数算的，是按它未来可能造成的业务损失算的。
就拿老陈那个单机内存锁的问题说，你说它是债吗？是，但如果他的客户永远都是单店，每天并发不超过10个，那他就算再过五年也不需要换。但当客户规模到了几十上百，每次故障直接影响几十万的流水，那这个债的优先级就比你加个新的营销弹窗功能高一百倍。
很多人搞反了顺序。上来就说“我要把所有旧代码全部重写”，本质上是把“还技术债”当成了自己可以脱离业务需求、按自己的审美写代码的借口。说白了，就是不想接产品的需求，拿重构当挡箭牌。
真要还债，别搞大动作
老陈后来是怎么处理那个库存锁的问题的？他没有搞全量重构，就是在每次给客户做新功能迭代的时候，顺带着把锁的逻辑改一点。比如这次给A品牌做库存盘点功能，就把涉及到的门店库存操作的锁换成分布式的；下次给B品牌做活动库存预警，再把剩下的模块慢慢切。前后花了两周，每天抽两个小时，没有耽误任何新需求上线，也没让团队加班熬夜。
不要为了还债而还债，要把还债的动作揉进每一次正常的业务迭代里。
真要落地，其实没那么多复杂的方法论。每次做需求评审的时候，顺带着问一句“这次改的模块，之前有没有留过什么坑”，有坑就趁这次改代码的机会顺手填了，不用专门抽时间搞重构。每个季度抽半天时间，让团队的人把自己负责的模块里“可能会炸”的点列出来，按“炸了之后会损失多少钱”排个序，优先处理排最前面的三个，剩下的往后放。
别追求什么“代码零债务”，那是不可能的。只要你在做决策的时候，知道自己现在欠了什么债，大概未来要花多少成本还，就够了。
那天跟老陈喝完酒走在广州路的梧桐树下，他说以前总觉得“技术债”是书上教出来的虚概念，现在才知道，那就是你在每一个赶进度的深夜，偷偷塞在代码仓库抽屉里的欠条。
你可以暂时不还。
但别等债主找上门的时候，才发现抽屉已经被欠条塞满了。