${} 直接拼SQL导致SQL注入，因其绕过PreparedStatement、不转义不校验，仅作字符串替换；误用场景如WHERE/AND/LIKE/IN中该用#{}却用${}，正确做法是数据值一律用#{}，表名/排序字段/分页偏移等结构化参数必须用${}但需白名单校验。
为什么 ${} 直接拼进 SQL 就会执行恶意代码
因为 ${} 不走 JDBC 的 PreparedStatement 流程，MyBatis 解析完就原样塞进 SQL 字符串里，数据库收到的是已经“组装好”的完整语句。用户输入的任何内容，只要语法合法，就会被当作 SQL 逻辑执行。
常见错误现象：
- 传入
name="admin' OR '1'='1"→ 生成WHERE username = 'admin' OR '1'='1'，条件恒真 - 传入
sort="id; DROP TABLE user; --"→ 实际执行两条语句，第二条被数据库接受并运行 - 传入
keyword="'; SELECT version(); --"→ 在模糊查询中触发额外查询，泄露数据库版本
这些都不是“意外”，而是 ${} 的设计行为：它就是字符串替换，不加引号、不转义、不校验类型。
哪些地方误用了 ${}（该用 #{} 却写了 ${}）
绝大多数注入漏洞都出在这里——把本该是「数据值」的地方，错当成「SQL 结构」来拼接。
-
WHERE name = '${name}'→ 必须改为WHERE name = #{name} -
AND status = ${status}→ 必须改为AND status = #{status}（#{}会自动处理int/boolean类型，不用手动转） -
LIKE '%${keyword}%'→ 必须改为LIKE CONCAT('%', #{keyword}, '%')或数据库适配写法（如 PostgreSQL 用||） -
IN (${idList})→ 不能简单替换为IN (#{idList})，要用#{}动态展开
关键判断标准：这个参数是不是最终要作为「值」出现在 SQL 里？如果是，#{} 是唯一安全选择。
哪些地方真的不能用 #{}（必须用 ${} 且必须白名单校验）
#{} 会给所有参数加引号或绑定类型，导致 SQL 语法错误。只有三类结构无法避免 ${}：
- 表名：
FROM ${tableName}→#{tableName}会变成FROM 'user_202605'，MySQL 报错 - 排序字段与方向：
ORDER BY ${sortField} ${sortOrder}→#{sortField}变成ORDER BY 'created_time'，按字符串字面值排序，失效 - LIMIT 偏移量：
LIMIT ${(page-1)*size}, #{size}→ 偏移量是表达式，#{}不支持计算，且不能加引号
但注意：这些场景下，${} 的输入绝不能直接来自 HTTP 请求体或 query 参数。必须经过 Java 层强校验，例如：
- 表名 → 从预设数组
String[] validTables = {"user", "order_202605"}中匹配 - 排序字段 → 映射为枚举：
SortField.ID("id"), SortField.NAME("user_name") - 排序方向 → 强制限定为
"asc"或"desc"，其他值一律拒绝
扫描工具报 ${} 风险，能不能只改写法不改逻辑
不能靠把 ${} 改成 ##{} 或重写 TextSqlNode 来绕过扫描。这既没解决真实风险，又掩盖了问题根源。
真正要做的，是分清两类情况：
- 误用
${}的地方 → 立即替换成#{}，配合 - 确需
${}的地方 → 在调用前插入白名单校验逻辑，确保传入值在允许范围内，并在代码注释里明确标注“此处需 ${}，已校验”
最易被忽略的一点：动态 SQL 块里混用 ${} 会让整个块失去防护意义。比如 sort 是攻击者可控的，就等于开门揖盗。
