SonarQube扫描结果为空怎么办 SonarQube扫描日志怎么定位原因

SonarQube扫描结果为空，先不要急着重跑。更常见的原因不是平台坏了，而是扫描范围没有真正命中代码文件，或者代码被排除规则、源码管理忽略规则、主代码与测试代码分类错误一起过滤掉了。Sonar官方文档明确说明，扫描器会先根据分析范围决定要分析哪些文件，而调试日志会直接打印哪些源文件和测试文件被索引，所以排查顺序应先看范围，再看日志。

一、SonarQube扫描结果为空怎么办

这一步先解决“为什么没有文件进分析器”。只要范围为空，后面的规则、覆盖率和质量门禁都不会有意义，所以先把扫描范围查清楚最重要。

1、先查sonar.sources和sonar.tests有没有配到真实目录

Sonar官方参数文档说明，分析范围首先由sonar.sources和sonar.tests决定；如果这些路径没配到真实代码目录，或者构建工具没有给出默认值，扫描器就可能没有可分析文件。

2、再查inclusions和exclusions是不是把代码全过滤掉了

官方分析范围文档写得很清楚，Source File Exclusions会从sonar.sources定义的范围里继续排除文件，Source File Inclusions则只保留匹配项。两者一旦配错，就很容易把所有代码都筛空。

3、把源码管理忽略规则也一起查一遍

SonarQube Server当前文档说明，分析默认会尊重源码管理系统的忽略规则，例如Git里的.gitignore；如果代码目录被忽略，扫描时也会被自动排除。必要时可先核对这一层，而不是只盯扫描参数。

4、如果是.NET项目，先看.sonarqube-project.properties

SonarScanner for.NET文档明确提到，MSBuild完成后可以通过.sonarqube-project.properties查看扫描器最终会分析哪些文件。这一步很适合排查为什么项目编译成功了，但Sonar里几乎没有代码。

二、SonarQube扫描日志怎么定位原因

日志排查不要先看错误堆栈，而要先把日志级别提上来，再看“索引了哪些文件”和“哪些文件被归类成主代码或测试代码”。Sonar官方给出的标准做法，就是开启调试日志。

1、先用-X或sonar.verbose把日志拉到调试级

SonarScanner CLI官方文档说明，想拿到更多调试信息，可以在命令行加-X、--verbose或-Dsonar.verbose=true；参数文档也说明sonar.verbose=true会把扫描器日志提升到DEBUG级别。

2、重点看日志里哪些文件被indexed

官方“验证分析范围”页面明确指出，调试日志会显示哪些源文件和测试文件被索引。如果日志里几乎没有indexed file记录，问题通常就在分析范围，而不是规则执行本身。

3、若出现文件被重复索引，先修主代码和测试代码交叉

官方同一页面还给出了典型报错，若日志里出现某文件“can't be indexed twice”，就说明这份文件同时被当成source和test，必须先把主代码和测试代码的包含排除规则拆开。

4、如果是.NET，再看BEGIN和END阶段的分类日志

Sonar针对.NET的文档专门说明，开启verbose模式后，可以在日志里看到文件被归类为test project的相关信息；这对排查为什么主代码指标没出来、测试项目却被单独处理特别有用。

三、SonarQube分析范围怎么复核

把结果修到可用，靠的不是一次侥幸跑通，而是把扫描范围和日志口径固定下来。这样后面换分支、换CI或换机器时，才不会再次出现“扫描成功但结果为空”。

1、先把最终生效参数落到配置文件或CI脚本

Sonar官方参数层级文档说明，命令行参数优先级高于配置文件，配置文件又高于UI设置。更稳的做法是把本次修正后的sources、tests和exclusions固定在可追溯位置，不要靠临时命令记忆。

2、把一次调试日志和一次正常日志一起留档

一份留DEBUG日志，一份留正常INFO日志，后面若结果再次变空，可以直接比对indexed files和排除范围，定位会快很多。

3、对.NET项目把.sonarqube-project.properties一起归档

因为官方已经明确它可以反映最终会被分析的文件集合，所以把这个文件和构建号一起保存，后续最容易复现问题来源。

总结

SonarQube扫描结果为空，优先查分析范围是不是被sonar.sources、sonar.tests、inclusions、exclusions和源码管理忽略规则一起筛空了。日志定位时，先开-X或sonar.verbose，再看哪些文件被indexed、是否有主代码和测试代码重复分类；如果是.NET项目，再结合.sonarqube-project.properties和BEGIN、END阶段日志一起看，通常就能把原因压到具体目录、具体规则或具体项目分类上。