旧代码不一定是技术债。

一段五年前写下、长期稳定、边界清晰的代码，可能没有任何修改价值。相反，上周刚完成的功能，如果把数据库名称写进所有业务层、把某个客户编号散落在几十处判断里，债务已经形成。

我更愿意用“选择权”理解技术债。

当需求变化时，我们还能不能只修改一个局部？能不能替换数据库、协议或消息组件？能不能为一个模块单独写测试？能不能解释一次改动会影响哪里？

如果每个答案都是“不确定”，系统就在收取利息。

这也改变了我看待重构的方式。重构不是为了让代码看起来新，而是购买未来的选择权。有些选择权很贵，也未必值得购买。一个即将下线的服务，不需要为了理论上的数据库迁移做完整抽象。

所以技术债不是道德问题。写下临时代码不代表不专业，关键是团队是否知道自己借了什么、利息在哪里、准备何时偿还。

最危险的债务通常没有 TODO。它藏在一句话里：

这里先这样写，反正以后不会变。