mybatis-plus拦截器不能替代静态扫描，因其仅在运行时做可疑模式识别，无法还原源码拼接痕迹；它通过statementhandler监听原始sql、${}使用、危险字面量等实现高危信号捕获，但真正sql注入扫描应依赖ide插件、sonarqube或字节码工具。
不能靠 MyBatis-Plus 拦截器「自动扫描」SQL注入点——它没有静态分析能力，也不具备语法树遍历或污点追踪功能。所谓“扫描”，实际只能做运行时的**可疑模式识别**，比如检测未参数化的字符串拼接、硬编码值、危险函数调用等。
为什么拦截器不适合做 SQL 注入扫描
MyBatis-Plus 拦截器工作在 SQL 执行前一刻，此时 BoundSql.getSql() 返回的是已解析占位符的模板（如 SELECT * FROM user WHERE name = ?），原始 Java 代码里的字符串拼接痕迹早已丢失。你看到的不是“怎么写的”，而是“准备怎么执行的”。
这意味着：
- 无法还原
queryWrapper.eq("name", "'" + userInput + "'")这类错误写法 - 无法定位
apply("id in (" + ids + ")")中的ids来源 -
last("ORDER BY " + sortField)这种拼接在拦截器里只剩ORDER BY ?或直接报错（如果没加引号）
拦截器能做的有限但实用的事：捕获运行时高危信号
虽然不能“扫描源码”，但在执行阶段仍可识别出明显脱离框架安全机制的行为。关键在于监听 StatementHandler 的 prepare 方法，而不是 Executor：
-
StatementHandler拦截点能拿到原始 SQL 字符串（含未替换的#{}和${}），还能访问ParameterMapping列表 - 若发现 SQL 中存在
${}且对应参数未经过白名单校验（如字段名、表名），立刻告警 - 若
BoundSql.getSql()中出现连续单引号''、分号;、UNION SELECT等字面量，记录日志并标记为可疑 - 检查
MappedStatement.getSqlCommandType()为SELECT时，是否使用了last()、apply()等易出问题的方法（可通过MappedStatement.getId()反查 Mapper 方法名）
真正该用什么工具做注入点扫描
把运行时拦截当“扫描”是本末倒置。生产环境应分层处理：
- 开发阶段：用 IDE 插件（如 IntelliJ 的 MyBatis plugin）或 SonarQube + 自定义规则，匹配
apply(.*\+.*), last(.*\+.*), \${.*}等正则模式 - 测试阶段：结合
mybatis-mapper-xml-validator校验 XML 中的${}使用是否受限于bind或常量 - 上线前：用字节码扫描工具（如 ArchUnit）强制禁止
org.apache.ibatis.scripting.xmltags.XMLScriptBuilder在非白名单类中被反射调用
拦截器唯一不可替代的作用，是作为最后一道防线——当某个 ${tableName} 真的被传入了 user; DROP TABLE config--，它至少能让你在日志里第一眼看到这行 SQL，而不是等 DBA 报警。
