SonarQube 核心功能
三、核心功能
SonarQube 的核心可以概括为「一堆规则 × 一个门禁 × 一条趋势线」。
| 能力 | 说明 |
|---|---|
| Quality Profile | 按语言维护「激活哪些规则」。可继承官方配置再局部调整，团队习惯不同时可以为不同项目指定不同配置 |
| Quality Gate | 门禁条件集合。条件可以针对「新代码」或「整体代码」分别设定，实践中以新代码为主 |
| New Code 定义 | 决定「新代码」的边界：相对上个版本、最近若干天、或某个指定基线之后。这是整套机制里最需要想清楚的一项 |
| 问题分级 | 按类型分 Bug / Vulnerability / Code Smell，按严重程度分 Blocker / Critical / Major / Minor / Info |
| 分支与合并请求分析 | 把分析结果对到具体分支或 PR 上，PR 里直接看到新增问题（能力随版本不同，以官方文档为准） |
| 覆盖率导入 | 本身不算覆盖率，靠导入 JaCoCo（Java）、coverage.py（Python）、lcov（前端）等生成的报告 |
| Web API | 用于自动化创建项目、拉取指标、做自定义报表 |
| Scanner 形态 | 独立 CLI、Maven/Gradle 插件、容器镜像，按构建方式挑 |
门禁条件的常见构成（针对新代码，阈值按团队现状定）：
| 维度 | 示例条件 | 作用 |
|---|---|---|
| 覆盖率 | 新代码覆盖率不低于某个百分比 | 防止新代码无测试 |
| 重复率 | 新代码重复率不高于某个百分比 | 防止复制粘贴式开发 |
| 可靠性 | 新代码新增 Bug 数为 0 | 最直观的阻断条件 |
| 安全性 | 新代码新增漏洞数为 0，或不允许 Blocker/Critical | 把高危问题挡在合并前 |
| 可维护性 | 新代码技术债增量低于某个值 | 控制长期成本 |
关键配置项（写在项目根目录的 sonar-project.properties）：
| 配置项 | 作用 |
|---|---|
sonar.projectKey | 项目唯一标识，须与服务端创建的项目对应 |
sonar.sources | 源码目录 |
sonar.tests | 测试代码目录，与 sources 分开才能正确算覆盖率 |
sonar.exclusions | 不参与分析的路径，如生成代码、第三方库、静态资源 |
sonar.coverage.exclusions | 参与分析但不计入覆盖率的路径 |
sonar.java.binaries | Java 项目必填，指向编译产物目录；不填部分规则不生效 |
sonar.host.url | 服务端地址 |
sonar.token | 分析令牌，必须从环境变量或密钥管理注入，不要写进文件 |
