Dom4j 的 accept 方法不删除节点，仅决定节点是否进入 Visitor 处理逻辑；它只在 elements(Filter)、visit() 等明确支持 Filter 的 API 中生效，与 XPath 无关。
Dom4j 的 accept 方法到底在过滤什么
它不是直接删节点，而是告诉 Visitor 或遍历器“这个节点要不要进你的处理逻辑”。常见误解是以为调用 accept 就能删掉节点——其实它只影响当前过滤器的判断结果，不修改文档结构。
典型误用场景：想用 accept 配合 element.selectNodes("//*") 一次性筛出符合条件的节点，却发现结果没变。这是因为 selectNodes 用的是 XPath 引擎，压根不走 Filter.accept 流程。
-
accept只在Visitor遍历（如element.visit()）或某些特定构造器（如Element.elements(Filter)）中生效 - 真正想“筛选子节点”，该用
element.elements(Filter)，而不是先取全部再靠accept拦截 - 返回
false不等于“跳过”，而是“这个节点不参与后续 visitor 处理”，但父节点仍会继续遍历其子节点（除非 visitor 主动控制）
写一个靠谱的 Filter 实现要注意啥
别直接 new 匿名类硬写逻辑，容易漏判 null、text node、comment 等非 Element 类型。Dom4j 的 Filter 是泛型接口，accept(Object obj) 的参数可能是 Element、Text、Comment 甚至 Document，不判类型就调 getName() 必崩。
常见错误现象：NullPointerException 或 ClassCastException，尤其在处理带注释或 CDATA 的 XML 时。
立即学习“Java免费学习笔记（深入）”；
- 务必先用
instanceof判类型，比如只关心Element就写obj instanceof Element - 如果需要按属性过滤，记得检查
((Element)obj).attribute("xxx")是否为null，再取值 - 避免在
accept里做耗时操作（如正则匹配大量文本），因为它是遍历路径上的每一步都调用
示例：只接受 name 为 user 且有 active="true" 属性的元素
Filter userActiveFilter = new Filter() {
public boolean accept(Object obj) {
if (!(obj instanceof Element)) return false;
Element e = (Element) obj;
return "user".equals(e.getName())
&& "true".equals(e.attributeValue("active"));
}
};
elements(Filter) 和 selectNodes(String) 性能差多少
纯内存遍历 vs XPath 解析引擎，前者快得多，尤其在小范围筛选时。但 elements(Filter) 只查直接子节点，不能跨层级；而 //user[@active='true'] 能全树搜索——功能不同，不能只比快慢。
容易踩的坑：以为 elements(Filter) 支持递归，结果漏了嵌套结构里的目标节点。
-
elements(Filter)：仅当前层子节点，返回List<Element>，类型安全，无解析开销 -
selectNodes("xpath")：支持任意路径，但每次调用都触发 XPath 编译+执行，短路径可缓存CompiledXPath，否则重复调用很伤 - 如果已知层级（比如只查 root 下的
item），优先用root.elements(new NameFilter("item"))，比 XPath 稳且快
为什么改了 accept 返回值却没看到效果
最常见原因是：你把 Filter 传给了不支持它的 API。比如传给 Document.getRootElement().selectSingleNode("xxx")，这个方法根本不看 Filter，它只认 XPath 字符串。
另一个隐蔽问题：Dom4j 1.x 默认使用 JAXP XPath，某些老 JDK 的 XPath 实现对命名空间敏感，而 Filter 完全不涉及命名空间——这时候你以为过滤失效，其实是 XPath 表达式根本没匹配上。
- 确认 API 文档是否明确写了 “accepts
Filter” —— 只有elements(Filter)、nodeIterator(Filter)、visit(Visitor, Filter)这几个地方才真用 - 调试时加日志，打印进
accept的obj.getClass().getSimpleName()，看看实际传进来的是啥 - 别在
accept里修改节点（比如e.remove()），这会导致遍历器状态错乱，可能跳过后续节点
复杂点在于：Filter 是被动钩子，它本身不驱动任何行为，只是回答“要不要处理”。真正决定怎么走、走到哪、停不停，得看外面用它的那个方法怎么设计——这点很容易被忽略。
