DOM适合小文件但内存占用高，超5MB易OOM；SAX内存恒定但逻辑复杂需手动维护上下文；读取时须显式指定UTF-8编码并优先用ClassLoader加载资源。
DOM解析适合小文件但内存吃紧
DOM会把整个XML加载进内存构建成树状结构，读取快、支持随机访问，但文件稍大（比如超过5MB）就容易触发OutOfMemoryError。你改配置时手动加了个几百行的<bean>块，重启后服务起不来——八成是DOM撑爆堆了。
- 用
DocumentBuilder.parse()前务必设好DocumentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)，否则XML外部实体（XXE）漏洞直接暴露 - 别对生产环境的
application-config.xml无脑用DOM，尤其当它被多个模块include或动态生成时 -
getElementsByTagName("property")返回的是动态NodeList，循环里删节点要倒序遍历，不然漏处理
SAX解析不占内存但逻辑绕
SAX是事件驱动，边读边触发startElement()、characters()这些回调，内存几乎恒定，但没法回退、不能查父节点——你找<datasource url="...">时，得自己用栈记url在哪个<datasource>下，稍不留神就配错库。
- 必须重写
DefaultHandler.startElement()和endElement()，characters()拿到的文本前后常带换行/空格，要用trim()再判断 - 如果XML里有
<value>${db.host}</value>这类占位符，SAX不会自动展开，得自己集成PropertyPlaceholderConfigurer逻辑 - 遇到
SAXParseException: Element type "xxx" must be declared，基本是DTD或XSD校验开着，关掉setValidating(false)就行
Java原生API读取时路径和编码最易翻车
用FileInputStream读config.xml，本地跑得好好的，扔到Linux服务器就报Invalid byte 1 of 1-byte UTF-8 sequence——八成是Windows下存的GBK编码文件，没指定InputStreamReader编码。
- 绝对别用
new FileInputStream("conf/config.xml")，优先走ClassLoader.getResourceAsStream("config.xml")，避免路径硬编码 - DOM/SAX都得包一层
InputStreamReader，显式传StandardCharsets.UTF_8，别信System.getProperty("file.encoding") - 如果XML声明是
<?xml version="1.0" encoding="GBK"?>，而你用UTF-8读，characters()回调里的字符串直接乱码，且无法恢复
Spring的XmlBeanDefinitionReader其实默认用SAX
你以为ClassPathXmlApplicationContext在后台默默用DOM？其实它委托给XmlBeanDefinitionReader，底层调的是SAXParser——只是把事件解析结果缓存成BeanDefinition对象，对你屏蔽了回调细节。所以你自定义BeanFactoryPostProcessor去改XML配置时，别试图去操作Document对象，那根本不是它用的模型。
立即学习“Java免费学习笔记（深入）”；
- 想干预解析过程，该重写
EntityResolver.resolveEntity()来拦截spring-beans.dtd等远程引用，而不是去动DocumentBuilder -
XmlBeanDefinitionReader.setValidationMode(XmlBeanDefinitionReader.VALIDATION_NONE)能跳过DTD校验，比关SAX的setValidating更精准 - 如果你的XML里混用了
<import resource="xxx.xml"/>，注意ResourcePatternResolver默认只扫classpath*:，file:路径得自己注册UrlResource
DOM和SAX不是非此即彼的选择，而是看住你的XML有多大、谁在改它、出错时能不能快速定位到那一行——很多时候，先用head -n 50 config.xml瞄一眼文件头，比翻API文档管用。
