Saxon s9api：TinyDocumentImpl与DocumentImpl适用场景问询

刚迁移到Saxon s9api时碰到这俩实现确实容易懵，我来给你梳理清楚它们的区别、触发场景以及怎么处理：

核心区别与适用场景 #

这俩都是Saxon对NodeInfo接口的实现，核心差异在于内存存储结构和使用场景：

• TinyDocumentImpl（Tiny Tree）：轻量级、内存优化的只读实现。它把所有节点数据压缩存储在数组里，内存占用比Linked Tree小得多，加载和遍历速度也更快。适合静态、只读的文档场景，比如从文件/流加载的源文档，不需要修改的情况。缺点是不支持节点的动态修改（插入、删除、更新），因为压缩结构的特性，修改成本极高。
• DocumentImpl（Linked Tree）：基于链表结构的灵活实现，类似标准DOM的节点树。每个节点都是独立对象，通过引用关联，支持所有节点操作（增删改查）。适合需要动态构造或修改节点的场景，比如XSLT转换中生成的临时节点、需要手动修改内容的文档。缺点是内存占用更大，大文档下性能不如Tiny Tree。

Saxon返回不同实现的判定规则 #

1. DocumentBuilder加载文档默认返回TinyDocumentImpl #

Saxon的DocumentBuilder默认采用TreeModel.TINY_TREE作为树模型，因为加载文档大多是只读场景，优先保证内存效率和加载速度。如果你需要强制返回DocumentImpl，可以修改Builder的配置：

Processor processor = new Processor(false);
DocumentBuilder builder = processor.newDocumentBuilder();
// 指定使用Linked Tree，即DocumentImpl
builder.setTreeModel(TreeModel.LINKED_TREE);
XdmNode doc = builder.build(new File("your-document.xml"));

2. xsl:message中的节点为何是DocumentImpl？ #

这是因为xsl:message输出的内容通常是动态生成的节点片段，而非直接引用源文档的只读节点。Saxon在处理这类动态生成的节点时，会默认使用Linked Tree（DocumentImpl），因为它更适合临时的、可能需要修改的节点结构。另外，XSLT转换过程中创建的新节点（比如用xsl:element生成的元素），大多也会用Linked Tree实现，除非你显式配置了全局的树模型。

如何避免耦合具体实现？ #

最佳实践是面向NodeInfo接口编程，不要依赖具体的实现类。NodeInfo已经封装了所有核心的节点操作方法（比如获取节点类型、文本值、子节点等），不管拿到的是TinyDocumentImpl还是DocumentImpl，都能通过接口方法统一处理，避免代码里出现instanceof判断。

如果确实需要在两种实现间转换，可以用Saxon的TreeCopier工具：

// 把TinyDocumentImpl转换成DocumentImpl
TreeCopier copier = new TreeCopier(processor);
NodeInfo linkedTree = copier.copy(tinyTree);

内容的提问来源于stack exchange，提问作者craigmiller160