HikariCP不能防SQL注入，因其仅管理连接生命周期，不解析、不拦截SQL；真正防护需依赖PreparedStatement、MyBatis的#{}语法及多层数据访问层安全措施。
HikariCP 本身不提供 SQL 注入检测能力，也不能“辅助检测”SQL注入——它只是一个连接池，不解析、不拦截、不审计 SQL 语句。 试图靠调大 connectionTestQuery 或启用 leakDetectionThreshold 来“防注入”，是方向性错误。真正在生产环境起作用的防线，和 HikariCP 配置无关。
为什么 HikariCP 不能用于 SQL 注入防护
HikariCP 的职责仅限于：管理连接生命周期、复用 TCP 连接、控制并发获取行为。它不接触 SQL 文本，不介入 PreparedStatement 绑定过程，也不检查传入的参数值。即使你配置了 connectionTestQuery="SELECT 1"，它只在空闲连接保活时执行这条固定语句，对业务 SQL 完全无感。
- 所有 SQL 解析、拼接、预编译动作发生在 MyBatis / JdbcTemplate / JPA 层，不在连接池环节
- HikariCP 没有 SQL 白名单、关键字过滤、AST 解析等机制；Druid 才内置
stat和wall这类防火墙模块 - 把防御寄托在连接池上，等于让门卫去审查你带进办公室的每张纸的内容——他只管发门禁卡，不管纸上写什么
真正该配的 HikariCP 参数（与安全间接相关）
虽然 HikariCP 不防注入，但合理配置能暴露潜在风险点，比如连接泄漏常源于未关闭的 Statement 或 ResultSet，而这可能和手写拼接 SQL 的错误习惯强相关。
-
leakDetectionThreshold=60000：连接被借用超 60 秒未归还时打 warn 日志，可快速发现try-with-resources缺失或异常吞没问题 -
maxLifetime=1800000（30 分钟）且keepaliveTime=300000（5 分钟）：避免数据库侧主动断连导致的隐式错误，防止因连接失效后重试逻辑意外触发原始 SQL 字符串拼接 -
allowPoolSuspension=true（仅测试环境）：配合HikariDataSource的suspendPool()可临时阻断所有新连接，用于验证应用是否真依赖连接池而非直连——若直连仍能跑，说明底层有绕过 DataSource 的硬编码 JDBC
Spring Boot 3 中实际生效的 SQL 注入防护链
防护必须落在数据访问层，且需多层覆盖。HikariCP 配置只是最底下的“地基”，不是“安检门”。
- MyBatis：全局禁用
${}，只用#{}；检查所有<script></script>和<bind></bind>标签是否引入动态表名/字段——这类场景必须白名单校验，不能靠正则 - JDBC 原生调用：强制要求
PreparedStatement+setString()等方法，禁止Statement.execute(sql + param) - 请求入口：用
@WebFilter处理原始请求体（getInputStream()/getPart()），而非HandlerInterceptor——后者根本拿不到 JSON Body 里的字段 - 日志脱敏：确保
application.properties中logging.level.com.zaxxer.hikari=DEBUG不开启，否则会打印完整 SQL（含参数值），造成敏感信息泄露
最容易被忽略的一点：很多团队开了 spring.sql.init.mode=always 并配了 schema.sql，却没意识到其中的 DDL 若含 ${} 占位符（如动态库名），会在启动时被 Spring 直接字符串替换——这反而是个高危注入面，且完全绕过所有运行时防护。这类配置必须走 CI/CD 审计，不能靠连接池兜底。
