核心要点
识别：靠代码坏味道、圈复杂度、缺陷率、重复率等信号定位债务。
量化：评估维护变慢、bug 增多、新功能受阻等「利息」影响。
管理：建立技术债登记表，记录位置、影响与偿还成本。
偿还：按 ROI 排优先级，在日常迭代中渐进还债，防止失控。
标准回答
什么是技术债
技术债是为了短期速度而做的妥协（赶工、临时方案、欠缺测试），像借债一样会产生「利息」——后续维护变慢、bug 增多、改动风险变高。
如何识别
- 主观信号：代码坏味道、频繁出 bug 的模块、「不敢改」的区域。
- 客观指标：圈复杂度、重复率、测试覆盖率、缺陷密度、变更前置时间，可用静态分析工具辅助。
如何量化与管理
- 建立技术债登记表（backlog），记录位置、成因、影响范围与预估偿还成本。
- 量化业务影响：拖慢了哪些迭代、放大了多少缺陷。
- 按 ROI（影响大、偿还成本低优先）排序，在常规迭代中预留固定比例偿还。
- 通过评审、Definition of Done 与测试基线防止新债失控。
关键是把它当作可见、可决策的工程资产来管理，而非全部一次性「大重写」。
常见误区
⚠️ 常见踩坑
把所有技术债都标成「必须立刻还」，或反过来长期无视；也别拿「重构」当借口做无业务价值的大重写。
追问
追问 1：所有技术债都需要偿还吗？
不必。即将废弃或极少改动的模块，债务利息很低，可以「持有不还」。决策依据是该模块未来的变更频率与影响，而非债务本身存在与否。
追问 2：如何向非技术的产品/管理层争取还债资源？
用业务语言量化：把技术债转化为「交付变慢 X%」「线上故障率上升」「新功能排期延长」等可感知影响，给出还债后的收益与风险，纳入迭代计划而非额外申请。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。