1. 从一次SQL报错说起为什么XML里写个小于号都能翻车刚接触MyBatis那会儿我在Mapper XML里写了一个再普通不过的条件查询where age 30。启动项目调用接口控制台直接甩给我一个红彤彤的异常堆栈大意是XML解析失败标签没闭合。我当时盯着那行SQL看了半天心想这不就是个小于号吗怎么就成了标签了这个问题的根源在于MyBatis的Mapper XML文件本质上是一个XML文档而XML文档有自己的语法规则。在XML里和是用来界定标签的元字符是用来界定实体引用的元字符。你在SQL里写age 30XML解析器看到就以为你要开始一个新标签它往后找30想找到标签名结果发现后面跟的是空格和数字直接判定语法错误。所以这不是MyBatis的bug而是XML规范的要求。任何在XML文档中出现的、与XML语法冲突的字符都必须用实体引用Entity Reference的形式转义。MyBatis作为构建在XML之上的框架自然继承了这个约束。这篇文章就是把这个看似简单、实则坑点密集的话题彻底讲透。我会从五个特殊符号的转义写法讲起延伸到CDATA的取舍、动态SQL中的实战陷阱、不同数据库的兼容性问题最后给出一套可以直接抄作业的排查清单。不管你是刚学MyBatis的新手还是写了几年CRUD但一直没搞明白为什么有时候要写lt;有时候要写![CDATA[的老手这篇内容都能帮你把这块知识补完整。2. 五个特殊符号的转义规则与底层逻辑2.1 XML预定义实体五个必须记住的映射关系XML规范预定义了五个实体引用这是所有XML文档通用的规则不是MyBatis特有的。你必须记住这张表原始字符实体引用说明在SQL中的常见场景amp;和号XML中用于实体引用的起始位运算a b、字符串拼接lt;小于号XML中用于标签起始比较运算age 30gt;大于号XML中用于标签结束比较运算age 18quot;双引号XML中用于属性值界定字符串常量activeapos;单引号XML中用于属性值界定字符串常量pending这里有个很多人忽略的细节字符在XML中其实不是必须转义的。XML规范只强制要求转义和因为这两个字符会直接破坏文档结构。单独出现时解析器能正确处理但规范建议转义以保持一致性。而和只在特定上下文属性值内部才需要转义。那为什么MyBatis场景下我们通常五个都转义因为SQL语句里这些符号出现的频率太高统一转义比逐个判断上下文要省心得多。我个人的习惯是只要在XML的SQL片段里看到这五个字符一律转义不给自己留判断负担。2.2 为什么lt;能工作而不能解析器的视角要真正理解这个问题得站在XML解析器的角度想一遍。当你写select idselectByAge select * from user where age 30 /select解析器逐字符扫描遇到时进入标签开始状态它期待接下来是一个标签名字母开头。结果读到的是空格非法报错。整个过程解析器根本不知道你在写SQL它只认XML语法。当你写lt;时解析器遇到进入实体引用状态读到lt查表得到字符然后把它作为文本内容输出。最终MyBatis拿到的SQL字符串里就是真正的符号数据库执行时完全正常。这个机制的关键在于转义发生在XML解析阶段而不是SQL执行阶段。MyBatis从XML里读出来的已经是还原后的SQL文本了。所以你在日志里看到的SQL是age 30而不是age lt; 30这是正常的。2.3 一个容易混淆的点转义后的SQL在日志里长什么样很多人第一次配MyBatis日志的时候会懵我明明写的是lt;为什么打印出来的SQL是是不是没生效不是没生效恰恰是生效了。MyBatis的日志打印的是解析还原之后的SQL也就是真正发给数据库的那条语句。如果你在日志里看到的是lt;那才说明出问题了——意味着转义没有被正确解析或者你在某个不该转义的地方转了义。我建议你在调试阶段打开MyBatis的SQL日志确认两件事一是XML能正常解析不报错二是日志里的SQL是你期望的原始形式。这两点都满足说明转义写法没问题。3. CDATA的诱惑什么时候该用什么时候是给自己挖坑3.1 CDATA的语法与适用边界除了实体引用XML还提供了另一种处理特殊字符的方式CDATA区块。语法是![CDATA[ 你的内容 ]]在这个区块内所有字符都被当作纯文本解析器不做任何标签或实体解析。select idselectByAge ![CDATA[ select * from user where age 30 and status 0 ]] /select看起来很美对吧不用一个个转义了。但CDATA有个硬性限制它不能嵌套。而且CDATA区块内不能包含]]这个结束标记如果你的SQL里恰好有这种组合虽然罕见就会出问题。更关键的是CDATA在MyBatis的动态SQL场景下会带来麻烦。看这个例子select idselectByCondition ![CDATA[ select * from user where age #{maxAge} ]] if teststatus ! null and status #{status} /if /select这段代码能跑但CDATA区块把SQL切成了两段可读性变差。如果SQL更长、动态标签更多CDATA和if、where、foreach混在一起维护起来非常痛苦。3.2 我的选择标准什么情况下用CDATA经过多个项目的实践我总结了一个简单的判断标准纯静态SQL、特殊符号密集用CDATA。比如一段包含大量、的比较逻辑或者一段复杂的数学计算SQLCDATA能让代码干净很多。动态SQL、条件分支多用实体引用。因为CDATA会把区块内的所有内容变成纯文本你没法在CDATA里面写if标签只能把CDATA切碎反而更乱。混合场景优先实体引用只在个别符号密集的片段用CDATA包裹。还有一个实际经验团队协作时统一用实体引用。因为CDATA的边界不直观新人接手时容易在CDATA区块里误写动态标签导致不生效排查半天。实体引用虽然写起来啰嗦但意图明确不容易出错。3.3 CDATA与动态标签混用的真实翻车案例我遇到过这样一个场景同事写了一段SQLselect idqueryOrders ![CDATA[ select * from orders where create_time #{endTime} ]] if teststatus ! null and status #{status} /if ![CDATA[ order by create_time desc ]] /select这段代码本身能跑但问题在于如果status为null生成的SQL是select * from orders where create_time ? order by create_time desc没问题。但如果后续有人想在order by前面加一个动态的limit条件就得再切一次CDATA。切来切去SQL的可读性急剧下降。后来我们统一改成实体引用写法select idqueryOrders select * from orders where create_time lt; #{endTime} if teststatus ! null and status #{status} /if order by create_time desc /select清爽多了。这个案例告诉我们CDATA适合包裹完整的、不需要动态拼接的SQL片段而不是用来切割动态SQL。4. 动态SQL里的特殊符号那些让你加班到深夜的陷阱4.1if标签中的比较运算最容易踩的坑动态SQL是MyBatis的核心卖点但也是特殊符号问题的高发区。看这段代码select idselectUsers select * from user where if testage ! null and age 30 and age #{age} /if /where /select这段代码会报错因为if的test属性里写了。属性值里的同样需要转义if testage ! null and age lt; 30 and age #{age} /if但这里有个更隐蔽的问题OGNL表达式里的字符串比较。如果你写if testtype A单引号在属性值里通常没问题但如果属性值本身用单引号包裹就会冲突。MyBatis的test属性一般用双引号包裹内部字符串用单引号这样是安全的。但如果你写成if testtype A也能跑但不推荐因为团队里容易有人混用导致解析异常。统一用双引号包属性、单引号包字符串这是我踩过几次坑之后定下的规矩。4.2foreach中的分隔符与特殊字符foreach标签的separator属性经常需要用到逗号、or、and等这些一般没问题。但如果你在open或close属性里写了特殊符号就要注意了foreach collectionids itemid open( close) separator, #{id} /foreach这里的括号和逗号都是安全的。但如果你的SQL片段里需要拼接符号比如某些数据库的字符串拼接就得转义foreach collectionlist itemitem separator amp; #{item} /foreach这种情况比较少见但一旦遇到不转义就是解析错误。4.3test属性中的OGNL与XML转义的双重解析这是最烧脑的部分。if test...里的内容会经历两层解析先XML解析再OGNL解析。所以你在test里写的表达式既要符合XML语法又要符合OGNL语法。举个例子判断一个字符串是否包含某个子串if testname ! null and name.indexOf(张) ! -1这里没有特殊符号没问题。但如果要判断数值范围if testscore gt; 60 and score lt; 100和里的和都必须转义。我见过有人只转义了忘了结果在某些解析器版本下能跑换个环境就报错。统一转义不要赌解析器的宽容度。还有一个经典坑if testtype A or type B里的or是OGNL的关键字没问题。但如果你写type A || type B||在XML里是合法字符OGNL也支持能跑。不过为了可读性我建议用or和and而不是符号。5. 不同数据库下的特殊符号处理差异5.1 MySQL与Oracle转义规则一致但SQL语法有差异XML层面的转义规则是通用的跟数据库无关。但不同数据库的SQL语法对特殊符号的使用有差异这会影响你在XML里怎么写。比如字符串拼接MySQL用concat(a, b)或a || b取决于模式Oracle用a || b。||在XML里是合法字符不需要转义。但如果你用做位运算MySQL和Oracle都支持XML里就必须写成amp;。再比如正则表达式MySQL 8.0支持regexp_replaceOracle也支持。正则里经常出现\、[、]、(、)等字符这些在XML里大部分是安全的只有、、需要转义。但正则里的和用于断言时如(?...)就必须转义。5.2 分页插件与特殊符号的交互MyBatis的分页插件如PageHelper会在原SQL基础上拼接limit或rownum条件。这个过程通常不涉及特殊符号问题但如果你手写的SQL里已经包含了limit再叠加分页插件就会冲突。更隐蔽的是分页插件解析SQL时可能会对特殊符号敏感。我遇到过在SQL里用做位运算分页插件在count查询时解析出错的情况。解决办法是确保XML里的转义正确让插件拿到的是还原后的SQL。5.3 缓存与特殊符号二级缓存的key生成MyBatis的二级缓存以SQL语句和参数生成缓存key。如果你在SQL里用了特殊符号转义后的文本和还原后的文本在key生成时可能不一致导致缓存命中率下降。实测下来MyBatis在生成缓存key时用的是解析还原后的SQL所以只要XML解析正常缓存key就是稳定的。但如果你在动态SQL里用了CDATA和实体引用混写要确保最终生成的SQL文本一致否则同样的查询条件可能生成不同的key。6. 一套可直接复用的排查清单与实操建议6.1 报错信息对照表看到什么错就知道哪里出了问题报错关键词可能原因排查方向The content of element type select must matchXML标签未闭合或特殊符号未转义检查SQL里的、、Error parsing Mapper XMLXML语法错误用XML校验工具检查整个文件Could not resolve type alias类型别名配置问题检查typeAlias配置与特殊符号无关SQLSyntaxErrorExceptionSQL语法错误检查转义后的SQL在数据库里是否能执行OGNL expression parsing errortest属性表达式错误检查test里的特殊符号转义6.2 我的日常检查流程每次写完Mapper XML我会按这个顺序过一遍全局搜索特殊符号在IDE里搜索、、确认每一个都在合适的位置标签内还是SQL文本内。检查test属性所有if、when的test属性里比较运算符是否转义。确认CDATA边界如果用了CDATA确认区块内没有动态标签区块外没有遗漏的转义。跑一次单元测试用最小数据集触发每个动态分支看日志里的SQL是否符合预期。换数据库验证如果项目支持多数据库至少在两个数据库上各跑一次。6.3 几个能省时间的实操技巧技巧一用IDE的XML格式化功能。IntelliJ IDEA对MyBatis的Mapper XML有很好的支持格式化之后标签层级一目了然未闭合的标签会直接标红。技巧二装一个MyBatis插件。IDEA的MyBatisX或Free MyBatis Plugin能提供SQL高亮、跳转、参数提示写复杂动态SQL时效率提升明显。技巧三日志级别调到DEBUG。在application.yml里配logging: level: com.example.mapper: debug这样能看到每条SQL的完整输出包括参数和结果排查转义问题非常直接。技巧四写一个最小的复现用例。遇到解析报错时不要在大文件里改来改去新建一个只有几行的Mapper XML把可疑的SQL片段放进去快速定位问题符号。6.4 关于面试中这个知识点的回答思路MyBatis面试题里经常问XML里特殊符号怎么处理很多人只答用转义字符这不够。完整的回答应该包含XML预定义实体的五个映射关系CDATA的适用场景和限制动态SQL中test属性的双重解析问题实际项目中如何选择转义方式如果你能把这几点讲清楚面试官会知道你真正写过、踩过坑而不是背的八股文。7. 写在最后一些个人体会这个知识点本身不复杂但它是MyBatis使用中最容易反复踩的坑之一。我见过工作三五年的开发遇到XML解析报错还是第一反应去搜mybatis 小于号 转义搜完改完下次又忘。我的建议是不要靠记忆靠工具和流程。把IDE的XML校验打开把日志级别调好把检查清单固化到自己的开发习惯里。特殊符号转义这件事写的时候多花十秒钟比报错之后花半小时排查要划算得多。另外如果你在维护一个老项目发现Mapper XML里CDATA和实体引用混用得乱七八糟不要一次性全改。按模块逐步统一每次改完跑一遍回归测试。我试过在一个大项目里一次性替换所有CDATA结果因为某个SQL片段里恰好有]]组合导致解析失败回滚了一次才搞定。渐进式重构稳。 MyBatis XML特殊符号转义：从报错到精通的实战指南
1. 从一次SQL报错说起为什么XML里写个小于号都能翻车刚接触MyBatis那会儿我在Mapper XML里写了一个再普通不过的条件查询where age 30。启动项目调用接口控制台直接甩给我一个红彤彤的异常堆栈大意是XML解析失败标签没闭合。我当时盯着那行SQL看了半天心想这不就是个小于号吗怎么就成了标签了这个问题的根源在于MyBatis的Mapper XML文件本质上是一个XML文档而XML文档有自己的语法规则。在XML里和是用来界定标签的元字符是用来界定实体引用的元字符。你在SQL里写age 30XML解析器看到就以为你要开始一个新标签它往后找30想找到标签名结果发现后面跟的是空格和数字直接判定语法错误。所以这不是MyBatis的bug而是XML规范的要求。任何在XML文档中出现的、与XML语法冲突的字符都必须用实体引用Entity Reference的形式转义。MyBatis作为构建在XML之上的框架自然继承了这个约束。这篇文章就是把这个看似简单、实则坑点密集的话题彻底讲透。我会从五个特殊符号的转义写法讲起延伸到CDATA的取舍、动态SQL中的实战陷阱、不同数据库的兼容性问题最后给出一套可以直接抄作业的排查清单。不管你是刚学MyBatis的新手还是写了几年CRUD但一直没搞明白为什么有时候要写lt;有时候要写![CDATA[的老手这篇内容都能帮你把这块知识补完整。2. 五个特殊符号的转义规则与底层逻辑2.1 XML预定义实体五个必须记住的映射关系XML规范预定义了五个实体引用这是所有XML文档通用的规则不是MyBatis特有的。你必须记住这张表原始字符实体引用说明在SQL中的常见场景amp;和号XML中用于实体引用的起始位运算a b、字符串拼接lt;小于号XML中用于标签起始比较运算age 30gt;大于号XML中用于标签结束比较运算age 18quot;双引号XML中用于属性值界定字符串常量activeapos;单引号XML中用于属性值界定字符串常量pending这里有个很多人忽略的细节字符在XML中其实不是必须转义的。XML规范只强制要求转义和因为这两个字符会直接破坏文档结构。单独出现时解析器能正确处理但规范建议转义以保持一致性。而和只在特定上下文属性值内部才需要转义。那为什么MyBatis场景下我们通常五个都转义因为SQL语句里这些符号出现的频率太高统一转义比逐个判断上下文要省心得多。我个人的习惯是只要在XML的SQL片段里看到这五个字符一律转义不给自己留判断负担。2.2 为什么lt;能工作而不能解析器的视角要真正理解这个问题得站在XML解析器的角度想一遍。当你写select idselectByAge select * from user where age 30 /select解析器逐字符扫描遇到时进入标签开始状态它期待接下来是一个标签名字母开头。结果读到的是空格非法报错。整个过程解析器根本不知道你在写SQL它只认XML语法。当你写lt;时解析器遇到进入实体引用状态读到lt查表得到字符然后把它作为文本内容输出。最终MyBatis拿到的SQL字符串里就是真正的符号数据库执行时完全正常。这个机制的关键在于转义发生在XML解析阶段而不是SQL执行阶段。MyBatis从XML里读出来的已经是还原后的SQL文本了。所以你在日志里看到的SQL是age 30而不是age lt; 30这是正常的。2.3 一个容易混淆的点转义后的SQL在日志里长什么样很多人第一次配MyBatis日志的时候会懵我明明写的是lt;为什么打印出来的SQL是是不是没生效不是没生效恰恰是生效了。MyBatis的日志打印的是解析还原之后的SQL也就是真正发给数据库的那条语句。如果你在日志里看到的是lt;那才说明出问题了——意味着转义没有被正确解析或者你在某个不该转义的地方转了义。我建议你在调试阶段打开MyBatis的SQL日志确认两件事一是XML能正常解析不报错二是日志里的SQL是你期望的原始形式。这两点都满足说明转义写法没问题。3. CDATA的诱惑什么时候该用什么时候是给自己挖坑3.1 CDATA的语法与适用边界除了实体引用XML还提供了另一种处理特殊字符的方式CDATA区块。语法是![CDATA[ 你的内容 ]]在这个区块内所有字符都被当作纯文本解析器不做任何标签或实体解析。select idselectByAge ![CDATA[ select * from user where age 30 and status 0 ]] /select看起来很美对吧不用一个个转义了。但CDATA有个硬性限制它不能嵌套。而且CDATA区块内不能包含]]这个结束标记如果你的SQL里恰好有这种组合虽然罕见就会出问题。更关键的是CDATA在MyBatis的动态SQL场景下会带来麻烦。看这个例子select idselectByCondition ![CDATA[ select * from user where age #{maxAge} ]] if teststatus ! null and status #{status} /if /select这段代码能跑但CDATA区块把SQL切成了两段可读性变差。如果SQL更长、动态标签更多CDATA和if、where、foreach混在一起维护起来非常痛苦。3.2 我的选择标准什么情况下用CDATA经过多个项目的实践我总结了一个简单的判断标准纯静态SQL、特殊符号密集用CDATA。比如一段包含大量、的比较逻辑或者一段复杂的数学计算SQLCDATA能让代码干净很多。动态SQL、条件分支多用实体引用。因为CDATA会把区块内的所有内容变成纯文本你没法在CDATA里面写if标签只能把CDATA切碎反而更乱。混合场景优先实体引用只在个别符号密集的片段用CDATA包裹。还有一个实际经验团队协作时统一用实体引用。因为CDATA的边界不直观新人接手时容易在CDATA区块里误写动态标签导致不生效排查半天。实体引用虽然写起来啰嗦但意图明确不容易出错。3.3 CDATA与动态标签混用的真实翻车案例我遇到过这样一个场景同事写了一段SQLselect idqueryOrders ![CDATA[ select * from orders where create_time #{endTime} ]] if teststatus ! null and status #{status} /if ![CDATA[ order by create_time desc ]] /select这段代码本身能跑但问题在于如果status为null生成的SQL是select * from orders where create_time ? order by create_time desc没问题。但如果后续有人想在order by前面加一个动态的limit条件就得再切一次CDATA。切来切去SQL的可读性急剧下降。后来我们统一改成实体引用写法select idqueryOrders select * from orders where create_time lt; #{endTime} if teststatus ! null and status #{status} /if order by create_time desc /select清爽多了。这个案例告诉我们CDATA适合包裹完整的、不需要动态拼接的SQL片段而不是用来切割动态SQL。4. 动态SQL里的特殊符号那些让你加班到深夜的陷阱4.1if标签中的比较运算最容易踩的坑动态SQL是MyBatis的核心卖点但也是特殊符号问题的高发区。看这段代码select idselectUsers select * from user where if testage ! null and age 30 and age #{age} /if /where /select这段代码会报错因为if的test属性里写了。属性值里的同样需要转义if testage ! null and age lt; 30 and age #{age} /if但这里有个更隐蔽的问题OGNL表达式里的字符串比较。如果你写if testtype A单引号在属性值里通常没问题但如果属性值本身用单引号包裹就会冲突。MyBatis的test属性一般用双引号包裹内部字符串用单引号这样是安全的。但如果你写成if testtype A也能跑但不推荐因为团队里容易有人混用导致解析异常。统一用双引号包属性、单引号包字符串这是我踩过几次坑之后定下的规矩。4.2foreach中的分隔符与特殊字符foreach标签的separator属性经常需要用到逗号、or、and等这些一般没问题。但如果你在open或close属性里写了特殊符号就要注意了foreach collectionids itemid open( close) separator, #{id} /foreach这里的括号和逗号都是安全的。但如果你的SQL片段里需要拼接符号比如某些数据库的字符串拼接就得转义foreach collectionlist itemitem separator amp; #{item} /foreach这种情况比较少见但一旦遇到不转义就是解析错误。4.3test属性中的OGNL与XML转义的双重解析这是最烧脑的部分。if test...里的内容会经历两层解析先XML解析再OGNL解析。所以你在test里写的表达式既要符合XML语法又要符合OGNL语法。举个例子判断一个字符串是否包含某个子串if testname ! null and name.indexOf(张) ! -1这里没有特殊符号没问题。但如果要判断数值范围if testscore gt; 60 and score lt; 100和里的和都必须转义。我见过有人只转义了忘了结果在某些解析器版本下能跑换个环境就报错。统一转义不要赌解析器的宽容度。还有一个经典坑if testtype A or type B里的or是OGNL的关键字没问题。但如果你写type A || type B||在XML里是合法字符OGNL也支持能跑。不过为了可读性我建议用or和and而不是符号。5. 不同数据库下的特殊符号处理差异5.1 MySQL与Oracle转义规则一致但SQL语法有差异XML层面的转义规则是通用的跟数据库无关。但不同数据库的SQL语法对特殊符号的使用有差异这会影响你在XML里怎么写。比如字符串拼接MySQL用concat(a, b)或a || b取决于模式Oracle用a || b。||在XML里是合法字符不需要转义。但如果你用做位运算MySQL和Oracle都支持XML里就必须写成amp;。再比如正则表达式MySQL 8.0支持regexp_replaceOracle也支持。正则里经常出现\、[、]、(、)等字符这些在XML里大部分是安全的只有、、需要转义。但正则里的和用于断言时如(?...)就必须转义。5.2 分页插件与特殊符号的交互MyBatis的分页插件如PageHelper会在原SQL基础上拼接limit或rownum条件。这个过程通常不涉及特殊符号问题但如果你手写的SQL里已经包含了limit再叠加分页插件就会冲突。更隐蔽的是分页插件解析SQL时可能会对特殊符号敏感。我遇到过在SQL里用做位运算分页插件在count查询时解析出错的情况。解决办法是确保XML里的转义正确让插件拿到的是还原后的SQL。5.3 缓存与特殊符号二级缓存的key生成MyBatis的二级缓存以SQL语句和参数生成缓存key。如果你在SQL里用了特殊符号转义后的文本和还原后的文本在key生成时可能不一致导致缓存命中率下降。实测下来MyBatis在生成缓存key时用的是解析还原后的SQL所以只要XML解析正常缓存key就是稳定的。但如果你在动态SQL里用了CDATA和实体引用混写要确保最终生成的SQL文本一致否则同样的查询条件可能生成不同的key。6. 一套可直接复用的排查清单与实操建议6.1 报错信息对照表看到什么错就知道哪里出了问题报错关键词可能原因排查方向The content of element type select must matchXML标签未闭合或特殊符号未转义检查SQL里的、、Error parsing Mapper XMLXML语法错误用XML校验工具检查整个文件Could not resolve type alias类型别名配置问题检查typeAlias配置与特殊符号无关SQLSyntaxErrorExceptionSQL语法错误检查转义后的SQL在数据库里是否能执行OGNL expression parsing errortest属性表达式错误检查test里的特殊符号转义6.2 我的日常检查流程每次写完Mapper XML我会按这个顺序过一遍全局搜索特殊符号在IDE里搜索、、确认每一个都在合适的位置标签内还是SQL文本内。检查test属性所有if、when的test属性里比较运算符是否转义。确认CDATA边界如果用了CDATA确认区块内没有动态标签区块外没有遗漏的转义。跑一次单元测试用最小数据集触发每个动态分支看日志里的SQL是否符合预期。换数据库验证如果项目支持多数据库至少在两个数据库上各跑一次。6.3 几个能省时间的实操技巧技巧一用IDE的XML格式化功能。IntelliJ IDEA对MyBatis的Mapper XML有很好的支持格式化之后标签层级一目了然未闭合的标签会直接标红。技巧二装一个MyBatis插件。IDEA的MyBatisX或Free MyBatis Plugin能提供SQL高亮、跳转、参数提示写复杂动态SQL时效率提升明显。技巧三日志级别调到DEBUG。在application.yml里配logging: level: com.example.mapper: debug这样能看到每条SQL的完整输出包括参数和结果排查转义问题非常直接。技巧四写一个最小的复现用例。遇到解析报错时不要在大文件里改来改去新建一个只有几行的Mapper XML把可疑的SQL片段放进去快速定位问题符号。6.4 关于面试中这个知识点的回答思路MyBatis面试题里经常问XML里特殊符号怎么处理很多人只答用转义字符这不够。完整的回答应该包含XML预定义实体的五个映射关系CDATA的适用场景和限制动态SQL中test属性的双重解析问题实际项目中如何选择转义方式如果你能把这几点讲清楚面试官会知道你真正写过、踩过坑而不是背的八股文。7. 写在最后一些个人体会这个知识点本身不复杂但它是MyBatis使用中最容易反复踩的坑之一。我见过工作三五年的开发遇到XML解析报错还是第一反应去搜mybatis 小于号 转义搜完改完下次又忘。我的建议是不要靠记忆靠工具和流程。把IDE的XML校验打开把日志级别调好把检查清单固化到自己的开发习惯里。特殊符号转义这件事写的时候多花十秒钟比报错之后花半小时排查要划算得多。另外如果你在维护一个老项目发现Mapper XML里CDATA和实体引用混用得乱七八糟不要一次性全改。按模块逐步统一每次改完跑一遍回归测试。我试过在一个大项目里一次性替换所有CDATA结果因为某个SQL片段里恰好有]]组合导致解析失败回滚了一次才搞定。渐进式重构稳。