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：

1. 包含比较运算符的SQL：如<,>,<=,>=
2. LIKE语句中的通配符：%和_
3. 位运算符：&,|,^,~
4. 包含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 常见的错误用法

我在代码审查中经常看到以下错误用法：

1. CDATA包裹整个动态SQL块：

   <!-- 错误示例 --> <![CDATA[ <select id="findUsers" resultType="User"> SELECT * FROM users <where>...</where> </select> ]]>

   这样会导致MyBatis的动态SQL标签失效。

2. CDATA与${}混用的安全隐患：

   <!-- 危险示例 --> <![CDATA[ AND name LIKE '%${name}%' ]]>

   虽然语法正确，但使用${}容易导致SQL注入，应该改用#{}配合CONCAT函数。

4. CDATA的替代方案与选择建议

4.1 XML实体编码的用法

除了CDATA，还可以使用XML实体编码来表示特殊字符：

示例：

WHERE age > #{minAge} AND age < #{maxAge}

4.2 两种方式的对比

根据我的实践经验，它们的优缺点对比如下：

4.3 个人建议的选择策略

1. 简单条件：单个特殊字符使用实体编码
2. 复杂SQL：包含多个特殊字符时使用CDATA
3. 动态SQL：优先在条件片段中使用CDATA
4. 混合情况：可以组合使用，如动态SQL外层不用CDATA，内部条件用CDATA

5. CDATA使用中的常见问题与解决方案

5.1 IDE的语法高亮问题

在使用IntelliJ IDEA等IDE时，可能会遇到CDATA内部SQL语法高亮失效的问题。这可以通过以下方式解决：

1. 安装MyBatis插件（如Free MyBatis Plugin）
2. 在设置中启用"识别CDATA内的SQL"
3. 或者使用注释辅助高亮：

   <![CDATA[ /* 这里写SQL */ SELECT * FROM table ]]>

5.2 代码格式化导致的换行问题

XML格式化工具可能会在CDATA内部添加不必要的换行。我的建议是：

1. 在IDE中配置XML格式化规则，保留CDATA原样
2. 或者在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解析开销。实际上：

1. 现代XML解析器对CDATA的处理已经高度优化
2. MyBatis启动时解析映射文件的开销可以忽略
3. 运行时根本不涉及CDATA解析

我曾经用JMeter测试过，使用CDATA和不使用CDATA的查询性能差异在0.1%以内。

6.2 安全最佳实践

虽然CDATA本身不会引入安全问题，但要注意：

1. 绝对不要在CDATA中直接拼接用户输入
2. 即使使用CDATA，参数也应该用#{}而非${}
3. 对于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完全一致。但要注意：

1. 在Wrapper条件中不需要CDATA，因为那是Java代码
2. 只有XML中直接写的SQL需要CDATA
3. 例如自定义SQL片段：

<sql id="safeCondition"> <![CDATA[ AND age > #{age} ]]> </sql>

7.3 调试技巧

当CDATA导致问题时，可以：

1. 先去掉CDATA看是否是它引起的问题
2. 检查CDATA是否完整闭合
3. 使用XML验证工具检查文件有效性
4. 查看MyBatis启动日志中的SQL解析情况

我在实际项目中遇到过因为CDATA未闭合导致整个映射文件失效的情况，错误日志会提示"XML解析错误"，但不会直接指出是CDATA的问题。