嘿，这个问题问到点子上了——SonarQube里的技术债务计算和可维护性度量是一套环环相扣的体系，我来给你掰扯清楚：

简单来说，技术债务就是SonarQube预估修复代码中所有问题需要的总时间，具体逻辑是这样的：

• 规则预设修复时长：Sonar团队给每一条内置规则（不管是bug、漏洞还是代码异味）都设定了基准修复时间，比如一个“未使用的局部变量”可能只需要5分钟就能搞定，而“深度嵌套的条件判断”可能要花30分钟。你也可以在后台自定义这些时长，贴合自己团队的开发节奏。
• 累加所有问题的修复时间：扫描完项目后，SonarQube会把所有被触发的规则对应的修复时间加起来，得到总技术债务。同时还会按问题类型（bug/漏洞/异味）、严重级别（Blocker/Critical/Major等）拆分债务，方便你优先处理高优先级的部分。
• 技术债务比率：除了总时长，SonarQube还会算一个「债务比率」，公式是 技术债务总时长 / 代码开发总时长。这里的开发时长是按代码行数估算的（默认每行代码按2分钟开发时间算，这个数值也能自定义），这个比率能帮你快速判断项目的“债务健康度”——比率越高，说明项目里需要偿还的“技术欠债”越多。

可维护性问题主要对应代码异味，但SonarQube不止是简单标记问题，而是从多个维度来量化：

• 代码异味的精准标记：SonarQube会扫描代码匹配内置的可维护性规则，比如「方法过长」「重复代码块」「复杂圈复杂度」「不合理的依赖」等，每触发一个规则就会标记一个可维护性问题，同时给出具体的修复建议，这些问题的修复时间也会直接计入技术债务。
• 可维护性指数（Maintainability Index）：这是一个0-100的综合分数，分数越高代表代码可维护性越好。它是结合四个核心指标计算出来的：
  • 圈复杂度：衡量代码分支的复杂程度，值越高，代码越难理解和修改
  • 代码行数：单文件或单个方法的行数过多，会大幅提升维护成本
  • 重复代码比例：重复代码越多，后续修改时需要同步调整的地方就越多，维护成本直线上升
  • 注释密度：合适的注释能提升可读性，但冗余、无效的注释反而会干扰理解
• 可维护性评级：基于可维护性指数，SonarQube会给出直观的评级：A（80-100，优秀）、B（60-79，良好）、C（40-59，中等）、D（20-39，差）、E（0-19，极差），一眼就能知道项目的可维护性水平。
• 自定义可维护性规则：如果你的团队有自己的编码规范（比如禁止使用某个过时API、强制特定的命名格式），完全可以在SonarQube里自定义规则，这些规则触发的问题也会被纳入可维护性度量和技术债务计算。

内容的提问来源于stack exchange，提问作者RAF1409