DOM适合小XML文件，因全量加载内存占用大；SAX无内存压力但只能顺序读取；StAX兼顾低内存与可控性，支持拉模式解析和精准错误定位。
DOM 解析器内存占用大，适合小 XML 文件
DOM 会把整个 XML 文档加载进内存，构建成一棵完整的树形结构。这意味着你随时能随机访问任意节点，但代价是内存开销直接和文件大小成正比。OutOfMemoryError 是常见报错，尤其处理几十 MB 以上的 XML 时几乎必然触发。
- 适用场景：
DocumentBuilder.parse()后需频繁增删查改节点，比如配置文件校验、模板生成 - 不推荐用于：日志归档 XML、数据库导出 XML、流式上报数据等体积不可控的场景
- 注意
setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)，否则可能引发 XXE 攻击
SAX 解析器无内存压力，但只能单向顺序读取
SAX 是事件驱动模型，边读边触发 startElement()、characters()、endElement() 回调，不保留节点树。它内存恒定（通常几 KB），解析百 MB 文件也毫无压力，但无法回退或跳转。
- 典型错误：在
characters()回调里直接用new String(ch, start, length)拼接文本——XML 可能分多次回调，导致内容截断 - 正确做法：用
StringBuilder缓存字符片段，在endElement()时统一处理 - 不支持 XPath，也不能修改文档结构；适合纯解析提取字段，比如解析 RSS、SOAP 响应体中的关键值
StAX 解析器兼顾可控性与低内存，Java 6+ 原生支持
StAX 是拉模式（pull parsing），程序主动调用 next() 或 nextTag() 推进解析位置，既不像 DOM 那样全载入，也不像 SAX 那样被动响应。你可以随时暂停、跳过子树、甚至写回 XML。
-
XMLStreamReader的getAttributeValue(null, "id")比 SAX 的attributes.getValue("id")更直观，参数语义清晰 - 注意
hasNext()和isStartElement()的组合使用，避免漏判空元素或自闭合标签 - 兼容性：JDK 6 起内置，但老项目若用 WebLogic 10.3 等容器，可能默认加载旧版
stax-api，导致NoClassDefFoundError: javax.xml.stream.XMLStreamException
选型关键不在“快”，而在“控制粒度”和“错误容忍度”
DOM 失败时你能拿到完整树，方便调试；SAX 出错就停在某一行，堆栈里只有 parse()；StAX 错误定位最准，getLocation().getLineNumber() 直接指向出问题的 XML 行号。真正棘手的是混合场景：比如要提取某个大 XML 中嵌套三层的几百个 <item></item>，又得对每个做简单校验——这时 StAX 的 skipElement() 和按需读取才是解法，硬上 DOM 会 OOM，死磕 SAX 容易状态管理失控。
