优先选用StAX解析器替代DOM，因其支持拉模式遍历、可跳过无关节点；XPath需预编译复用并避免//全树扫描；高频字段应注册自定义XmlAdapter绕过反射；映射中须规避I/O操作与资源未关闭问题。
XML解析器选型直接影响映射速度
DOM 解析器会把整个 XML 加载进内存构建树结构，document.getElementsByTagName 看似方便，但对 10MB+ 文件极易触发 OutOfMemoryError 或 GC 频繁。SAX 和 StAX 更适合大文件映射：SAX 是事件驱动、只读、不可回退；StAX（如 javax.xml.stream.XMLStreamReader）支持拉模式遍历，能边读边映射，且可跳过无关节点。
实操建议：
- 优先用 StAX 替代 DOM，尤其当只需提取部分字段（如只取
<order>下的<id>和<amount>） - 避免在
startElement回调里做对象构造或数据库写入——先缓存关键值，等完整读完再批量处理 - 若必须用 DOM，设置
DocumentBuilderFactory.setFeature("http://apache.org/xml/features/dom/defer-node-expansion", true)延迟展开子树
避免 XPath 在循环中重复编译
每次调用 XPathExpression.evaluate() 前若都用 xpath.compile("//item/name")，JVM 会反复解析表达式语法树，开销显著。尤其在映射千条记录时，可能多耗 200ms+。
实操建议：
- 将
XPathExpression提前编译并复用，例如作为类静态字段或 Spring Bean 的依赖 - 慎用
//开头的表达式——它强制全树扫描；改用绝对路径如/root/items/item/name或结合local-name()过滤 - 若 XML 结构固定，直接用 StAX 跳转到目标标签更轻量，比 XPath 快 3–5 倍
自定义类型转换器减少反射开销
通用映射框架（如 JAXB、Jackson XML）默认通过反射调用 setter 或字段赋值，而 Integer.valueOf()、LocalDateTime.parse() 等转换也常被反复反射触发。在高吞吐场景下，这部分可能占映射总耗时 40% 以上。
实操建议：
- 为高频字段（如
<created>2023-05-12T10:30:00Z</created>）注册自定义XmlAdapter，内部用DateTimeFormatter.ISO_INSTANT直接解析，绕过反射 - JAXB 中禁用
@XmlAccessorType(XmlAccessType.FIELD)改用PROPERTY并确保 getter/setter 无逻辑，避免意外副作用 - 考虑用
Record类 + 手动 StAX 映射替代全量注解方案，省去运行时元数据扫描
XMLStreamReader reader = factory.createXMLStreamReader(inputStream);
while (reader.hasNext()) {
int event = reader.next();
if (event == XMLStreamConstants.START_ELEMENT) {
if ("order".equals(reader.getLocalName())) {
String id = reader.getAttributeValue(null, "id");
// 直接读属性，不走 XPath，不建 Node 对象
orders.add(new Order(id, parseAmount(reader.getElementText())));
}
}
}
真正卡顿的往往不是解析本身，而是映射过程中混入了日志、验证、远程调用或未关闭的 InputStream——这些会让看似线性的 XML 处理变成 I/O 瓶颈。盯紧你的 close() 和 try-with-resources。
