动态XML映射指MyBatis通过、等标签根据参数灵活拼接SQL,而非运行时生成XML;核心是条件可选、安全防注入、避免${}拼接值。

动态 XML 映射在实际开发中通常不是指“运行时生成 XML 文件”,而是指在不修改硬编码 SQL 或映射配置的前提下,让 MyBatis(最常见场景)能根据参数灵活拼接查询条件。核心在于用 、、 等标签实现条件可选,而非真去解析或构造 XML 字符串。
MyBatis 中用 + 实现动态 WHERE 条件
这是最常用、最安全的动态映射方式。MyBatis 在 XML 解析阶段就完成条件判断,不会产生 SQL 注入,也不依赖字符串拼接。
-
会自动处理开头多余的AND或OR,比手写更简洁 - 每个
对应一个可选字段,注意判空逻辑要匹配 Java 参数类型(如Integer用!= null,String建议加trim()判断) - 避免在
test表达式里调用复杂方法(如list.size() > 0),MyBatis 的 OGNL 支持有限,且影响可读性
用 处理 IN 查询和批量插入
当参数是集合(List、Array)时, 是唯一可靠方式。硬拼 IN (#{list[0]}, #{list[1]}) 会报错或被截断。
-
collection属性必须与接口方法参数名一致(若参数是单个集合,用list或array;若封装在对象里,写userIds) -
open/close/separator控制括号和分隔符,item是当前遍历元素别名 - 批量插入时,
内每条VALUES后不能加分号,否则 SQL 语法错误
避免用 或脚本化拼接替代真实动态逻辑
只适合简单字符串预处理(如给参数加前缀),不是动态 SQL 的主力。更危险的是用 ${} 直接拼接(如 ORDER BY ${sortBy}),这等于把参数裸露进 SQL,极易引发注入。
-
${}仅限于明确可控的字段名、表名等元数据,且必须配合白名单校验(如 Java 层判断sortBy是否在["id", "name", "create_time"]中) - 不要用
${}拼接值(如WHERE name = '${name}'),一律改用#{} - MyBatis-Plus 的
QueryWrapper是 Java 层动态构建,和 XML 动态无关,混用反而增加维护成本
XML 映射文件热更新几乎不可行,别指望运行时重载
MyBatis 加载 XML 后会缓存 MappedStatement,修改 XML 文件不会自动生效。开发期靠 IDE 插件(如 MyBatisX)或重启应用;生产环境应视为不可变配置。
- 真正需要“动态”的场景(如用户自定义报表),应转为用
JDBC Template+ 白名单字段 + 预编译参数,而不是折腾 XML - 多个相似查询建议提取公共 SQL 片段(
),复用比复制粘贴更安全 - XML 中嵌套太多
会让可读性骤降,超过 5 个条件时,考虑拆成多个独立语句或用注解方式
真正的难点不在语法,而在于边界:哪些条件必须支持、空值如何语义解释、分页和排序是否也动态、以及多人协作时 XML 格式与命名规范是否统一。这些往往比写对一个 标签更耗精力。










