wallfilter 需显式配置 db-type（如 mysql）且与 jdbc url 严格匹配，否则不加载；多语句需开启 multistatementallow；恒真条件拦截需启用对应开关；cte/窗口函数报错应升级 druid 至 1.2.38+ 或关闭 strictsyntaxcheck；注释需设 commentallow: true；参数化 sql 天然放行，${} 拼接才触发拦截。
WallFilter 不是“开了就防住”，配置错一个参数，它就完全不生效，甚至静默跳过校验。
WallFilter 没加载？先看日志里有没有 WallFilter init with dbType: mysql
Spring Boot 下仅配 druid.filters=wall 不够，db-type 必须显式指定且与 JDBC URL 严格匹配：
- MySQL 用
mysql（不是mysql5或mysql8） - PostgreSQL 用
postgresql（写成postgres会失败） - Oracle 用
oracle
1.2.38+ 版本起，db-type 不再自动推断，缺失即降级为无规则校验。启动时搜不到 WallFilter init with dbType: xxx 这行日志，说明 WallProvider 根本没加载，后续所有开关都无效。
sql injection violation, multi-statement not allow 怎么办
这是 WallFilter 默认拦截多语句执行（如分号分隔的多条 SQL），常见于批量操作或某些 ORM 自动生成语句场景：
- 启用
multiStatementAllow: true（在druid.wall.config下） - 但注意：该配置仅放开语法限制，不代表绕过注入检测；若业务真需多语句，应确认是否由 MyBatis 或 JDBC 层主动拼接导致
- 更安全的做法是改用
addBatch()+executeBatch()替代多语句拼接
sql injection violation, part alway true condition not allow 是什么
这类报错表明 WallFilter 检测到恒真条件（如 WHERE 1=1、OR '' = ''），但对应检查开关默认是关闭的：
-
delete-where-alway-true-check: true才拦截无 WHERE 或恒真 WHERE 的 DELETE -
update-where-alway-true-check: true才拦截类似 UPDATE 语句 - 缩进必须对齐 —— 若写在
druid.wall.config下但缩进错位，YAML 解析会忽略该字段
误报常源于动态 SQL 中的空值拼接（如 MyBatis 的 ${} 构造了 OR '' = ''），这不是 WallFilter 的问题，而是代码本身存在拼接风险。
SQL 有注释、CTE、窗口函数就报错？Parser 版本和 strictSyntaxCheck 得配合着调
Druid 的 WallFilter 依赖自研 Parser 做语义分析，旧版（如 1.2.20）无法解析 MySQL 8.0+ 的 CTE、INSERT ALL 等语法，直接抛 syntax error：
- 升级到
druid 1.2.38+是首选方案 - 临时应对可设
strictSyntaxCheck: false（注意：这仅关语法校验，不关注入规则） - 注释被拦？默认
commentAllow: false，需显式开为true - 所有这些开关都属于
druid.wall.config，且必须和db-type同级、缩进一致
最易被忽略的是：WallFilter 对参数化 SQL（PreparedStatement 占位符）天然放行，它只校验原始 SQL 字符串 —— 所以拼接出来的恶意语句会被拦，而正确用 #{} 的 SQL 永远不会触发这个异常。别为了过墙去关防护，先检查代码里有没有漏掉的 ${}。
