MyBatis XML里写大于小于号总报错？试试这两种写法，别再硬编码了
MyBatis XML特殊符号避坑指南：转义与CDATA的实战抉择
每次在MyBatis的XML映射文件中写SQL，最让人抓狂的莫过于那些看似普通的比较运算符突然变成XML解析器的眼中钉。明明在数据库客户端运行完美的SQL，放到XML里就频繁报错——这几乎是每个Java开发者都会遇到的"入门礼"。今天我们就来彻底解决这个看似简单却困扰无数人的技术痛点。
1. 问题根源：XML语法与SQL符号的冲突本质
XML文档本质上是一种标记语言，它的核心语法依赖于尖括号（<和>）来定义标签。当我们在MyBatis的XML文件中编写包含比较运算符的SQL时，解析器会误将这些符号识别为XML标签的开始或结束。例如下面这段看似正常的SQL：
<select id="findActiveUsers" resultType="User"> SELECT * FROM users WHERE last_login_time < NOW() - INTERVAL 30 DAY AND status = 'ACTIVE' </select>实际上会导致XML解析错误，因为解析器会把< NOW()中的小于号当作新标签的开始。这种冲突在编写动态SQL时尤为常见，特别是当我们在<if>、<when>等标签内使用比较运算符时，问题会变得更加隐蔽。
XML中需要转义的主要特殊符号包括：
| 符号 | 实体引用 | 常见使用场景 |
|---|---|---|
| < | < | 小于比较、XML标签开始 |
| > | > | 大于比较、XML标签结束 |
| & | & | 逻辑AND、URL参数连接 |
| " | " | 字符串界定符 |
| ' | ' | 字符串界定符(单引号) |
2. 解决方案一：XML实体转义的精准应用
实体转义是最直接的解决方案，其核心思想是用预定义的字符实体替代特殊符号。这种方法特别适合处理简单的比较运算场景。让我们看一个完整的示例：
<select id="selectProductsByPriceRange" resultType="Product"> SELECT * FROM products WHERE price >= #{minPrice} AND price <= #{maxPrice} <if test="category != null"> AND category = #{category} </if> </select>实体转义的三大优势：
- 精确控制：每个符号都有明确的对应实体，转义范围清晰
- 可读性平衡：虽然比原生符号稍显复杂，但保持了SQL的整体结构
- 兼容性强：所有XML解析器都支持标准实体引用
但在复杂动态SQL中，过度使用实体引用会导致代码可读性急剧下降。例如：
<select id="selectComplexQuery" resultType="Result"> SELECT * FROM table WHERE 1=1 <if test="param1 > 0"> AND column1 < #{param1} </if> <if test="param2 != null and param2 < 100"> AND column2 > #{param2} </if> </select>提示：在IntelliJ IDEA中，可以使用
Ctrl+Alt+L快捷键快速格式化包含实体引用的XML，这能显著改善代码的可读性。
3. 解决方案二：CDATA区块的战术运用
CDATA(Character Data)区块提供了一种"整体豁免"的解决方案，特别适合以下场景：
- SQL中包含大量特殊符号
- 需要保持SQL的原始格式
- 动态SQL中的复杂条件判断
典型的CDATA使用方式如下：
<select id="findRecentOrders" resultType="Order"> <![CDATA[ SELECT o.*, u.username FROM orders o JOIN users u ON o.user_id = u.id WHERE o.create_time > DATE_SUB(NOW(), INTERVAL 7 DAY) AND o.status IN ('PAID', 'SHIPPED') ]]> </select>CDATA与实体转义的对比决策矩阵：
| 考量维度 | 实体转义更适合 | CDATA更适合 |
|---|---|---|
| 符号数量 | 少量特殊符号(2-3处) | 多个特殊符号或复杂表达式 |
| SQL复杂度 | 简单条件查询 | 多表关联、子查询等复杂SQL |
| 动态SQL | 适合<if>等标签外的静态部分 | 适合包裹整个复杂SQL块 |
| 可维护性 | 需要逐个符号处理 | 整体包裹，内部可自由使用原生符号 |
| 工具链支持 | 所有IDE都能识别 | 部分工具可能不会高亮CDATA内语法 |
一个常见的误区是在动态SQL标签内部使用CDATA，这通常会导致意料之外的问题。正确的做法应该是：
<!-- 推荐做法 --> <select id="dynamicQuery" resultType="Map"> SELECT * FROM data <where> <if test="minValue != null"> <![CDATA[ AND value >= #{minValue} ]]> </if> <if test="maxValue != null"> <![CDATA[ AND value <= #{maxValue} ]]> </if> </where> </select> <!-- 不推荐做法 --> <select id="dynamicQuery" resultType="Map"> <![CDATA[ SELECT * FROM data WHERE 1=1 <if test="minValue != null"> AND value >= #{minValue} </if> ]]> </select>4. 高级场景：混合策略与性能考量
在实际企业级应用中，我们往往需要根据SQL的不同部分采用混合策略。以下是一个结合两种方案的典型案例：
<select id="searchProducts" resultType="Product"> SELECT id, name, price FROM products <where> <if test="keywords != null"> AND name LIKE CONCAT('%', #{keywords}, '%') </if> <if test="minPrice != null"> <![CDATA[ AND price >= #{minPrice} ]]> </if> <if test="maxPrice != null"> <![CDATA[ AND price <= #{maxPrice} ]]> </if> <if test="categories != null"> AND category_id IN <foreach item="item" collection="categories" open="(" separator="," close=")"> #{item} </foreach> </if> AND status <> 'DISCONTINUED' </where> ORDER BY <choose> <when test="sortBy == 'price'">price</when> <when test="sortBy == 'name'">name</when> <otherwise>created_at DESC</otherwise> </choose> </select>性能方面的深度考量：
- 解析效率：实体引用需要XML解析器额外处理，但现代解析器的差异可以忽略
- 缓存影响：MyBatis会缓存解析后的SQL，两种方案最终生成的SQL相同
- 网络传输：CDATA区块可能略微增加XML文件大小，但gzip压缩后差异不大
- 预处理语句：两种方案最终都会转换为标准的JDBC预处理语句
在Spring Boot项目中，可以通过配置MyBatis的日志级别来观察最终生成的SQL：
# application.properties logging.level.org.mybatis=DEBUG这会在控制台输出实际执行的SQL，你可以验证特殊符号是否被正确处理。例如：
-- 转义方案生成的SQL SELECT * FROM products WHERE price > ? AND price < ? -- CDATA方案生成的SQL SELECT * FROM products WHERE price > ? AND price < ?5. 工程化实践：团队协作中的最佳方案
在多人协作项目中，保持代码风格统一至关重要。以下是我们在实际项目中总结的规范：
基础规则：
- 简单的比较运算（
<,>,<=,>=）优先使用实体转义 - 复杂SQL片段或包含多个特殊符号时使用CDATA
- 动态SQL标签(
<if>,<foreach>等)内部避免使用CDATA
- 简单的比较运算（
IDE配置技巧：
- 在IntelliJ IDEA中安装MyBatis插件，可以获得更好的XML SQL支持
- 配置Live Template快速生成CDATA区块：
<![CDATA[ $SELECTION$ ]]> - 使用代码风格设置统一实体引用格式
代码审查要点：
- 检查是否所有特殊符号都得到正确处理
- 避免CDATA嵌套导致的解析问题
- 确保动态SQL中的条件表达式正确转义
测试策略：
@Test void testSpecialCharactersInXml() { try (SqlSession session = sqlSessionFactory.openSession()) { UserMapper mapper = session.getMapper(UserMapper.class); List<User> users = mapper.selectUsersByAge(18, 30); assertFalse(users.isEmpty()); } }
对于使用MyBatis-Plus的项目，虽然其Wrapper API可以避免XML中的符号问题，但复杂SQL仍然需要回到XML映射文件。这时上述规则同样适用：
// MyBatis-Plus的Wrapper写法避免了XML符号问题 QueryWrapper<User> wrapper = new QueryWrapper<>(); wrapper.gt("age", 18).lt("age", 30).eq("status", "ACTIVE"); userMapper.selectList(wrapper);在大型项目中，我们通常会建立代码模板库，包含各种常见场景的MyBatis XML示例，新成员可以快速参考这些模板避免常见错误。例如：
<!-- 分页查询模板 --> <select id="selectByPage" resultType="com.example.Entity"> <![CDATA[ SELECT * FROM table WHERE create_time > #{startDate} ORDER BY id DESC LIMIT #{offset}, #{pageSize} ]]> </select> <!-- 批量更新模板 --> <update id="batchUpdate"> UPDATE table SET <foreach collection="list" item="item" separator=","> column_#{item.field} = #{item.value} </foreach> WHERE id IN <foreach collection="list" item="item" open="(" separator="," close=")"> #{item.id} </foreach> </update>经过多个项目的实践验证，我们发现合理组合使用转义和CDATA方案，配合团队规范，可以显著减少XML解析问题，同时保持代码的可读性和可维护性。当遇到特别复杂的SQL时，也可以考虑将其移至注解或Provider类中，但这需要权衡可维护性和灵活性。