mybatis防sql注入的核心是使用#{}进行预编译参数绑定，禁用${}字符串拼接；#{}交由preparedstatement处理，参数作为纯数据不参与sql解析，而${}直接拼入sql，无任何转义，等同于手动拼接statement，极易引发注入。
MyBatis 本身不靠“配置”防 SQL 注入，靠写法——用 #{} ，禁用 ${} ，这是最直接、最有效的防线。
为什么不能靠拦截器或 Filter 拦 SQL 注入？
很多人一想到“防注入”就去写 HandlerInterceptor 或自定义 Filter，结果白忙活：
-
HandlerInterceptor.preHandle()拿不到原始请求体（比如 JSON 的getInputStream()），对 POST Body、文件上传字段、Header 完全失效 - 正则匹配关键词（如
or 1=1、union select）误杀率高——用户昵称叫Orion、搜索词含order by就被拦 - Filter 若没加
@Component或没控制好加载顺序（比如在 Spring Security 之后），根本不会生效 - 它只是补丁，不是根治；真正该拦的地方是数据库访问层，不是 HTTP 入口
MyBatis 中必须禁用 ${} ，除非你明确需要动态表名或 order by 字段
${} 是字符串拼接，不做任何转义，等价于手写 Statement + + 拼接，天然带注入风险。常见踩坑点：
-
SELECT * FROM ${tableName}—— 表名来自用户输入？危险 -
ORDER BY ${sortField}—— 字段名未白名单校验？危险 -
WHERE name LIKE '%${name}%'—— 这是典型错误写法，应改用#{}配合CONCAT或<bind></bind> - MyBatis-Plus 的
QueryWrapper.like("name", value)内部自动用#{}，安全；但若手动写eq("name", "${value}")就破防
前后模糊查询（%name%）的安全写法
别碰 ${} ，用这三种方式之一，全部基于预编译：
- XML 中用
CONCAT：WHERE name LIKE CONCAT('%', #{name}, '%') - XML 中用
<bind></bind>：<bind name="pattern" value="'%' + name + '%'"></bind> WHERE name LIKE #{pattern} - MyBatis-Plus 直接调
queryWrapper.like("name", name)—— 底层已封装好，无需操心
注意：MySQL 8.0+ 支持 CONCAT，若用旧版或 PostgreSQL，可改用 WHERE name LIKE '%' || #{name} || '%'（PostgreSQL）或数据库函数适配。
真正难的不是写代码，而是守住边界
团队里最容易出问题的，不是不会写 #{} ，而是：
- 某次紧急上线，为“快速支持动态排序”，悄悄在 DAO 层放开
${sortField}，又忘了加白名单校验 - 新同学复制了老代码里的
${}模式，以为“能跑就行”，没看注释也没查文档 - SQL 日志开启后把
#{}参数值原样打出来，导致密码、身份证号泄露
防注入不是加个过滤器就完事，是每次写 SQL 时下意识问一句：“这个值，我敢让它进 PreparedStatement 吗？”
