怎样在MyBatis动态生成的XML中强制使用SQL参数化绑定？

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 文本——这个过程是受控的、可审计的、且 #{} 一定生效。一旦跳出这个机制，就只能靠编码规范和人工校验兜底。