每个人都可以，
拥有SSL证书

在Mapper XML里写SQL，偶尔需要用到小于号、大于号这些，直接把符号丢进去是不行的——XML解析器会把它当成标签起始，启动就报错，通常是个SAXParseException。第一次遇到的时候我还以为MyBatis哪儿出bug了，查了一圈才发现是要转义。

这东西不复杂，但每次都得处理，踩过两次坑之后基本就固定套路了。

用得最多的是XML预定义的实体转义。小于号<写成<，大于号>写成>，这两个很直接。容易被忽略的是&符号，它必须写成&，不然解析器会以为你要声明一个实体引用，然后抛一个“实体未定义”的错误。至于单引号和双引号，对应的转义符是'和"，实际在SQL里很少用到——除非你在标签属性值里硬要用到引号，那个场景比较罕见，知道有这回事就行。

动态SQL里典型的场景是<if>标签的判断条件。

比如想过滤出未成年用户，写成age < 18就会炸，必须改成age < 18。静态SQL同理，SELECT * FROM users WHERE age < 30这个查询得写成WHERE age < 30。如果你刚好在写那种拼接了一堆条件的查询，满屏<和>看着确实有点眼花。

这时候另一个方案就出来了：CDATA区块。

用<![CDATA[ ... ]]>把包含特殊符号的那段SQL包起来，解析器会原样处理里面的内容，<就不用转义了。比如查30岁以下的用户，直接写成：

<select id="selectYoungUsers" resultType="User">
    SELECT * FROM users
    <where>
        <![CDATA[ age < 30 ]]>
    </where>
</select>

一整段SQL里如果夹杂了一堆特殊符号，用CDATA能省不少事，读起来也更干净。

但有个小坑：CDATA区块里不能再出现]]>，那是结束标志。要是SQL里真有这种字符串（极少见），就得把]]>拆开，或者改用实体转义拼接。

实际干活的时候两种方案经常混着用。比如静态部分很复杂，直接一个CDATA包住，但是动态条件里还要拼<if>之类的标签，那部分就不能用CDATA包了，只能老老实实写<。混用没问题，关键是别把自己绕进去——动态标签的判断表达式始终是不能放进CDATA里的，那里是XML的活区。

说下自己怎么选。零星一两个比较符号，手写实体转义其实更直观，比如age < 18 AND score > 60，一眼就知道是“小于”“大于”，不需要跳出去看是不是被CDATA包了。如果遇上那种老长一段带嵌套或很多运算符的SQL，全转义写起来又累又容易漏，直接上CDATA是更省眼睛的选择。团队里最好定个统一的倾向，有的文件全用实体，有的文件满篇CDATA，切来切去阅读成本会高一些——尤其是遗留代码里两种混得乱七八糟，排查问题得先对上眼神，烦得很。

线上要是突然因为一个没转义的<挂掉，定位其实很快，日志会很直接地告诉你XML解析失败了。只是这种本可以在本地启动时就暴露的问题拖到发布后才发现，确实有点亏。养成写完随便跑一下的习惯就好，别等打包完才看到那一行红字。