dom解析大文件会卡住，因其将整个xml加载进内存构建树，10mb文件可能占用300mb堆空间并引发gc压力；sax事件驱动、内存恒定但需手动维护上下文；stax在性能与易用性间取得平衡，适合多数场景。
DOM解析为什么在大文件上明显卡住
DOM会把整个XML加载进内存构建成树，文件越大，内存占用和初始化时间越长。10MB的XML可能吃掉300MB堆空间，GC压力陡增，DocumentBuilder.parse() 调用直接变慢半秒以上。
- 适合场景：
Document需要频繁随机访问、反复修改节点（比如配置重写） - 致命坑：没设
DocumentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)，可能触发XXE攻击 - 性能开关：用
DocumentBuilderFactory.setNamespaceAware(false)关闭命名空间处理，快15%~20%
SAX解析快但容易漏掉上下文信息
SAX是事件驱动，边读边触发startElement()、characters()，不存整棵树，内存恒定在KB级。但characters() 可能被多次调用（尤其含CDATA或换行时），直接拼接char[]易丢数据。
- 典型错误：
StringBuffer.append(ch, start, length)写错参数顺序，或忽略ignorableWhitespace()干扰 - 必须手动维护栈：用
Stack<string></string>记录当前路径，否则无法判断“/root/item/name”在哪一层 - 不支持回溯：遇到
<item id="100"></item>时，attributes.getValue("id")必须当场保存，后面拿不到
StAX的XMLStreamReader才是平衡点
StAX像“可暂停的SAX”，用next() 和 hasNext() 控制流，内存低、逻辑直，且能按需跳过子树。比SAX少写30%胶水代码，又比DOM省90%内存。
- 关键技巧：用
reader.getElementText()替代手动循环读CHARACTERS，自动合并分片文本 - 跳过无关节点：
reader.skip()比逐个next()快2倍，尤其面对大量注释或空格 - 注意兼容性：
Woodstox实现比JDK自带javax.xml.stream快40%，但需显式添加依赖，否则XMLInputFactory.newInstance()可能回落到慢实现
真实场景下的选择逻辑
别只看“谁最快”，要看你真正要做什么。一个5MB的订单XML，如果只要提取order/id和order/total两个字段，StAX跑完只要8ms；DOM却要120ms建树+GC停顿。
立即学习“Java免费学习笔记（深入）”；
- 只取少数字段 → 用StAX，
XMLStreamReader+if (name.equals("id")) value = reader.getElementText() - 要校验结构+修改后写回 → DOM更稳，但务必限制最大文件尺寸（如超2MB抛
IllegalArgumentException） - 流式处理超大日志XML（GB级）→ SAX，但必须用
ByteBuffer缓冲+异步写磁盘，避免System.out.println()拖慢吞吐
最容易被忽略的是字符编码。所有解析器默认用UTF-8，但XML声明里写encoding="GBK"时，FileInputStream不套InputStreamReader就直接乱码——这个错不会报异常，只会静默解析出错数据。
