翻过老项目的代码你大概率见过这种场景对端系统返回的不是 JSON而是一大串结构复杂、层级好几层的 XML。你在心里骂一句“怎么还在用这玩意”然后还是得老老实实解析。今天要聊的 Dom4j就是 Java 生态里解析 XML 的老牌实战派。这一课我打算把 Dom4j 从读取到遍历、从增删改到 XPath 定位再到真实报文解析完整地走一遍把文档里常不写明的坑也一并摊开。内容适合两类人一类是刚学完 Java 基础准备接触真实项目的同学另一类是工作中经常跟 XML 报文打交道被各种解析问题折磨得头疼的开发者。看完之后至少遇到 XML 不会再发怵。1. 为什么需要 XML 解析从真实项目场景说起1.1 XML 到底是个什么东西XML 的全称是可扩展标记语言本质上就是“带标签的纯文本”。它跟 HTML 长得很像但 HTML 的标签是固定的XML 的标签可以自己定义。比如你要描述一个订单可以写成这样order id1001 customer某客户/customer items item skuA001 name机械键盘/name price399.00/price count1/count /item /items /order这种格式的好处是人和机器都能读懂。跟 JSON 比它少了括号嵌套的视觉压力多了一堆尖括号跟纯文本比它有明确的结构层级可以表达“一个订单下面有多个商品明细”这种复杂关系。正是因为这种结构自描述的特性XML 在配置文件、系统对接、设备通信、金融报文这些领域一直活得很好。你改变不了这个现状那就只能学会怎么高效地跟它打交道。所谓 XML 解析就是把这么一段文本转换成一个有层级关系的内存对象树然后你可以随意读取某个元素、修改某个属性、删除某个节点。在 Java 里做这件事主流方案有四套DOM、SAX、JDOM、Dom4j每套都有各自的脾气。1.2 解析一个 XML有哪些可选的方案先说说最原始的 DOM。DOM 是 W3C 的标准接口Java 自带的 javax.xml.parsers 包就能用。它会将整个 XML 文档读入内存构建一棵完整的节点树。优点是功能最全、操作面广缺点是代码啰嗦getElementsByTagName 一路往下找写起来很费劲而且整棵树的加载方式对内存不友好。SAX 则走了另一个极端。它不建树而是从头到尾扫一遍文档遇到开始标签触发一个事件遇到结束标签再触发一个事件程序员在这些事件回调里自己拼装数据。优点是内存占用极低、速度飞快缺点是没有树的全局视图你想回头找某个节点非常麻烦而且代码是事件驱动的一不留神就会陷入回调地狱。JDOM 比 DOM 好用一些API 设计更贴近 Java 开发者的直觉内部也采用树模型。但它的生态一直不温不火更新也慢而且 JDOM 1.x 在 Java 新版本上的兼容性偶尔会出问题。Dom4j 则是本文的重点它同样是一棵树模型API 设计相当顺手支持 XPath、读写一体、输出格式可控很多开源框架内部都在用它解析配置。四者的直观对比如下方案内存模型内存占用XPath 支持增删改方便度典型适用场景DOM树高弱一般小型标准文档SAX事件流低无几乎不用超大文件的读取JDOM树中弱一般简单的文档操作Dom4j树中强非常方便日常项目、报文解析、配置读写1.3 为什么我最终选择了 Dom4j选 Dom4j 的原因很实际第一API 设计符合直觉。一个 Document 就是一棵树getRootElement() 拿到根element() 拿子节点elementIterator() 做遍历addElement() 加节点怎么写都顺。第二XPath 集成得很自然。手写 N 层循环遍历去定位一个深层节点和写一行//order[id1001]/customer直接拿到目标体验完全不在一个层次。第三输出格式可控。它可以紧凑输出也可以格式化输出写配置文件的场景相当好用。当然Dom4j 也有短板。大文件解析时内存占用偏高这是所有树模型的通病另外它在 2.x 版本之前迭代较慢一度让人觉得它停更了。但就绝大多数日常场景来说它是我最顺手的选择。这一课后面的所有代码都基于 Dom4j 2.x 版本来写。2. Dom4j 上手环境、读取、遍历三板斧2.1 引入依赖版本选择和 XPath 的隐藏依赖用 Maven 引入 Dom4j 非常简单核心依赖就一个dependency groupIdorg.dom4j/groupId artifactIddom4j/artifactId version2.1.4/version /dependency但如果你要用 XPath我建议顺手把 jaxen 也加上。这是 Dom4j 执行 XPath 查询时的底层依赖虽然 Dom4j 的包声明里带了一个标记为 optional 的依赖但很多情况下并不会自动引入。不加的话运行时会在你调用 selectNodes() 的那一行抛出NoClassDefFoundError: org/jaxen/JaxenException。这个坑我见过不止一次在项目里排查了半天才发现是少了一个 jar。dependency groupIdjaxen/groupId artifactIdjaxen/artifactId version1.2.0/version /dependency版本方面用 2.1.4 比较稳。有些老项目还在用 1.6.1那个版本年代久远和新 JDK 的兼容性不如 2.x 好。如果你是接手老项目先看清楚项目里已有的版本再动手别上来就升到 2.x免得和旧代码冲突这个后面会专门讲。2.2 读取 XML从一个文件开始读取 XML 的核心类是 SAXReader。它的名字听着像 SAX其实它内部用 SAX 解析器扫描一遍后会把结果组装成一棵 Dom4j 的 Document 树。平时我们在代码里写的“读取 XML”绝大多数都是通过它完成的。最基础的用法如下import org.dom4j.Document; import org.dom4j.Element; import org.dom4j.io.SAXReader; import java.io.File; public class ReadXmlDemo { public static void main(String[] args) throws Exception { SAXReader reader new SAXReader(); Document document reader.read(new File(order.xml)); Element root document.getRootElement(); System.out.println(根节点名称 root.getName()); System.out.println(根节点 id 属性 root.attributeValue(id)); } }这里有几个值得注意的地方。reader.read() 支持传入 File、InputStream、Reader、URL甚至一段字符串。但如果 XML 文件含有中文字符直接用 File 读取时Dom4j 会按照 XML 声明里写的编码去解码。如果声明写的是 UTF-8文件内容也确实保存为 UTF-8那没问题如果声明写错了或者文件本身是 GBK 却声明成 UTF-8就会出现乱码。提示实践中我更推荐用 InputStreamReader 显式指定编码来读取尤其是对接老系统时对方传过来的 XML 声明经常不靠谱。SAXReader reader new SAXReader(); try (InputStream in new FileInputStream(order.xml); Reader r new InputStreamReader(in, StandardCharsets.UTF_8)) { Document document reader.read(r); }2.3 遍历节点从根元素开始一层一层走拿到 Document 之后XML 就变成了一棵树。你要做的是从根节点出发逐步进入子节点、孙节点。Dom4j 提供了多种遍历方式最常用的几个我列出来。elementIterator(String name) 方法返回一个迭代器可以逐个处理同名子节点elements(String name) 方法直接返回一个 List 适合用增强 for 遍历。attributeValue(String name) 可以拿到属性值getText() 取文本elementTextTrim(String name) 直接取某个子节点的文本并去掉首尾空白。看一个完整示例import org.dom4j.Document; import org.dom4j.Element; import org.dom4j.io.SAXReader; import java.io.File; import java.util.Iterator; import java.util.List; public class TraverseXmlDemo { public static void main(String[] args) throws Exception { SAXReader reader new SAXReader(); Document document reader.read(new File(order.xml)); Element root document.getRootElement(); // 遍历所有 order 子节点 for (IteratorElement it root.elementIterator(order); it.hasNext(); ) { Element order it.next(); System.out.println(订单号 order.attributeValue(id)); System.out.println(客户 order.elementTextTrim(customer)); Element items order.element(items); ListElement itemList items.elements(item); for (Element item : itemList) { String sku item.attributeValue(sku); String name item.elementTextTrim(name); String price item.elementTextTrim(price); System.out.println(商品 sku name 价格 price); } } } }这段代码里我刻意先取了 customer再取 items 列表是想让你直观感受一下“树在内存中的结构”。根节点下面挂着多个 order每个 order 下面有 customer、itemsitems 下面才是 item。遍历的时候层级关系一目了然。这个遍历思路是所有解析的基础比直接背 API 更重要。3. 增删改查一条龙把 XML 当内存对象来操作3.1 增加节点给订单数据追加一条明细很多教程只教怎么解析 XML但实际项目里还有一个高频场景是“生成 XML”。比如你要给外部系统下发一个报文或者要动态生成一个配置文件。Dom4j 的 API 在创建节点时做得非常顺手用链式调用的话几行就能拼出一棵标签树。假设我们要在根节点下新增一个订单包含客户和商品明细可以这样写import org.dom4j.Document; import org.dom4j.DocumentHelper; import org.dom4j.Element; public class CreateXmlDemo { public static void main(String[] args) { Document document DocumentHelper.createDocument(); Element root document.addElement(orders); Element order root.addElement(order) .addAttribute(id, 1002); order.addElement(customer).addText(某供应商); order.addElement(remark).addText(加急发货); Element items order.addElement(items); Element item items.addElement(item) .addAttribute(sku, C003); item.addElement(name).addText(显示器); item.addElement(price).addText(899.00); item.addElement(count).addText(1); System.out.println(document.asXML()); } }注意 addText() 方法会自动处理特殊字符的转义。如果文本内容是a b写出来会变成a lt; b确保生成的 XML 是合法的。这也是为什么不要自己拿字符串拼 XML 的核心理由——你永远猜不到文本里会不会出现 或尖括号。DocumentHelper.createDocument() 会创建一个空白文档addElement() 放在这个文档首次调用时创建的是根节点。再次调用 addElement() 才会创建根节点的子节点。如果你在已有的 Document 上操作则要先通过 getRootElement() 拿到根节点再往上追加。3.2 修改节点把价格批量改掉修改操作的核心是“先定位再修改”。定位在上一步遍历时已经学过修改则有两类改文本和改属性。改文本用 setText()改属性用 setAttributeValue()。例如要把某个商品的价格从 899.00 改成 799.00代码是这样Element items root.element(order).element(items); for (Element item : items.elements(item)) { if (C003.equals(item.attributeValue(sku))) { item.element(price).setText(799.00); item.setAttributeValue(status, promoted); // 如果之前没有 status 属性这会自动创建一个 } }setAttributeValue 是一个很方便的方法属性存在时改值不存在时自动新增。这个特性在更新不固定格式的 XML 时非常有用省去了一堆 if-else 判断。文本修改同理如果某个子节点不存在直接 setText 会怎样结果是抛异常因为你试图在一个不存在的元素上设文本。所以在修改深层节点前最好先确认它存在。3.3 删除节点清理过期数据删除单个节点在 Dom4j 里异常简单调用 detach() 就行Element remark order.element(remark); if (remark ! null) { remark.detach(); }detach() 会把当前节点从父节点上摘下来同时这个 Element 对象仍然存活你可以把它插入到别的地方。这个特性很实用比如要调整 XML 里节点的顺序或者把一组节点从一个父节点整体移动到另一个父节点detach() 之后再 add 到目标位置即可。如果想清空一个节点下的所有子节点可以用 clearContent()它会移除所有子元素和文本节点但保留这个节点本身的属性。想删掉一批符合条件的子节点稳妥的做法是先收集要删除的对象再统一 detach。不要在遍历迭代器的过程中直接调用 detach()步子迈太大容易出并发修改异常这个细节后面避坑部分还会提到。3.4 把结果写回文件别掉进编码的坑改完内存里的树最终要落盘。Dom4j 提供了一个 XMLWriter 类配合 OutputFormat 控制输出样式。常见需求有两种一种是格式化输出每个标签缩进换行方便人阅读另一种是紧凑输出每一行就是一大串 XML适合做报文传输。import org.dom4j.Document; import org.dom4j.io.OutputFormat; import org.dom4j.io.XMLWriter; import java.io.FileOutputStream; import java.io.OutputStreamWriter; import java.nio.charset.StandardCharsets; public class WriteXmlDemo { public static void main(String[] args) throws Exception { Document document buildDocument(); // 假设已经有了一棵文档树 OutputFormat format OutputFormat.createPrettyPrint(); format.setEncoding(UTF-8); try (FileOutputStream fos new FileOutputStream(order_new.xml); OutputStreamWriter writer new OutputStreamWriter(fos, StandardCharsets.UTF_8)) { XMLWriter xmlWriter new XMLWriter(writer, format); xmlWriter.write(document); xmlWriter.flush(); } } }这里有几个关键点。OutputFormat.createPrettyPrint() 生成的是带缩进的格式化输出createCompactFormat() 则生成紧凑输出。如果不做任何格式化设置默认写出来的 XML 是一行但也不至于出错。编码方面format.setEncoding(UTF-8) 只是设置了 XML 声明里的 encoding 属性真正决定字节编码的是你传入 XMLWriter 的 Writer 或 OutputStream 的编码。两者必须保持一致否则就会出现“声明是 UTF-8实际字节却是 GBK”的惨案。注意写完 XML 后记得把 XMLWriter 的流关闭。用 try-with-resources 包住 FileOutputStream 和 OutputStreamWriter 是更省心的做法省得忘记 flush。4. XPath 精准定位少写一百行循环4.1 XPath 表达式到底是什么如果说手写循环遍历是“一步一步走迷宫”那 XPath 就是“站在高处直接看到目标”。它是一门专门用于在 XML 文档中定位信息的查询语言。几个最常用的语法必须掌握表达式示例含义/orders/order从根节点出发找所有 order 子节点//item忽略层级找所有 item 节点//item[skuA001]找 sku 属性为 A001 的 item 节点/orders/order[1]找第一个 order 节点//price/text()找所有 price 节点的文本//item/name找所有 item 下的 name 子节点在代码里手写五层嵌套循环去筛选数据写出来的字数是 XPath 的十倍不止而且可读性还不如一行表达式。所以在解析结构比较复杂的 XML 时我通常会先用 XPath 把边界试探清楚再动手写遍历逻辑。4.2 在 Dom4j 中执行 XPath 查询Dom4j 的 Document 和 Element 都内置了 selectNodes() 和 selectSingleNode() 方法。前者返回一个 List 后者返回单个 Node。看个例子import org.dom4j.Document; import org.dom4j.Node; import org.dom4j.io.SAXReader; import java.io.File; import java.util.List; public class XPathDemo { public static void main(String[] args) throws Exception { SAXReader reader new SAXReader(); Document document reader.read(new File(order.xml)); // 取所有商品名称 ListNode nameNodes document.selectNodes(//item/name); for (Node node : nameNodes) { System.out.println(node.getText()); } // 取 sku 为 A001 的那个 item 元素 Node target document.selectSingleNode(//item[skuA001]); if (target ! null) { System.out.println(target.asXML()); } } }selectSingleNode() 返回的是 Node 接口类型。如果确定查的是元素节点可以强转成 Element然后继续调用业务 API。比如Element item (Element) document.selectSingleNode(//item[skuA001]);之后就可以 item.element(price) 这类操作了。XPath 查询不到任何内容时返回 null所以用之前最好判空否则空指针一下就来了。4.3 命名空间这个坑很多人绕不过去只要对接过带命名空间的 XML你一定见过这种标签ns:order xmlns:nshttp://example.com/order ns:item.../ns:item /ns:order猛一看结构还是那个结构但你用//ns:item去查的时候Dom4j 会告诉你查不到。原因在于XPath 1.0 要求你为命名空间前缀提供一个映射把前缀和真实的 URI 绑起来。很多人第一次在这上面栽跟头浪费一整个下午。正确的写法是给 XPath 设置 Namespace 上下文import org.dom4j.Document; import org.dom4j.Element; import org.dom4j.XPath; import java.util.HashMap; import java.util.Map; public class NamespaceXPathDemo { public static void main(String[] args) throws Exception { SAXReader reader new SAXReader(); Document document reader.read(new File(ns_order.xml)); MapString, String nsMap new HashMap(); nsMap.put(ns, http://example.com/order); XPath xPath document.createXPath(//ns:order/ns:item[skuA001]); xPath.setNamespaceURIs(nsMap); Element item (Element) xPath.selectSingleNode(document); if (item ! null) { System.out.println(item.asXML()); } } }建议不管 XML 里有没有命名空间只要标签里有冒号前缀就一律用 createXPath() 配合 setNamespaceURIs() 来处理。这样写出来的代码对格式变化更健壮将来 XML 结构调整时也不用全部推翻重来。5. 实战解析一个带嵌套列表的 XML 报文5.1 场景设定这一节我们造一个贴近实际的报文。假设某系统对外提供订单查询接口返回的响应是一段 XML里面包含状态、订单信息以及一个商品明细列表。这种“外层响应 中间业务对象 内层列表”的结构在真实项目中非常典型。response statusSUCCESS/status message处理完成/message order id20230415001 customer某客户/customer remark加急/remark items item skuA001 name机械键盘/name price399.00/price count2/count /item item skuB002 name无线鼠标/name price99.50/price count1/count /item /items /order /response我们的目标是把这段 XML 解析成一个 Java 对象方便后续入库或者展示。解析思路分三步第一步拿到根节点检查 status 是否为 SUCCESS第二步取出 order 节点填充订单主表信息第三步遍历 items 下的 item 节点逐条填充明细列表。5.2 设计解析模型在写解析代码之前先定义两个实体类。订单类 OrderInfo 包含订单号、客户、备注、商品明细列表商品明细类 ItemInfo 包含 SKU、名称、单价、数量。简单写如下public class OrderInfo { private String id; private String customer; private String remark; private ListItemInfo items new ArrayList(); // 省略 getter / setter } public class ItemInfo { private String sku; private String name; private double price; private int count; // 省略 getter / setter }有人会觉得手写实体类很麻烦但实际项目中对接文档一旦确定对应的 Java 模型就会固定下来。先把字段定义清楚解析代码就能写得更稳、更明确。5.3 核心代码实现解析代码可以直接写成一个小工具类。为了演示完整我把读取和解析放在同一个 parse 方法里import org.dom4j.Document; import org.dom4j.Element; import org.dom4j.io.SAXReader; import java.io.StringReader; import java.util.Iterator; public class OrderParser { public OrderInfo parse(String xmlText) throws Exception { SAXReader reader new SAXReader(); Document document reader.read(new StringReader(xmlText)); Element root document.getRootElement(); if (!SUCCESS.equals(root.elementTextTrim(status))) { throw new RuntimeException(订单查询失败 root.elementTextTrim(message)); } Element orderEl root.element(order); if (orderEl null) { throw new RuntimeException(响应中缺少 order 节点); } OrderInfo order new OrderInfo(); order.setId(orderEl.attributeValue(id)); order.setCustomer(orderEl.elementTextTrim(customer)); order.setRemark(orderEl.elementTextTrim(remark)); Element itemsEl orderEl.element(items); if (itemsEl ! null) { for (IteratorElement it itemsEl.elementIterator(item); it.hasNext(); ) { Element itemEl it.next(); ItemInfo item new ItemInfo(); item.setSku(itemEl.attributeValue(sku)); item.setName(itemEl.elementTextTrim(name)); item.setPrice(Double.parseDouble(itemEl.elementTextTrim(price))); item.setCount(Integer.parseInt(itemEl.elementTextTrim(count))); order.getItems().add(item); } } return order; } }elementTextTrim() 在这个场景里非常合适。它取出子元素文本后自动去掉首尾空格和换行避免你因为 XML 里恰好有个换行符而读到399.00\n这种脏值。在 double 转换时399.00是合法数字但如果对方的报文里写成了399.00元这里就要用更健壮的清洗逻辑了。现实中金额字段经常既可能是数字也可能是带单位字符串遇到这种情况我建议先尝试用正则过滤后再转换而不是直接交给 Double.parseDouble 去炸。5.4 防御式解析别让一个 null 毁掉整个流程解析外部 XML 不同于解析自己生成的 XML你永远不知道对方会在什么情况下少给一个字段。防御式解析的核心就是“层层判空”。比如 orderEl 为 null 时如果直接调用 attributeValue虽然不一定立刻报错但后续 elementTextTrim 一定会抛 NullPointerException而且异常信息还不直观。加上自定义异常信息之后问题定位速度快得多。数值字段的转换也要做保护。Double.parseDouble和Integer.parseInt都可能因为格式问题抛出 NumberFormatException。可以写一个统一的安全转换方法传入默认值转失败时返回默认值。这样就算某个金额字段异常也不会让整个订单解析失败。当然业务上要不要容忍脏数据取决于你对数据的信任程度。如果外部系统经常出错我更建议解析后将日志打印出来把异常信息记录下来而不是静默吞掉。6. 避坑手册从乱码到类冲突的全面排查6.1 编码问题乱码九成出在这里XML 乱码的根源几乎都是编码不一致。有三个环节都要对齐XML 文件本身的编码、XML 声明里的 encoding 属性、代码读取时使用的 Reader 编码。比如文件是 GBK 保存声明写的却是 UTF-8那不管你怎么解析读出来的中文都是问号。另一个隐蔽的问题藏在 UTF-8 的 BOM 头里。某些 Windows 工具生成的 XML 文件开头会带一个\uFEFF字符解析后你会发现根节点的名称前面多了一个不可见字符直接导致document.getRootElement().getName()拿到的字符串不等于你预期值。解决办法是在读取时通过 InputStreamReader 显式指定编码如果怀疑有 BOM可以先检测并跳过前几个字节。实际项目中我最省心的做法是让上游系统统一输出 UTF-8 编码并在 XML 声明里写 UTF-8。遇到对方不配合的情况就自己写一个小工具方法去做编码预处理。6.2 特殊字符与 CDATA 的正确姿势XML 文本中、、、单双引号这五个字符是保留字符直接出现会导致解析失败。如果是你自己用 DOM4j 的 addText() 方法生成文本它会自动转义不用慌。但如果你是从字符串里读入一段已经拼好的 XML而且文本内容里混入了未转义的解析时会直接抛出org.xml.sax.SAXParseException。应对方案有两个。第一生成方做好转义把写成amp;把写成lt;。第二如果是大段包含特殊符号的文本比如配置文件里的 SQL 语句、正则表达式用 CDATA 包起来更省心。CDATA 里的内容不会被 XML 解析器当作标签或转义符处理。Dom4j 中的写法是element.addCDATA(这里的内容随便写 )。读取的时候CDATA 的内容会作为普通文本返回。6.3 性能问题大文件别用 Dom4j 硬扛Dom4j 是树模型解析时会把整棵文档树加载到内存。一个 1 MB 的 XML 解析成树之后内存占用可能会放大到几十 MB因为每个节点都是一个对象还有父子引用和属性集合。几十 MB 以内的小文档问题不大但如果你面对的是几百 MB 的日志文件、报文备份Dom4j 的内存开销就有点吓人了。这时候应该考虑 SAX 或 StAX 这类流式解析方案。SAX 是一次性扫描不建树内存占用极低适合从头到尾顺序处理StAX 则支持像迭代器一样按需拉取节点。如果非要在大文件里用 XPath 查询就只能另想办法比如先做一次流式过滤只把符合条件的片段取出来再喂给 Dom4j 做精细解析。不要试图用 Dom4j 硬扛大数据量体验很差。提示判断该不该用 Dom4j 的标准很简单——文件是否能被轻松读进内存。能就用 Dom4j开发效率最高不能就老老实实上 SAX。6.4 类库冲突ClassCastException 的元凶Dom4j 的老版本和新版本 API 不兼容如果项目的依赖树里同时引入了 dom4j 1.6.1 和 2.1.4运行时很可能会出现ClassCastException: org.dom4j.tree.DefaultElement cannot be cast to ...。这种问题的隐蔽之处在于编译期一切正常跑起来才炸而且报错信息还不容易联想到依赖冲突。排查思路是先用依赖树分析工具看 dom4j 被哪些构件带进来然后通过 Maven 的 exclusion 排除多余的传递依赖或者统一指定版本号。另一个常见冲突是项目中存在多个 XML 解析器实现比如 xercesImpl 和 JDK 内置的解析器版本不一致导致 SAXParser 行为异常。这种时候默认以 JDK 内置实现为主不要随便往依赖里塞 xerces除非你有非常明确的理由且知道自己在做什么。6.5 其他小坑遍历时删节点、null 处理和格式化输出遍历过程中删除节点是一个高频事故点。在迭代器遍历时如果直接调用element.detach()迭代器的结构会被破坏抛出异常或漏掉节点。解决办法是先把要删除的元素收集到一个临时 List 里循环结束后再统一 detach 掉。selectSingleNode() 返回 null 也必须处理。不要直接(Element)强转后调用方法先判空一下。另外格式化输出时会发现同样的文档树经过一次解析再写出原本的注释节点、属性顺序、空白文本都可能变化。如果外部系统对 XML 格式有严格校验比如签名字段的位置不能变那你就要小心了不要用 Dom4j 对原始报文做“读入再原样写出”很容易改掉字节级细节导致验签失败。下面是几个高频问题的速查表建议收藏现象可能原因解决方案中文乱码文件编码与声明编码不一致统一 UTF-8用 Reader 显式指定编码根节点名字多出\uFEFFUTF-8 BOM读取前跳过 BOM 头selectNodes 抛 NoClassDefFoundError缺少 jaxen 依赖引入 jaxen jar解析未转义特殊字符报错 或 未转义生成方做 XML 转义或用 CDATA大文件内存溢出Dom4j 树模型内存开销高改用 SAX / StAXClassCastExceptiondom4j 多版本共存依赖树排查排除多余版本遍历时删除元素异常迭代器结构被破坏先收集再统一 detach这一课的内容基本覆盖了 Dom4j 从入门到实战的方方面面也把我踩过的坑都摊开说了。我个人在实际项目中的体会是Dom4j 这套 API 一旦用顺了解析 XML 就不再是让人头疼的事反而更像是在“整理一棵树”。如果你想复习巩固建议按照“读取 → 遍历 → 修改 → XPath → 写回”的顺序亲手跑一遍然后在真实项目找一个报文样例练手。最后再分享一个小经验每写完一段解析代码最好先输出一下asXML()或打印关键字段看看结果比直接闷头调业务逻辑要省时间得多。