为何.class文件一致的@UtilityClass类，SonarQube显示的覆盖率不同？

问题原因 #

这一差异和SonarQube的覆盖率统计逻辑直接相关，核心原因是SonarQube的覆盖率结果不是仅基于最终生成的.class文件计算，而是需要将字节码的执行记录与原始Java源码的语法结构做映射匹配，两者的差异就来自两份原始源码的语法结构不同：

1. Lombok的@UtilityClass注解处理发生在编译期的注解处理阶段，会自动给类下的所有成员加上static修饰符再生成最终字节码，所以两份代码编译后的.class文件完全一致。
2. 但SonarQube解析代码时，会先读取你写的原始源码生成AST（抽象语法树）：
   • 写法1的原始源码里字段显式标注了static，Sonar识别为静态成员，静态成员在类加载阶段就会完成初始化，只要类被加载过就会被判定为已覆盖。
   • 写法2的原始源码里字段没有标注static，Sonar识别为实例成员，而@UtilityClass会自动将类的构造函数私有化，不允许生成实例，Sonar就会判定这个实例成员永远没有被访问/初始化的机会，所以标记为覆盖率0%。

解决方案 #

你可以二选一处理：

• 统一在@UtilityClass下的所有字段、方法前显式添加static修饰符，和Sonar的识别逻辑对齐。
• 调整SonarQube、JaCoCo的规则配置，添加对lombok.experimental.UtilityClass注解的适配，自动忽略该类下非显式static成员的覆盖率检测。

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