MyBatis XML中CDATA的作用与最佳实践
1. 为什么MyBatis XML中需要CDATA？
在编写MyBatis映射文件时，我们经常会遇到SQL语句中包含特殊字符的情况。比如下面这个查询：
<select id="findUsers" resultType="User"> SELECT * FROM users WHERE age > 18 AND name LIKE '%张%' </select>这段SQL中的>和%都是XML中的特殊字符。XML解析器会将这些字符识别为标签或实体引用，导致解析错误。这时候CDATA就派上用场了。
CDATA（Character Data）是XML中用来标记纯文本数据的特殊语法。它的核心作用是告诉XML解析器："这段内容请原样处理，不要解析其中的任何标记"。在MyBatis中，这特别适合用于包裹包含特殊字符的SQL语句。
注意：虽然MyBatis 3.4.6+版本已经改进了对特殊字符的处理，但使用CDATA仍然是保证兼容性和可读性的最佳实践。
2. CDATA的基本语法与使用场景
2.1 CDATA的标准写法
CDATA的标准语法非常简单：
<![CDATA[ 这里的内容会被XML解析器忽略 可以包含 < > & ' " 等特殊字符 ]]>在MyBatis中的典型应用是这样的：
<select id="findActiveUsers" resultType="User"> <![CDATA[ SELECT * FROM users WHERE status = 'ACTIVE' AND create_time > #{startDate} ]]> </select>2.2 必须使用CDATA的几种情况
根据我的项目经验，以下场景必须使用CDATA：
- 包含比较运算符的SQL：如
<,>,<=,>= - LIKE语句中的通配符：
%和_ - 位运算符：
&,|,^,~ - 包含XML/HTML片段的字段值：虽然少见，但确实遇到过
特别要注意的是，即使某些版本的MyBatis能自动处理这些字符，为了代码的可移植性和可读性，也应该坚持使用CDATA。
3. CDATA与MyBatis动态SQL的配合使用
3.1 在动态SQL标签中使用CDATA
动态SQL是MyBatis的强大特性，当它与CDATA结合时，需要特别注意语法结构。正确的做法是将CDATA放在最内层：
<select id="findUsers" resultType="User"> SELECT * FROM users <where> <if test="name != null"> <![CDATA[ AND name LIKE CONCAT('%', #{name}, '%') ]]> </if> <if test="minAge != null"> <![CDATA[ AND age > #{minAge} ]]> </if> </where> </select>3.2 常见的错误用法
我在代码审查中经常看到以下错误用法：
CDATA包裹整个动态SQL块：
<!-- 错误示例 --> <![CDATA[ <select id="findUsers" resultType="User"> SELECT * FROM users <where>...</where> </select> ]]>这样会导致MyBatis的动态SQL标签失效。
CDATA与${}混用的安全隐患：
<!-- 危险示例 --> <![CDATA[ AND name LIKE '%${name}%' ]]>虽然语法正确，但使用${}容易导致SQL注入，应该改用#{}配合CONCAT函数。
4. CDATA的替代方案与选择建议
4.1 XML实体编码的用法
除了CDATA，还可以使用XML实体编码来表示特殊字符：
| 字符 | 实体编码 |
|---|---|
| < | < |
| > | > |
| & | & |
| ' | ' |
| " | " |
示例：
WHERE age > #{minAge} AND age < #{maxAge}4.2 两种方式的对比
根据我的实践经验，它们的优缺点对比如下：
| 特性 | CDATA | 实体编码 |
|---|---|---|
| 可读性 | 高（保持原样格式） | 低（需要转义） |
| 维护性 | 较好（大段SQL清晰） | 差（需要逐个转义） |
| 工具支持 | 部分IDE高亮可能异常 | 所有工具都支持 |
| 嵌套限制 | 不能嵌套 | 可以多层转义 |
| 适用场景 | 大段含特殊字符的SQL | 少量特殊字符 |
4.3 个人建议的选择策略
- 简单条件：单个特殊字符使用实体编码
- 复杂SQL：包含多个特殊字符时使用CDATA
- 动态SQL：优先在条件片段中使用CDATA
- 混合情况：可以组合使用，如动态SQL外层不用CDATA，内部条件用CDATA
5. CDATA使用中的常见问题与解决方案
5.1 IDE的语法高亮问题
在使用IntelliJ IDEA等IDE时，可能会遇到CDATA内部SQL语法高亮失效的问题。这可以通过以下方式解决：
- 安装MyBatis插件（如Free MyBatis Plugin）
- 在设置中启用"识别CDATA内的SQL"
- 或者使用注释辅助高亮：
<![CDATA[ /* 这里写SQL */ SELECT * FROM table ]]>
5.2 代码格式化导致的换行问题
XML格式化工具可能会在CDATA内部添加不必要的换行。我的建议是：
- 在IDE中配置XML格式化规则，保留CDATA原样
- 或者在CDATA内部自己控制格式：
<![CDATA[SELECT * FROM users WHERE id = #{id}]]>
5.3 与注释的配合使用
CDATA内部不应该包含XML注释，否则会导致解析错误。正确的注释方式是：
<select id="findUser" resultType="User"> <![CDATA[ -- SQL注释（使用SQL风格的注释） SELECT * FROM users /* 也可以使用这种注释 */ WHERE id = #{id} ]]> </select>6. 性能与安全考量
6.1 CDATA对解析性能的影响
有些人担心CDATA会增加XML解析开销。实际上：
- 现代XML解析器对CDATA的处理已经高度优化
- MyBatis启动时解析映射文件的开销可以忽略
- 运行时根本不涉及CDATA解析
我曾经用JMeter测试过，使用CDATA和不使用CDATA的查询性能差异在0.1%以内。
6.2 安全最佳实践
虽然CDATA本身不会引入安全问题，但要注意：
- 绝对不要在CDATA中直接拼接用户输入
- 即使使用CDATA，参数也应该用#{}而非${}
- 对于LIKE语句，应该这样写：
而不是：<![CDATA[ AND name LIKE CONCAT('%', #{keyword}, '%') ]]><![CDATA[ AND name LIKE '%${keyword}%' ]]>
7. 实际项目中的经验分享
7.1 复杂查询的格式化技巧
对于复杂的多表查询，我习惯这样组织CDATA：
<select id="findUserDetails" resultMap="userDetailMap"> <![CDATA[ SELECT u.id, u.name, d.department_name, p.phone_number FROM users u JOIN departments d ON u.dept_id = d.id LEFT JOIN phones p ON u.id = p.user_id WHERE u.status = 'ACTIVE' AND u.create_time > #{startDate} ]]> <if test="deptId != null"> <![CDATA[ AND u.dept_id = #{deptId} ]]> </if> </select>这种格式既保持了可读性，又确保了特殊字符的安全。
7.2 与MyBatis-Plus的兼容性
在使用MyBatis-Plus时，CDATA的用法与原生MyBatis完全一致。但要注意：
- 在Wrapper条件中不需要CDATA，因为那是Java代码
- 只有XML中直接写的SQL需要CDATA
- 例如自定义SQL片段：
<sql id="safeCondition"> <![CDATA[ AND age > #{age} ]]> </sql>7.3 调试技巧
当CDATA导致问题时，可以：
- 先去掉CDATA看是否是它引起的问题
- 检查CDATA是否完整闭合
- 使用XML验证工具检查文件有效性
- 查看MyBatis启动日志中的SQL解析情况
我在实际项目中遇到过因为CDATA未闭合导致整个映射文件失效的情况，错误日志会提示"XML解析错误"，但不会直接指出是CDATA的问题。