XML解析性能瓶颈主要源于DocumentBuilder线程不安全、StAX/DOM选型不当、命名空间校验开销、MyBatis resultMap反射成本、XSD远程校验、BOM编码问题；应复用Builder、禁用非必要校验、改用注解映射、本地化XSD、绕过Reader层处理BOM。
XML解析器选择直接影响吞吐量
默认的DocumentBuilder（JAXP）在高并发下容易成为瓶颈，因为其线程不安全且每次构建DocumentBuilder实例开销大。SAX和StAX更适合流式、只读场景；DOM适合小文件随机访问，但内存占用随文档大小线性增长。
实操建议：
- 避免在循环中反复调用
DocumentBuilderFactory.newInstance().newDocumentBuilder()，应复用DocumentBuilder实例（注意：它不是线程安全的，需配合ThreadLocal或对象池） - 对大于1MB的XML，优先用
XMLStreamReader（StAX）替代DOM解析，减少内存驻留和GC压力 - 禁用
setNamespaceAware(true)（除非真用命名空间），否则解析器会额外维护前缀/URI映射表，性能下降约15–20%
MyBatis XML映射文件中的<resultMap>嵌套过深引发反射开销
当<resultMap>包含多层<association>或<collection>，且目标类字段多、层级深时，MyBatis会在运行时动态生成ResultHandler并大量调用Field.setAccessible(true)和Field.set()，造成显著反射成本。
实操建议：
- 用
@Results注解 +@Result替代复杂XML<resultMap>，让映射逻辑在编译期绑定，绕过XML解析+反射双重开销 - 对高频查询结果，启用
autoMappingBehavior="NONE"，显式声明所有字段，避免MyBatis自动探测getter/setter带来的遍历开销 - 检查是否误用
<collection fetchType="eager">导致N+1未被抑制——这会触发多次SQL执行+重复解析，比解析本身更耗时
XML Schema校验（XSD）在生产环境开启即拖慢接口响应
MyBatis或Spring整合XML配置时若启用schemaValidation=true（如SqlSessionFactoryBean.setConfigLocation()指向带<!DOCTYPE>的XML），每次加载都会触发XSD下载与本地校验，网络抖动或XSD不可达会导致超时或阻塞。
实操建议：
- 生产环境必须关闭XML Schema校验：
DocumentBuilderFactory.setValidating(false)且setFeature("http://apache.org/xml/features/validation/schema", false) - 若依赖XSD做开发期提示，可将XSD文件本地化，并通过
EntityResolver重写resolveEntity方法返回ClassPathResource，避免HTTP请求 - Spring Boot 2.4+ 默认禁用DTD，但若项目显式配置了
spring.xml.ignore-dtd=false，需手动设为true
字符编码与BOM头导致解析失败或乱码，间接放大性能问题
UTF-8带BOM的XML文件被InputStreamReader以默认编码打开时，BOM（EF BB BF）会被当作非法XML字符，触发SAXParseException: Invalid byte 1 of 1-byte UTF-8 sequence，异常处理本身就会吃掉毫秒级时间，在QPS高的服务中累积明显。
实操建议：
- 统一用
Files.newInputStream(path)配合XmlInputFactory.createXMLStreamReader(InputStream, "UTF-8")（StAX）或InputSource(InputStream)（SAX），跳过Reader层，避免BOM干扰 - CI阶段加入检查脚本，拒绝提交含BOM的XML：
file -i *.xml | grep -i 'utf-8.*with b'
- IDE中设置“Save files without BOM”（IntelliJ：Settings → Editor → File Encodings → UTF-8 without BOM）
<mapper>写了多少行，先确认DocumentBuilder怎么建、XMLStreamReader从哪来、BOM有没有被吃掉。 
