Checkstyle 无法检测 SQL 注入，因其仅基于 AST 做风格检查，不分析数据流和框架语义；真正有效的工具是 FindSecBugs，它通过字节码分析识别危险调用链和不安全模板用法。
Checkstyle 本身完全不能检测 SQL 注入等安全坏味道——它只管格式、命名、行宽、括号位置这类风格问题。想靠它拦住 String sql = "SELECT * FROM user WHERE id = " + userId; 这种拼接？不可能。
真正能识别这类风险的是 FindSecBugs（基于 SpotBugs 的安全插件），它分析字节码，盯住危险调用链：比如 request.getParameter() 直接进 Statement.execute()，或 MyBatis 中误用 ${}。
但你可以把 Checkstyle 和 FindSecBugs 放在同一套 CI 流程里，让它们各司其职。
为什么 Checkstyle 配了也报不出 SQL 注入？
因为它的设计目标就是「风格校验」：Checkstyle 解析源码 AST（抽象语法树），不追踪数据流，也不理解 JDBC 或 MyBatis 的语义。它甚至不会去读 @Query("SELECT * FROM t WHERE name = '" + name + "'") 这种字符串内容。
-
Checkstyle能发现：方法名用了下划线（get_user_info）、单行超 120 字符、缺少 Javadoc -
Checkstyle完全无视：变量是否来自 request、SQL 字符串里有没有拼接、PreparedStatement是否漏设参数 - 如果你在
checkstyle.xml里加了一条自定义正则规则去匹配"SELECT.*\+.*"，那属于 hack，不可靠、易误报、维护成本高
该用什么工具真正检测 SQL 注入坏味道？
用 FindSecBugs —— 它是专为安全漏洞设计的静态分析器，且和 Spring Boot 兼容性好，支持 Maven/Gradle 插件集成。
- 它能识别：
HttpServletRequest.getParameter()→Statement.executeUpdate()这类未经净化的直通链 - 它能标记：
MyBatis中${userInput}出现在WHERE子句中（而#{}是安全的） - 它能告警：
JPA @Query原生 SQL 里硬拼参数，如@Query("SELECT * FROM u WHERE email = '" + email + "'") - 注意：它不分析 XML 映射文件或纯字符串拼接逻辑（比如
"SELECT * FROM t WHERE id = " + id），只看字节码中的 API 调用模式和可控输入源
Maven 中如何同时启用 Checkstyle + FindSecBugs？
两者独立配置，互不干扰，但可以共用同一个 validate 阶段，失败即中断构建。
-
Checkstyle插件保持原样，重点约束可读性和团队约定：maven-checkstyle-plugin+ 自定义checkstyle.xml -
FindSecBugs需引入spotbugs-maven-plugin并启用findsecbugs-plugin：<plugin> <groupId>com.github.spotbugs</groupId> <artifactId>spotbugs-maven-plugin</artifactId> <version>4.8.4</version> <configuration> <plugins> <plugin> <groupId>com.h3xstream.findsecbugs</groupId> <artifactId>findsecbugs-plugin</artifactId> <version>1.12.0</version> </plugin> </plugins> </configuration> <executions> <execution> <goals><goal>check</goal></goals> </execution> </executions> </plugin> - 确保项目编译输出 class 文件（
mvn compile），因为FindSecBugs分析的是字节码，不是源码
关键点在于：别让 Checkstyle 承担它不该扛的责任。SQL 注入是语义级风险，靠风格工具永远扫不出来。真正要做的，是把 FindSecBugs 当成 CI 必过关卡，再辅以人工审计 XML 和字符串拼接逻辑——这两块它确实覆盖不到。
