{}能有效防sql注入，因其触发jdbc preparedstatement预编译：sql模板（如select * from user where username = ?）先编译锁定结构，参数值后通过setstring等方法单独绑定，数据库仅视其为纯数据，不解析为语法，故"admin' or 1=1"会被当作字符串字面量安全处理。
MyBatis 的 #{} 能有效防 SQL 注入，核心在于它不拼 SQL，而是交由 JDBC 的 PreparedStatement 做预编译处理——参数值在 SQL 语句结构确定之后才被安全填入，永远作为纯数据，不会参与语法解析。
底层执行流程：先编译，后赋值
MyBatis 遇到 #{username} 时，会把整条 SQL（如 "SELECT * FROM user WHERE username = ?"）先交给数据库预编译。此时数据库已锁定语句结构，后续所有参数都只是往 ? 占位符里“塞值”，驱动自动完成类型适配、单引号包裹（对字符串）、转义特殊字符等操作。攻击者输入的 "admin' OR '1'='1" 会被当作一个完整字符串字面量处理，最终执行的是：
SELECT * FROM user WHERE username = 'admin'' OR ''1''=''1'
这是一条合法但无害的查询，无法改变原有逻辑。
所有值类参数必须用 #{}
只要参数代表的是“数据内容”，而不是“SQL 结构”，一律走 #{}：
- WHERE 条件：
WHERE id = #{id} AND status = #{status} - INSERT 值：
VALUES (#{name}, #{age}, #{email}) - UPDATE 赋值：
SET phone = #{phone}, updated_at = NOW() - DELETE 条件：
WHERE tenant_id = #{tenantId} AND deleted = 0 - IN 查询多个值：
WHERE id IN <foreach item="id" collection="ids" open="(" separator="," close=")">#{id}</foreach>
LIKE 模糊查询的正确写法
LIKE '%#{keyword}%' 是错误写法，MyBatis 不允许在 #{} 外加引号或通配符；LIKE '%${keyword}%' 更危险，等于主动放弃防护。
安全做法只有两种：
-
Java 层拼通配符：Service 中传参前处理为
"%" + keyword + "%"，Mapper XML 中仍写username LIKE #{keyword} -
数据库函数兜底：MySQL 用
CONCAT('%', #{keyword}, '%')；Oracle/PostgreSQL 用'%' || #{keyword} || '%'——函数本身安全，前提是参数仍走#{}
为什么 ${} 一用就出事？
${} 是 MyBatis 在生成 SQL 字符串阶段就做的纯文本替换，数据库还没见到这条语句，结构就已经被改写。例如：
ORDER BY ${sortField} + 输入 id; DROP TABLE user; -- → 实际执行：
SELECT * FROM user ORDER BY id; DROP TABLE user; --
哪怕数据库不支持多语句，攻击者也能用 id, (SELECT SLEEP(5)) 实现延迟盲注或拒绝服务。这种风险不是“可能”，而是“必然”——只要输入不可信，${} 就是注入入口。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
