怎样解决MyBatis中$符号带来的SQL注入风险？关键在于厘清场景
一提到MyBatis中的${}和SQL注入，很多人的第一反应是：“把它换成#{}不就行了？”
其实，这个想法恰恰是问题的开始。真相是：绝大多数情况下，${}不能直接“替换为”#{}——强行替换会导致SQL语法错误，程序根本跑不起来。真正的解决之道，在于搞清楚三个核心问题：哪些地方是误用了${}？哪些地方又不得不用${}？以及在那些必须用的场景下，如何守住安全底线。
哪些地方误用了${}？这是最常见的漏洞源头
生产环境里，绝大部分SQL注入漏洞都源于此。典型表现是：参数本应是纯粹的数据值（比如用户ID、搜索关键词、订单金额），却被错误地用${}拼接进了WHERE、INSERT或UPDATE子句中。
- 错误写法示例：
WHERE name = '${name}'或者AND status = ${status} - 后果有多严重？如果用户传入
name="admin' OR '1'='1"，SQL就会变成WHERE name = 'admin' OR '1'='1'，直接导致全表数据泄露。 - 正确做法：统一改为
WHERE name = #{name}和AND status = #{status}。 - 这里有个细节：
#{}会自动处理类型，字符串会加引号，数字或布尔值会做对应转换，完全不需要手动拼接单引号。
哪些地方必须用${}？#{}真的无能为力
为什么不能全用#{}？因为它的底层是JDBC的PreparedStatement，所有参数都会被当作“值”来处理，并加上引号或进行类型绑定。而SQL语法中的某些部分，比如表名、字段名、ORDER BY后的排序方向、GROUP BY表达式，它们本身是“标识符”或“关键字”，绝对不能加引号，否则数据库会直接报语法错误。
- 动态表名（如分库分表）：
FROM ${tableName}。如果写成FROM #{tableName}，就会变成FROM 'user_202604'，语法错误。 - 动态排序：
ORDER BY ${sortField} ${sortOrder}。如果字段名用了#{}，会变成ORDER BY 'created_time'，字段名被当成字符串，排序失效。 - 动态分页的偏移量：
LIMIT ${(page-1)*size}, #{size}。偏移量往往是个表达式，#{}不支持计算，而且偏移量作为数字也不能加引号。
必须用${}时，如何防御注入？白名单校验是唯一靠谱的方案
到了这一步，没有“银弹”。别指望靠过滤几个关键词或者转义单引号就能万事大吉，攻击面太广了（比如UNION SELECT、注释符--、内联注释/* */）。唯一能落地、真正有效的防御策略就是：只允许已知安全的输入。
- 对动态表名：在Ja va层定义合法的表名数组，比如
String[] validTables = {"user", "order_202601", "order_202602"}，然后严格校验传入值是否在名单内：Arrays.asList(validTables).contains(tableName)。 - 对排序字段：使用枚举或Map进行映射。例如，建立一个映射关系：
Map.of("ctime", "created_time", "utime", "updated_time")。前端只传递“ctime”这样的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} || '%'。 - 关键点：通配符
%由数据库的字符串连接函数（如CONCAT）包裹，用户输入的值始终通过#{}走预编译，完全不参与SQL字符串的拼接。
最后，还有一个极易被忽略的“坑”：MyBatis Generator等工具自动生成的XML代码中，ORDER BY子句默认可能使用${}。很多人直接复制使用，却忘了补充白名单校验。记住，只要代码中间出现了${}，就必须问自己一句：这个值是完全由我控制的吗？如果答案是否定的，那么就必须在Ja va层加上一层严格的校验或映射转换。这才是守住安全防线的关键所在。
