SAX解析器是基于事件驱动的流式XML解析工具，边读边触发startElement()等回调，内存占用恒定且与文件大小无关，适合处理大型XML；DOM则需构建完整节点树，内存用量达文件大小2~5倍，适用于需随机访问和修改的小型XML。
SAX解析器是一种基于事件驱动的流式XML解析工具，它不把整个文件装进内存，而是边读边触发回调，比如startElement()、characters()、endElement()，开发者在这些回调里处理数据。处理大型XML时，它和DOM的核心差异就落在“要不要建一棵树”上。
内存占用方式完全不同
DOM必须一次性加载全部内容，构建完整的节点树，每个元素、属性、文本都变成内存里的对象，还带着父子引用、命名空间信息等开销。一个500MB的XML，DOM可能吃掉2GB以上内存。SAX只保留当前解析位置的少量上下文（比如元素栈、字符缓冲区），峰值内存通常稳定在几MB以内。
- DOM：内存用量≈文件大小 × 2~5倍，随文件线性暴涨
- SAX：内存基本恒定，与文件大小无关
- 遇到1GB+ XML，DOM容易触发
OutOfMemoryError，SAX一般不受影响
数据访问能力截然相反
DOM像打开一本纸质书——可以随时翻到任意页、划重点、涂改、插页。SAX则像听广播——声音过去了就没了，不能倒带，也不能跳到中间某段。
- DOM支持XPath查询、任意节点增删改、反复遍历
- SAX只能顺序处理，一旦解析过某个节点，
除非你自己缓存，否则无法再取 - 若需关联多个分散节点（比如用ID匹配不同section），SAX得靠代码手动维护映射关系
除非你自己缓存，否则无法再取适用场景有明确分界
不是技术高低之分，而是任务匹配问题。选错会导致开发绕弯或系统崩溃。
- 选SAX：日志归档解析、ETL数据抽取、实时消息体处理、嵌入式设备读配置
- 选DOM：编辑型应用（如XML可视化编辑器）、需多次修改并保存回文件、小配置文件+强查询需求（如Spring配置）
- 折中方案：对大文件中关键片段用SAX提取，再用DOM局部处理；或用StAX做半拉拽式解析
基本上就这些。不复杂但容易忽略：文件一超20MB，就该本能地先想SAX。
