XML流实时转换需SplitXml切片、EvaluateXPath提取、ReplaceText重写，避免OOM；命名空间须显式声明，XPath用相对路径；ReplaceText禁用XML转义；复杂变换优先Jolt。
XML流实时转换的核心是SplitXml + EvaluateXPath + ReplaceText组合
Apache NiFi本身不直接“解析并修改XML结构”，而是靠处理器链协作完成：先切片、再抽取、最后重写。关键在于避免把整个大XML一次性加载进内存——SplitXml按
常见错误是跳过SplitXml，直接用EvaluateXPath处理整份文档，导致OOM或XPath匹配失败（XPath默认作用域是单个Document节点，不是根元素下的任意层级）。
-
SplitXml的XML Path配置必须指向可重复出现的子元素，例如/root/item，不能填/root - 拆分后每个FlowFile只含一个
- ...
EvaluateXPath才能用./name/text()安全取值 - 若原始XML无自然分组标签（如只有顶层
包着几十个同级ReplaceText加包装再SplitXml
EvaluateXPath提取字段时路径必须相对且带命名空间声明
遇到带命名空间的XML（如EvaluateXPath默认无法识别ns:person。必须在处理器的Namespaces属性里显式声明：ns=http://example.com，然后XPath才能写成/ns:person/ns:name/text()。
另一个易错点是路径以/开头（绝对路径），但EvaluateXPath输入是拆分后的单个元素，实际上下文是该元素本身。所以应改用.或./开头：
- ❌ 错误：
/person/name/text()（试图从文档根找，但当前FlowFile只有 - ✅ 正确：
./name/text()或name/text()（相对当前节点） - ✅ 命名空间场景：
./ns:name/text()+Namespaces=ns=http://example.com
ReplaceText构建新XML时要关闭“Replacement Strategy”自动转义
用ReplaceText生成新XML时，如果启用了默认的Regex Replace策略且未关掉Escape XML选项，特殊字符如&会被转成&，导致输出非法XML。必须手动设置：
通过Apache Tika Server REST API从1400多种文件格式中提取文本和元数据。处理PDF、DOCX、PPTX、电子邮件归档以及带有MIME类型检测的嵌入式文档提取。
-
Replacement Strategy选Always Replace（非Regex Replace） -
Escape XML设为false - 替换内容用
${xpath_name}等EL表达式拼接，例如：<user><id>${xpath_id}</id><email>${xpath_email}</email></user>
注意：EL表达式值若含或&，仍需在上游用UpdateAttribute或ExecuteScript预处理转义——ReplaceText本身不负责输入净化。
高吞吐场景下优先用JoltTransformJSON而非纯XML链路
当XML结构固定且需频繁增删字段、重排层级时，SplitXml → XMLToJSON → JoltTransformJSON → JSONToXML比纯XPath链路更稳定、更易维护。Jolt规则用JSON描述变换逻辑，避免XPath字符串拼接错误，也规避了命名空间反复声明的麻烦。
但代价是多两次序列化开销。实测10MB/s XML流中，纯XPath链路延迟约8ms/record，Jolt链路约22ms/record。是否切换取决于你更怕CPU还是怕配置出错：
- XML格式简单、变更少 → 坚持XPath链路
- 需要动态字段映射、条件过滤、嵌套重组 → 上Jolt
- 原始XML含CDATA或注释 → 必须用XPath（Jolt中间JSON会丢失这些）
真实生产环境里，命名空间处理、CDATA保留、超长文本截断这三件事，最容易在压测后期暴露——别只盯着吞吐数字看。
