AICoding质量门禁|SonarQube 核心度量项详细释义

1.核心度量
- [1.1.SonarQube 核心度量项详细释义（对应截图里每一项）](#1.1.SonarQube 核心度量项详细释义（对应截图里每一项）)
- - 1.1.1.Security｜安全域
  - [1.1.2. Reliability｜可靠性域](#1.1.2. Reliability｜可靠性域)
  - [1.1.3. Maintainability｜可维护性域](#1.1.3. Maintainability｜可维护性域)
  - [1.1.4. 3类Issue类型快速对照表](#1.1.4. 3类Issue类型快速对照表)
- 1.2.辅助度量
- - [1.2.1. Accepted issues｜已接纳问题](#1.2.1. Accepted issues｜已接纳问题)
  - [1.2.2. Coverage｜测试覆盖率](#1.2.2. Coverage｜测试覆盖率)
  - [1.2.3. Duplications｜代码重复率](#1.2.3. Duplications｜代码重复率)
- [1.3.New Code / Overall Code这两个Tab度量范围](#1.3.New Code / Overall Code这两个Tab度量范围)
[2. SonarQube 传统5个严重级别（Standard 模式：Blocker / Critical / Major / Minor / Info）](#2. SonarQube 传统5个严重级别（Standard 模式：Blocker / Critical / Major / Minor / Info）)
- [2.1. 严重级别](#2.1. 严重级别)
- - [2.1.1. Blocker（阻断级 / 阻塞）](#2.1.1. Blocker（阻断级 / 阻塞）)
  - [2.1.2. Critical（严重级）](#2.1.2. Critical（严重级）)
  - [2.1.3. Major（主要级）](#2.1.3. Major（主要级）)
  - [2.1.4. Minor（次要级）](#2.1.4. Minor（次要级）)
  - [2.1.5. Info（提示级）](#2.1.5. Info（提示级）)
- [2.2. 工程上的修复优先级建议](#2.2. 工程上的修复优先级建议)

关键字：质量门禁；核心度量；质量实践；软件质量；AI编程

本文主要介绍SonarQube的度量，包括核心度量和辅助度量，还介绍Sonar的度量严重级别和工程实践。

1.核心度量

1.1.SonarQube 核心度量项详细释义（对应截图里每一项）

SonarQube 的度量分为 三大质量域（Security、Reliability、Maintainability） + 辅助度量（Accepted issues、Coverage、Duplications）

评级规则：A(最优) > B > C > D > E(最差)

1.1.1.Security｜安全域

Open issues（20） ：未修复安全缺陷(Security Vulnerability)
- 定义：代码中存在可被利用的安全漏洞，攻击者有可能借此入侵系统、窃取数据、执行恶意代码。
- 举例：SQL注入、XSS跨站、硬编码密钥、不安全的权限控制、危险文件操作。
- 评级D：代表安全风险较高，存在中高危漏洞，需要处理。

区分：Vulnerability（安全漏洞，这里统计的）≠ Security Hotspot（安全热点，只是需要人工审核的风险点，不算Open Issue）

1.1.2. Reliability｜可靠性域

Open issues（151） ：未修复Bug
- 定义：代码逻辑缺陷，运行时会直接引发错误：程序崩溃、抛出异常、业务逻辑错误、死锁、空指针等。Bug会直接造成线上故障。
- 评级E：可靠性最差等级，说明存在不少严重/阻断级Bug，是最高优先级整改项。

1.1.3. Maintainability｜可维护性域

Open issues（941） ：代码异味 Code Smell
- 定义：代码写法不规范，不会直接导致程序崩溃或安全漏洞，但会增加阅读、修改成本。
- 举例：过长函数、魔法数字、命名混乱、多余if嵌套、未关闭资源、重复逻辑。
- 评级A：可维护性优秀。
关键：可维护评级不看问题数量，看技术债比率：修复全部代码异味预估工时 ÷ 项目总开发工时。本项目虽然941个异味，但整体修复成本占比低，所以是A级。

1.1.4. 3类Issue类型快速对照表

Issue类型	归属域	会不会直接线上故障	评级影响
Vulnerability 安全漏洞	Security	✅ 会，被利用就会安全事件	严重漏洞直接拉低安全评级
Bug	Reliability	✅ 会，运行出错、崩溃	高危Bug直接拉到E
Code Smell 代码异味	Maintainability	❌ 不会直接故障	看技术债比率，不是数量

1.2.辅助度量

1.2.1. Accepted issues｜已接纳问题

值：0
说明：Valid issues that were not fixed
含义：经过评审，团队确认问题有效，但决定暂时不修复 的缺陷（Bug/漏洞/代码异味）。
- 场景：业务遗留历史代码、风险很低且改动成本巨大，走豁免流程。
- 这里=0：代表当前没有任何问题被豁免，所有发现的问题都处于待修复状态。

1.2.2. Coverage｜测试覆盖率

值：0.0%，13k lines to cover
含义：单元测试/自动化测试执行时，覆盖到的可执行业务代码行占比
- 13k lines to cover：项目一共有13000行可被测试覆盖的代码（排除注释、空行、配置等）。
- 0.0%：完全没有单元测试。后续代码改动，无法自动化校验，极易产生回归Bug。

注意：覆盖率是辅助质量指标，不是Sonar A-E评级依据。

1.2.3. Duplications｜代码重复率

值：39.4%，132k lines
含义：项目全部132000行源码中，重复代码所占的行比例 。
Sonar会识别连续多行完全/近似相同的代码片段，判定为重复。
- 危害：一处业务逻辑修改，需要同步修改多处副本；漏改就会产生不一致Bug；增加维护成本。
- 39.4%属于很高的重复率，建议中长期做抽取公共方法/类的重构。

1.3.New Code / Overall Code这两个Tab度量范围

Overall Code（当前截图） ：整个仓库全部代码的统计结果
New Code ：新增代码（配置的新代码周期内，新提交/变更的代码）独立统计一套相同度量，用来管控增量代码质量，防止新代码继续引入问题。

2. SonarQube 传统5个严重级别（Standard 模式：Blocker / Critical / Major / Minor / Info）

优先级从高到低：Blocker > Critical > Major > Minor > Info

⚠️ 重要：严重级别直接影响 Security / Reliability 的A-E评级（只要存在 Blocker 漏洞，安全评级直接E）；可维护性（Code Smell）一般不会分到 Blocker/Critical。

2.1. 严重级别

2.1.1. Blocker（阻断级 / 阻塞）

定义：极大概率造成严重后果，必须立刻修复，不能上线

Bug场景：一定会引发生产崩溃、服务宕机、核心业务中断。例：空指针在核心链路、死锁、内存泄漏导致OOM。
安全漏洞场景：可直接被利用，攻击者能获取敏感数据、执行任意代码。例：无过滤SQL注入、硬编码数据库密码、高危远程代码执行漏洞。
管控策略：门禁红线，存在Blocker问题禁止合并上线。

2.1.2. Critical（严重级）

定义：影响重大，需要尽快修复，上线前优先处理。

Bug：大概率会触发异常、业务逻辑错误，不一定每次请求必现，但触发后影响大。例：事务未回滚、资源泄漏。
安全漏洞：高危漏洞，可被攻击但利用条件有一定限制。例：未授权访问、XSS存储型。
管控策略：迭代内限期修复，不允许长期遗留。

2.1.3. Major（主要级）

定义：存在较大影响，需要安排修复。

Bug：业务逻辑缺陷，在特定条件下出错，不会直接宕机，但会造成业务错误。
安全：中危漏洞。
代码异味：会显著增加维护成本，潜在隐患。

你截图里 Reliability E，大概率是存在大量 Blocker / Critical / Major 级别的Bug。

2.1.4. Minor（次要级）

定义：影响较小，不会破坏核心业务。

多为代码规范、可读性问题，少量低风险Bug。
例子：未使用变量、多余赋值、方法命名不规范。
修复时机：有空迭代顺带清理，不阻塞上线。

2.1.5. Info（提示级）

定义：仅信息提示，对程序运行没有实际影响，纯规范建议。

不影响功能、安全、稳定性。
例子：注释缺失、代码行略长、编码风格建议。
可选择忽略，一般不纳入质量门禁。

2.2. 工程上的修复优先级建议

Blocker：🔥 最高，立刻修复，阻断上线
Critical：🔴 高，本迭代必须修复
Major：🟠 中，计划在近期迭代修复
Minor：🟡 低，空闲重构时清理
Info：🔵 可选，按需处理