必须用${}的场景限于表名、字段名、排序方向等sql关键字，误用${}于数据值是注入主因；应改用#{}，并在必须用${}时通过白名单校验确保安全。
绝大多数情况下，${} 不能直接“替换为 #{}”——强行替换会导致 SQL 语法错误，反而让程序跑不起来。真正要解决的是：哪些地方必须用 ${}、哪些地方误用了 ${}、以及在必须用 ${} 的场景下如何守住安全底线。
哪些地方误用了 ${}（该用 #{} 却写了 ${}）
这是生产中最常见的注入源头。典型表现是：参数本应是数据值（如用户 ID、用户名、金额），却用了 ${} 拼进 WHERE / INSERT / UPDATE 子句中。
- 错误写法：
WHERE name = '${name}'或AND status = ${status} - 后果：传入
name="admin' OR '1'='1"就变成WHERE name = 'admin' OR '1'='1'，全表泄露 - 正确做法：统一改为
WHERE name = #{name}、AND status = #{status} - 注意：
#{}会自动加引号（字符串）或转为对应类型（数字/布尔），无需手动拼单引号
哪些地方必须用 ${}（#{} 真的不行）
MyBatis 的 #{} 底层走 JDBC PreparedStatement，所有参数都会被当作「值」处理并加引号或类型绑定；而 SQL 关键字（如表名、字段名、ORDER BY 方向、GROUP BY 表达式）不能加引号，否则 MySQL 直接报错。
- 表名分库分表：
FROM ${tableName}——#{tableName}会变成FROM 'user_202604'，语法错误 - 动态排序：
ORDER BY ${sortField} ${sortOrder}——#{sortField}会变成ORDER BY 'created_time'，字段名变字符串，排序失效 - 动态 LIMIT 偏移：
LIMIT ${(page-1)*size}, #{size}—— 偏移量是表达式，#{}不支持计算，且偏移量不能加引号
必须用 ${} 时怎么防注入（白名单 + 校验是唯一靠谱方案）
没有银弹，不能靠“过滤关键词”或“转义单引号”，因为攻击面太广（比如 UNION SELECT、注释符 --、内联注释 /* */）。唯一可落地的防御是：只允许已知安全的输入。
- 对表名：Java 层定义合法表名数组
String[] validTables = {"user", "order_202601", "order_202602"}，校验Arrays.asList(validTables).contains(tableName) - 对排序字段：用枚举或 Map 映射，例如
Map.of("ctime", "created_time", "utime", "updated_time")，前端只传 key，后端查表转换 - 对排序方向：强制限定为
"asc"或"desc"，其他值一律拒绝或默认"asc" - 绝对不要把用户原始输入（如 HTTP 参数、JSON 字段）不加检查就塞进 ${} —— 这等于给黑客递刀
模糊查询 like 场景的典型陷阱与解法
很多人写 LIKE '%${keyword}%' 图省事，但这是高危写法。正确姿势是让 #{} 承担拼接责任，数据库负责通配符逻辑。
- 错误：
WHERE title LIKE '%${keyword}%'—— keyword=“a%b' OR '1'='1” 直接穿透 - 推荐写法（MySQL）：
WHERE title LIKE CONCAT('%', #{keyword}, '%') - 或 Oracle：
WHERE title LIKE '%' || #{keyword} || '%' - 关键点：通配符由数据库函数包裹，用户输入始终走
#{}预编译，不参与字符串拼接
最易被忽略的一点：MyBatis Generator 自动生成的 XML 中，<sql></sql> 片段和 ORDER BY 子句默认用 ${}，很多人直接拿去用，却没补白名单校验。只要涉及 ${}，就得问一句——这个值是不是完全可控？如果不是，就得加一层 Java 校验或映射转换。
