Java 处理 XML，就像是在给一堆杂乱的毛衣拆线。
很多人觉得这玩意儿过时了，毕竟 JSON 早就统治了互联网通信。
但在企业级后台、配置文件以及那些古老的遗留系统里，XML 依然是绕不开的大山。
今天咱们不聊虚的，直接钻进 Java 解析 XML 的核心逻辑，看看底层的肌肉是怎么练成的。
DOM 解析：笨重但全知全能
DOM（Document Object Model）是最直观的解析方式。
它的逻辑很简单：把整个 XML 文件一次性读入内存，变成一棵完整的树状结构。
你可以把它想象成把一本厚书复印下来，然后拿着放大镜逐页查找。
这种方式的好处是随机访问极其方便，你想改哪个节点，直接 getElementById 就行。
缺点也很致命：如果文件很大，比如几百兆的配置文档，内存瞬间就会爆掉。
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(new File("config.xml"));
这段代码虽然简单，但背后隐藏着一个巨大的坑。
它在解析过程中会构建大量的 Node 对象，GC 压力极大。
所以，除非你需要频繁修改 XML 结构，或者文件极小，否则别轻易用它。
SAX 解析：流式处理的极致效率
如果说 DOM 是复印全书，那 SAX（Simple API for XML）就是边读边记笔记。
它采用事件驱动机制，逐行扫描 XML 文件。
遇到开始标签，触发 startElement；遇到结束标签，触发 endElement。
这种方式的内存占用几乎可以忽略不计，因为它不需要在内存中保存整棵树。
哪怕是一个几个 G 的日志文件，它也能轻松扛住。
问题是，它的编程模型比较反人类。
你得维护一个状态机，自己记录上下文信息。
比如你要提取
稍微不注意，数据就串了。
public void startElement(String uri, String localName, String qName, Attributes attributes) {
// 记录当前标签名
}public void characters(char[] ch, int start, int length) { // 拼接文本内容 } ```
适合场景也很明确：只读、大文件、对内存敏感的场景。
JAXP 与 StAX：中间派的优雅平衡
JAXP 其实是 Java API for XML Processing 的缩写，它更像是一个框架，统管 DOM 和 SAX。 XML解析技术核心原理与用法详解
但真正让开发者感到舒服的，是后来出现的 StAX（Streaming API for XML）。
StAX 被称为“拉式”解析器，而 SAX 是“推式”。
SAX 是事件主动推送给你，你被动接收；StAX 是你主动调用 nextEvent() 来获取下一个事件。
这种控制权反转，让代码逻辑变得线性且清晰。
你就像在看电影，按播放键就走一步，想看哪段回放就看哪段。
XMLEventReader reader = factory.createXMLEventReader(new FileInputStream("data.xml"));
while (reader.hasNext()) {
XMLEvent event = reader.nextEvent();
if (event.isStartElement()) {
StartElement startElement = event.asStartElement();
// 处理逻辑
}
}
StAX 的内存效率接近 SAX，但代码可读性远高于 SAX。
对于大多数中等规模的 XML 处理任务，它是最佳选择。
JAXB：从 XML 到对象的魔法转换
前面三种都是底层解析，还得手动映射字段。
JAXB（Java Architecture for XML Binding）则是直接帮你做对象绑定。
它通过注解，把 Java 类和 XML 结构直接对应起来。
比如你在类上加个 @XmlRootElement，再给字段加个 @XmlElement。
解析的时候，一行代码搞定：
JAXBContext context = JAXBContext.newInstance(User.class);
Unmarshaller unmarshaller = context.createUnmarshaller();
User user = (User) unmarshaller.unmarshal(new File("user.xml"));
这简直是解放生产力。
再也不用手动去解析标签名、属性值，也不用担心嵌套层级搞错。
但 JAXB 也有局限，它对复杂动态结构的 XML 支持不够灵活。
而且生成的代码体积不小，加载速度也相对慢一些。
适合结构固定、业务逻辑清晰的场景，比如 SOAP 接口调用。
性能对比与选型建议
选哪种方案？别拍脑袋，看数据。
如果是小于 1MB 的小文件，DOM 完全够用，开发效率最高。
如果是 10MB 以上的大文件，或者内存受限的环境，SAX 或 StAX 是唯一选择。
StAX 在读写混合场景下表现更好，SAX 更适合纯读取。
至于 JAXB，它是为了简化开发而存在的，牺牲了一点性能换取了极大的便利性。
在实际项目中，我们往往是混合使用的。
比如用 JAXB 解析配置元数据，用 StAX 处理核心业务数据流。
没有银弹，只有最适合当下场景的工具。
避坑指南：编码与安全性
很多新手在这块栽跟头，不是代码写错了，而是环境没配好。
XML 解析对编码非常敏感。
如果文件声明是 UTF-8，但实际内容是 GBK，解析器可能会抛出异常或乱码。
务必确保 InputSource 指定正确的编码。
另外，XXE 漏洞（XML External Entity Injection）是个大坑。
默认情况下，某些解析器可能允许加载外部实体，导致服务器本地文件泄露。
在生产环境中，一定要关闭 DTD 支持和外部实体解析。
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
这点钱不能省，安全红线碰不得。
说到底，Java XML 解析不是技术难题，而是工程选择题。
选对工具，避开陷阱，剩下的就是熟能生巧。
别被概念吓住，动手写两行代码，你就明白其中的门道了。