MyBatis中仅#{}支持参数化绑定，${}仅为字符串拼接；表名、列名等元数据需白名单校验，动态SQL应通过<if>等标签在XML中生成，而非运行时拼接含#{ }的字符串。
不能“强制”在动态生成的 XML 中使用参数化绑定——因为 MyBatis 的 ${} 本质就是字符串拼接，它不经过 PreparedStatement，也就没有参数化一说。真正能参数化的只有 #{}，且它只对值（value）生效，不能用于表名、列名、排序字段等元数据。
为什么 ${sql} 看似“参数化”实则危险
常见错误是把整个 SQL 字符串塞进 Map，再用 ${sql} 插入：
<select id="dynamicSql" parameterType="map" resultType="map">
${sql}
</select>这种写法看似灵活，但只要 sql 值来自用户输入（比如前端传的 "select * from user where name = 'admin' -- "），就会直接执行任意 SQL。MyBatis 不会对 ${} 做任何转义或预编译。
-
${}是在 XML 解析阶段就完成字符串替换，等同于 Java 的String.format() - 即使你在 Map 里给
code字段用了#{code}，它也不会被解析——因为#{}只在 MyBatis 动态标签（如<if>）内部、且由 MyBatis 自己解析的 SQL 片段中才有效 - 你传进去的
"select count(*) from user where code like #{code}"这个字符串，里面的#{code}就是纯文本，不会被 MyBatis 识别为参数占位符
真正安全的参数化：必须让 #{} 出现在 MyBatis 解析的 SQL 上下文中
要让 MyBatis 对参数做 PreparedStatement 绑定，#{} 必须写在 XML 的静态/动态 SQL 片段里，而不是运行时拼进字符串里。
- ✅ 正确：SQL 结构固定，仅值可变 → 全部用
#{} - ✅ 正确：结构需动态（如条件开关）→ 用
<if test="xxx != null">AND name = #{name}</if> - ❌ 错误：把带
#{}的字符串当值传进来，指望它被二次解析 - ❌ 错误：用
${tableName}拼表名后，再幻想里面嵌套的#{}能起作用
示例对比：
<!-- ✅ 安全：MyBatis 真正解析并绑定 -->
<select id="getUserByCode" resultType="map">
SELECT * FROM user WHERE code LIKE #{code}
</select>
<p><!-- ❌ 危险：${sql} 是纯字符串替换，#{code} 不会被识别 -->
<select id="unsafeDynamic" parameterType="map">
${sql} <!-- 传入 "SELECT * FROM user WHERE code LIKE #{code}" —— 这里的 #{code} 就是字面量 -->
</select>需要动态表名/列名时，如何兼顾灵活性与安全性
表名、排序字段、GROUP BY 列等属于 SQL 元数据，无法用 #{} 参数化。这时只能靠白名单校验 + 显式限制，而非“强制参数化”。
- 在 Java 层严格校验输入：比如
tableName只允许是"user"、"order"、"product"等预设值 - 用
${}拼接前先通过Enum或Set<String>进行白名单匹配，不匹配则抛异常 - 避免从 HTTP 参数、JSON body 直接取值拼 SQL；优先用固定枚举或配置项驱动
- 如果真要支持任意列排序，至少拆成两层：
sortField（白名单校验） +sortOrder（只允许"ASC"/"DESC"）
例如：
<select id="listUsers" resultType="map">
SELECT * FROM user
<if test="sortField != null and sortField == 'name'">
ORDER BY name ${sortOrder}
</if>
<if test="sortField != null and sortField == 'created_time'">
ORDER BY created_time ${sortOrder}
</if>
</select>Provider 类是更可控的替代方案
当你发现 XML 动态 SQL 写起来越来越绕，又不想裸用 ${}，@SelectProvider 是更清晰的选择。它把 SQL 构建逻辑移到 Java 方法里，你能完全控制拼接过程，并手动做白名单检查。
- SQL 字符串由 Java 方法返回，MyBatis 仍只认其中的
#{}作为参数占位符 - 你可以用
StringBuilder拼接表名、列名，但必须自己校验合法性 - 参数值仍走
#{}，保证 PreparedStatement 绑定
示例：
public class UserSqlProvider {
public String listUsers(Map<String, Object> params) {
String table = (String) params.get("table");
if (!Arrays.asList("user", "admin_user").contains(table)) {
throw new IllegalArgumentException("Invalid table: " + table);
}
return "SELECT * FROM " + table + " WHERE status = #{status}";
}
}
<p>// 接口上
@SelectProvider(type = UserSqlProvider.class, method = "listUsers")
List<Map<String, Object>> listUsers(@Param("table") String table, @Param("status") int status);最易被忽略的一点：所谓“动态生成 SQL”，不是指运行时拼字符串，而是指 MyBatis 在执行前根据参数条件，用内置标签（<if>、<choose>、<foreach>）实时生成最终 SQL 文本——这个过程是受控的、可审计的、且 #{} 一定生效。一旦跳出这个机制，就只能靠编码规范和人工校验兜底。
