[!info] 关联笔记

• 所属 MOC：测试质量 · 学习路线
• 前置概念：JUnit · Maven / Gradle
• 后续概念：性能方法论
• 容易混淆：格式化 vs 静态分析 vs 测试

Java 静态检查与格式化

这个概念为什么出现

测试抓行为；静态分析抓“看起来就能错”的模式：空指针风险、资源未关、错误相等性。格式化消灭风格战争。

[!abstract] 一句话理解 格式化器统一外观；静态分析/编译器插件在 CI 拦截高风险模式；它们补位测试，而不是替代测试。

最小可观察示例

场景：CI 中的质量门禁命令示意

# 概念组合，具体插件随仓库而定
mvn -q spotbugs:check
mvn -q checkstyle:check
# 或
./gradlew spotlessCheck test

错误示例模式（人工）：

// 静态分析常警告：比较用了 == 对 Integer
Integer a = 128, b = 128;
if (a == b) { /* 可能 false */ }

结合场景再看三个关注点

1. 工具进 CI 才有效。
2. 抑制告警要写理由。
3. 格式化自动化（save/pre-commit）。

核心概念与准确模型

1. 格式化

google-java-format / Spotless / EditorConfig

2. 静态分析家族

SpotBugs、Error Prone、Nullness 检查、PMD…

3. 类型强化

Optional、注解 nullness、不可变

边界情况与反直觉行为

1. 误报需要基线治理。
2. 规则过严导致“全 suppress”。
3. 与 Lombok 等生成代码交互。

常见误区

[!warning] 常见误区：本地不跑、只靠审查 人脑不适合做格式警察与模式匹配。

工程实践

1. 新项目第一天加 format+基础 bug 模式。
2. 逐步打开错误级规则。
3. 与 IDE 检查同步。
4. 质量分阶段，不一次噎死。

本节总结

• 格式化统一噪声
• 静态分析降风险
• CI 强制执行

自测题

1. 静态分析与单元测试如何分工？
2. 为什么 suppress 要留注释？

参考答案

1. 分析抓模式/通病；测试锁业务行为与回归。
2. 防止无声绕过门禁，便于审计与后续清理。

延伸阅读与资料来源

资料	类型	支撑内容
Error Prone	工具	编译期检查
SpotBugs	工具	字节码分析