因为#{}仅支持值参数化，无法替代sql语法结构（如order by字段、表名），硬套会导致语法错误或语义错误；必须用${}的三类场景须严格白名单校验。
为什么不能直接把${}换成#{}就完事
因为#{}只能传值，不能动态拼接 SQL 结构。比如 ORDER BY 后面的字段名、FROM 后面的表名、GROUP BY 的列名——这些位置数据库不允许用 ? 占位符，JDBC 会直接报错。硬套 #{column} 会导致 SQL 执行失败，例如变成 ORDER BY 'user_id'（带引号的字符串字面量），数据库当成常量而非列名处理。
哪些地方必须用${}，又怎么控住它
仅三类场景可考虑 ${}，且全部需配合白名单校验：
-
ORDER BY ${column}：column 必须来自预定义枚举或配置项，如["id", "name", "created_at"]，Java 层校验后再透传 -
FROM ${tableName}：多租户分表或归档表切换时使用，表名必须从内部配置中心读取，禁止接收任何前端参数 -
GROUP BY ${groupField}：同理，只允许固定几个业务字段，校验逻辑写死在 service 层，不进 mapper
所有 ${} 出现场景都必须满足：变量值不来自 HTTP 请求体/查询参数/表单提交；不在 <if></if> 或 <choose></choose> 动态块内裸露使用；上线前用 grep -r '\$\{.*\}' src/main/resources/mapper/ 全局扫描并逐个人工确认。
Like 模糊查询的正确写法
这是最常踩坑的地方。错误写法：WHERE username LIKE '%${username}%' —— 直接开后门。正确姿势是让数据库函数处理拼接，保持 #{} 安全通道：
- MySQL：用
CONCAT('%', #{keyword}, '%')，SQL 写成WHERE username LIKE CONCAT('%', #{keyword}, '%') - PostgreSQL：用
||拼接，如WHERE username LIKE '%' || #{keyword} || '%' - Oracle：用
CONCAT或双竖线，避免+（会转成数值加法）
注意：不要在 Java 层拼 "%" + keyword + "%" 再传给 #{xxx}，那只是把风险从 XML 移到 Java，仍可能被绕过（比如 keyword 是 '' OR 1=1 --）。
In 语句怎么安全传多个 ID
WHERE id IN (${ids}) 是典型高危写法，攻击者可注入任意 SQL 片段。也不能写成 WHERE id IN (#{ids})，MyBatis 不支持单个 #{} 展开为逗号列表。
唯一安全方式是用 <foreach></foreach> 标签：
<select id="selectByIds" resulttype="User">
SELECT * FROM user WHERE id IN
<foreach collection="ids" item="id" open="(" separator="," close=")">
#{id}
</foreach></select>
关键点：collection 必须是 List/Array，不能是 String；#{id} 仍在预编译通道里，每个 ID 都单独绑定；separator 用英文逗号，open/close 控制括号，不依赖字符串拼接。
真正难防的不是不知道 ${} 危险，而是没意识到 <bind></bind>、<sql></sql> 片段、注解式 @Select("...${...}") 里也藏了 ${}；更隐蔽的是 generator 自动生成的代码里，order by 默认就用 ${}。别信“我只用了 #{}”，上线前 grep 所有 ${ 才算落地。
