连接池无法单独拦截sql注入，需wallfilter语法检测+allowmultiqueries=false隔离+maxlifetime凭证绑定三者协同；druid需显式启用wall并配置策略，hikaricp依赖jdbc参数堵漏，k8s滚动更新须确保旧连接超时后再删账号。
仅靠连接池配置无法拦截SQL注入，但它能显著收紧攻击面——关键在于切断“高权限+长连接+多语句”组合带来的逃逸路径。
Druid 的 filter 配置必须显式启用 SQL 防注入拦截
Druid 自带的 WallFilter 是唯一能在连接池层做 SQL 语法级检测的机制，但默认不开启。它不是万能盾，但能拦住 UNION SELECT、EXEC xp_cmdshell、INTO OUTFILE 等典型注入模式。
-
spring.datasource.druid.filters=wall必须写在配置里，否则所有 SQL 都直通数据库 -
spring.datasource.druid.wall.config.delete-allow=false禁用 DELETE（若业务真不需要） -
spring.datasource.druid.wall.config.select-allow=true显式放行 SELECT，避免默认策略过于宽松 - 注意：WallFilter 对
LIKE '%?%'或ORDER BY ?这类动态字段无效，仍需代码层白名单校验
HikariCP 没有内置 SQL 检测能力，靠参数隔离阻断多语句逃逸
HikariCP 定位是轻量高性能池，不处理 SQL 内容。它的防御价值全在“堵漏”：防止攻击者绕过 PreparedStatement 直接执行多语句。
- 确认 JDBC URL 中设置了
allowMultiQueries=false（MySQL 默认为false，但显式声明更安全） - 禁用
autoReconnect=true，避免重连时用原始凭证绕过连接池权限控制 - 不要在
connection-init-sql里执行SET sql_mode=''或SET NAMES gbk—— 宽字节注入可能借此复活 - 若应用必须支持动态排序字段（如
ORDER BY ${column}），连接池本身无法防护，只能靠上层代码白名单校验
所有连接池都必须设 maxLifetime 配合凭证轮换
连接池复用旧连接的特性，会让数据库密码轮换失效。攻击者一旦拿到一个存活连接，就能继续用旧凭证执行任意语句，哪怕密码已被重置。
-
maxLifetime建议设为 1800000（30 分钟），确保连接在凭证过期前自然销毁 - Druid 还要配
testWhileIdle=true+validationQuery=SELECT 1，避免空闲连接失效后仍被取出使用 - HikariCP 同样需开
connection-test-query=SELECT 1和idle-timeout，但测试语句不能含权限敏感操作 - K8s 环境下滚动更新时，必须等旧连接全部超时断开，再删数据库旧账号；否则
maxLifetime形同虚设
真正起作用的从来不是某个单一配置，而是 WallFilter 的语法拦截 + allowMultiQueries=false 的语句隔离 + maxLifetime 的凭证绑定 —— 三者缺一不可。最容易被跳过的，是把 maxLifetime 当成可选参数，或以为开了 WallFilter 就不用管连接复用问题。
