✅ #{ } 是唯一能防 SQL 注入的写法：它通过 JDBC PreparedStatement 将参数作为独立数据绑定，数据库仅将其视为字符串值；❌ ${ } 是纯字符串拼接，无任何防护，直接将用户输入嵌入 SQL，极易引发注入攻击。
#{ } 是唯一能防 SQL 注入的写法
MyBatis 中只有 #{} 能真正防御 SQL 注入，${} 本身不提供任何防护机制——它就是字符串拼接，传什么就拼什么。数据库看到的不是参数，而是你拼出来的完整 SQL 文本。哪怕只漏校验一个字段，攻击者就能用 ' OR '1'='1 或 ; DROP TABLE user; -- 直接执行任意语句。
为什么 #{ } 能拦住恶意输入？
因为 #{} 触发的是 JDBC 的 PreparedStatement 流程：
- MyBatis 把
#{id}替换成?占位符，SQL 发给数据库时是固定结构，比如SELECT * FROM user WHERE id = ? - 参数值通过
setLong(1, id)或setString(1, value)单独绑定，数据库只把它当「数据」处理，不会解析为语法 - 即使传入
"1; DROP TABLE user; --"，最终执行的也只是WHERE id = '1; DROP TABLE user; --'—— 一条查不到结果的普通查询
哪些地方非得用 ${ }？
${} 不是“可以不用”，而是 JDBC 层面不允许用 #{} 的硬性场景：
- 表名：
SELECT * FROM ${tableName}——#{tableName}会加单引号变成FROM 'user'，直接报错 - 列名或排序字段：
ORDER BY ${column} ${orderType}——#{orderType}会变成ORDER BY name 'ASC'，语法错误 - GROUP BY、LIMIT 偏移量等无法加引号的语法位置
这些地方用 ${} 不是图省事，是没得选。
用 ${ } 时最容易忽略的安全动作
很多人以为“加个正则”或“限制长度”就够了，其实远远不够：
- 白名单必须硬编码：比如排序字段只允许
Set.of("id", "name", "created_at")，前端传sort=user_name，后端映射成真实列名"name" - 表名需双重校验：先匹配正则
^[a-zA-Z][a-zA-Z0-9_]{2,31}$，再查数据库元信息确认该表真实存在 - 绝对禁止用户直传字段名/表名：所有动态片段都应来自配置或枚举，而不是前端 raw input
没走这几步，${column} 和裸写 Statement 没本质区别。
