SonarQube自定义Java规则校验debug/trace日志前置启用检查时JUnit测试报断言错误

• 上报点位错位：当前代码调用context.reportIssue时，传入的节点参数是整个方法的MethodTree，但单元测试断言的是两个非合规日志调用的精准行号（示例代码中两处未做前置判断的LOG.debug、LOG.trace行），两者位置完全不匹配，直接触发断言错误。
• 违规判定逻辑完全缺失：代码没有判断debug/trace日志调用是否被对应的isDebugEnabled()/isTraceEnabled()判断包裹，只要碰到LOG.debug、LOG.trace调用就上报——连示例中if块内部的两个合规日志调用都会被误判为违规，实际上报的问题数（4个）和单测预期的违规数（2个）完全对不上。
• 硬编码匹配的健壮性问题：代码靠拼接字符串精确匹配"LOG.debug""LOG.trace"，写死了日志变量名必须是LOG，开发者把日志实例命名为logger、log的时候就完全识别失效；同时靠字符串匹配类型Log的判断方式，对不同日志框架的日志类兼容度极差。
• 全局状态污染风险：logFlag是类级别的全局变量，只要碰到Log类型的变量就永久置为true，遍历不同类、不同方法的代码时不会重置，会导致跨代码块的判断逻辑出错。

• 调整上报节点：将context.reportIssue的第二个参数从方法树tree，替换为当前检测到的违规日志方法调用的MethodInvocationTree节点，保证问题上报的行号精准对应到日志代码行，和单测预期的点位匹配。
• 补全违规判定逻辑：对每个debug、trace级别的日志调用，沿语法树向上遍历父节点，检查当前调用是否被同个日志实例对应的isXxxEnabled()判断的if块包裹，只有未被对应判断包裹的日志调用才判定为违规。
• 替换硬编码匹配逻辑：不再拼接字符串识别方法，直接从方法调用节点的语义信息获取被调用的方法名，只要是日志实例调用的debug、trace方法就纳入检测，不依赖日志变量的命名。
• 移除全局状态标记：删掉类级别的logFlag变量，所有判断逻辑完全基于当前语法节点的语义做实时判断，避免遍历过程中的状态污染。

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