上周三凌晨两点，我被前同事的电话炸醒。
他在做的那个电商大促活动，刚开卖十分钟，订单接口直接挂死。远程连上去查了半小时，发现是三年前为了赶618上线，临时把用户地址校验的三层嵌套循环写死在订单生成逻辑里，当时谁都没想着抽离。现在订单量翻了20倍，那个循环直接把数据库连接池占满了。
真的。你坐在电脑前面看着告警一条接一条弹出来，那种后背发凉的感觉，没经历过的人根本不懂。
你以为的临时凑数，其实都是在给未来记账
很多人对技术债的第一反应，就是“代码写得烂”。
根本不是。
当年赶版本，产品拍着桌子说这周必须上，不然竞品就抢了行业首发的位置，你把原本要拆的微服务先揉在一个进程里上线，为了快，没写单元测试，甚至连异常捕获都只写了个最外层的try catch。这不是错。这是业务决策里必然要付的成本。
但问题是，太多人付了钱，却忘了这是笔要还的债。就像你刷信用卡买了个当下急需的东西，当时付款的那一刻爽得不行，后面每个月的账单不会因为你假装忘了就自动消失。
最坑的是，很多团队根本没把这笔账记在公开台账上。上次跟一个做垂直SaaS的团队聊，他们上线了17个功能模块，里面有9个是当年为了满足单个大客户的定制需求，硬改的核心代码逻辑。现在要做大版本升级，光把这些散落在各个角落的定制逻辑拆出来，就要花3个资深开发整整两个月。
你说这部分成本算谁的？产品那边觉得“我当时要的需求你答应做了，现在升级慢是你们技术能力不行”。开发那边觉得“我当时连续加班一周给你赶出来的东西，现在凭什么我要花两个月擦屁股”。扯皮扯到最后，版本延期，客户投诉，所有人都一肚子火。
别把技术债当洪水猛兽，也别当看不见的空气
说实话，我见过太多团队在技术债的问题上走极端。
一个极端是刚上任的技术负责人，追求代码的绝对优雅。哪怕业务明天就要上线，也要花两周时间把所有逻辑重构成教科书级别的标准架构，最后项目黄了，他拿着一套没有跑过线上流量的完美代码，去找下一份工作。
另一个极端是业务驱动到极致，所有需求排期只看上线时间，连代码评审都能省则省。半年后整个系统没人敢碰，改一个小功能要动三个地方，发版一次要回滚两次，团队里的开发熬了两年全跑光了，剩下几个老员工每天对着一堆没人看得懂的代码骂娘。
其实技术债本身没有对错，关键是你有没有主动管理它。我之前待过的一个团队，每次上线赶需求省下来的技术成本，都会专门在迭代看板上开一个固定卡片，标注清楚“本次为了赶双11上线，未做用户中心的接口鉴权”“本次为了满足快速上线，未做订单状态的幂等校验”，每个季度的迭代，都会专门拿出20%的排期，优先还那些已经开始影响业务效率的债。
比如之前省了接口鉴权的工作，后来发现有爬虫能直接刷用户的优惠券，就优先把这个补上。算下来花的人天成本，比真的被爬虫刷走几十万优惠券要划算太多。
真正要躲的，是那些没人认领的隐形成本
最可怕的技术债，从来不是那些你明知道欠了的。
是你根本不知道自己欠了的。
比如三年前的一个老开发离职了，他写的那段缓存逻辑，没人知道为什么要设置成15分钟过期，也没人知道为什么要在缓存里存三个本来可以实时计算的字段。直到上个月缓存集群扩容，大家把过期时间统一改成了1小时，结果整个首页的推荐逻辑直接乱套，排查了整整一天才找到原因。
这种隐形成本，才是团队最大的出血点。对吧？
你每次想招个新人进来快速上手，结果他光读老代码就要花两周，改一个小bug要翻五个文件，这种时间成本，根本没人算在技术债的账上。我之前跟一个做企业服务的CTO算过一笔账，他们团队一年因为老代码维护花的时间，占了开发总工时的40%——相当于10个开发里有4个，一年到头都在给之前的临时凑数代码擦屁股，根本没精力做新的业务功能。
那具体要怎么做？别搞什么复杂的治理框架，就从三件小事开始。
每次你为了赶进度，跳过了写测试、跳过了逻辑抽离、跳过了异常处理的时候，别装作这事没发生。专门找个文档记下来，标清楚当时为什么这么选，后面要补什么。
每个季度别全排新需求，留个15%到20%的迭代时间，优先还那些已经开始出故障、拖慢发版速度的债。别等系统崩了才临时抱佛脚。
所有老代码，只要有人动到，就顺手把那部分的注释补全，把能优化的小问题改掉。别留着给下一个人踩坑。
技术债从来不是什么技术圈的晦涩黑话。
就是你租代码房子的时候，欠的那笔房租。
你每月按时交点，住得踏实。
你一直拖着不还，总有一天房东会上门把你赶出去。