DOM解析大XML文件会OOM，因为其将整个XML树一次性加载进内存，内存占用取决于元素总数及属性/文本长度，而非文件大小；应改用SAX或StAX流式解析，边读边提取关键字段映射为轻量结构。
DOM解析大XML文件为什么会OOM
因为DOM会把整个XML树一次性加载进内存，节点越多、嵌套越深、文本越长，占用的堆空间就越大。哪怕文件只有50MB，实际内存占用可能飙到1.5GB以上——JVM没报错，OutOfMemoryError: Java heap space直接炸。
- 典型场景：解析日志归档XML、导出的数据库备份XML、GIS元数据文件
- 不是文件大小决定OOM，而是元素总数和属性/文本长度；一个含10万
<record></record>的扁平文件比10MB但深度嵌套20层的文件更危险 -
DocumentBuilder.parse(InputStream)底层仍会缓冲全部字节，即使你传的是FileInputStream
改用SAX或StAX替代DOM的实操要点
SAX是推模式、事件驱动，StAX是拉模式、可控迭代，二者都不建完整对象树，内存占用基本恒定（通常
- SAX必须继承
DefaultHandler，重写startElement/endElement/characters；注意characters可能被分段回调，需用StringBuilder拼接 - StAX用
XMLStreamReader，调nextTag()跳过空白，用getEventType() == XMLStreamConstants.START_ELEMENT判断节点类型 - 别在
characters()里直接存String——大文本（如CDATA里的base64）会瞬间吃光内存；应写入临时文件或流式处理
DOM解析时强制限制节点数和深度
如果必须用DOM（比如下游强依赖org.w3c.dom.Document），至少得加防护，避免解析失控的XML。
- 用
DocumentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)禁用DTD，防XXE和实体爆炸 - 设置
builder.setEntityResolver(new NoOpEntityResolver())，丢弃所有外部实体引用 - 自定义
ContentHandler包装DOMBuilder，在startElement里计数：超过50万节点或深度>100时抛RuntimeException中断解析 - JVM参数加
-Xmx512m -XX:+HeapDumpOnOutOfMemoryError，方便事后确认是不是真被XML撑爆
流式提取关键字段后转轻量结构
90%的业务其实只要XML里的几个字段（比如<id></id>、<timestamp></timestamp>、<status></status>），没必要保全树形。用StAX边读边映射成Map<string string></string>或自定义POJO，再批量入库或转发。
- 示例：遇到
START_ELEMENT且getLocalName().equals("record")，就new一个Record；后续遇到START_ELEMENT是id，下个CHARACTERS就是值 - 避免用
getElementById或XPath查DOM——这会让整个树驻留内存；StAX里用hasNext()+skipChildren()快速跳过无关分支 - 如果下游要XML片段，别拼字符串！用
Transformer配合DOMSource（仅针对当前小节点）生成，不污染主解析流
真正难的不是换解析器，是识别哪些字段必须保序、哪些可丢弃、哪些需校验长度——这些逻辑藏在业务规则里，不在XML Schema上。
