1 概述

SonarQube是一个静态代码分析工具，主要用于检查源代码的质量，包括代码重复、潜在漏洞、代码风格问题等。而SonarScanner是SonarQube的客户端工具，负责将代码进行形态分析，并将结果发送到SonarQube服务器。所以，静态分析通常针对的是源代码，而不是编译后的二进制文件。
例如，SonarScanner 在分析 Go 应用时，扫描的是源代码（即 .go 文件），而非编译后的二进制可执行文件。

但它在分析JAVA应用时，需要强制传入sonar.java.binaries参数，这是为什么呢？

2 sonar.java.binaries参数作用

sonar.java.binaries 用于指定JAVA项目编译后的字节码文件（.class 文件）的路径。SonarScanner需要这些字节码文件来执行以下操作：

• 精确代码分析
  某些分析（如代码覆盖率、继承关系、依赖解析）需要结合源码和编译后的字节码，以获取更准确的结果。例如，JaCoCo 覆盖率报告需与字节码关联以计算覆盖率。

• 检测潜在问题
  字节码中可能包含编译器优化后的信息，帮助识别某些仅通过源码无法发现的问题（如未使用的依赖、反射调用问题等）。

• 多模块项目支持
  在多模块项目中，每个模块的编译输出路径可能不同（如 module1/target/classes、module2/build/classes），需明确指定各模块的字节码路径以避免分析失败。

3 为什么需要参数sonar.java.binaries？

尽管 SonarQube 不直接分析字节码内容，但在某些场景下，需要访问编译后的.class文件以作为辅助分析，因为字节码在某些方面有着比源码更明确、完整的信息，此时.class文件是作为元数据输入，弥补源码的局限性。

以下是具体的情景：

• 场景1：测试覆盖率计算
  问题：覆盖率工具（如 JaCoCo）生成的报告是基于字节码的，而非源码。
  需求：SonarQube 需要将源码行与对应的字节码指令匹配，以准确统计哪些代码被测试覆盖。

• 场景2：复杂代码结构分析
  问题：某些代码特征（如泛型、Lambda 表达式（在编译后在字节码的特定结构）、反射调用）在源码中可能不够明确。
  需求：通过字节码可以更精确地解析代码结构，避免误报或漏报。

• 场景3：多模块项目依赖
  问题：在模块化项目中，子模块的源码可能依赖其他模块的编译结果。
  需求：通过字节码可以更精确地解析代码结构，避免误报或漏报。