XML流实时转换需SplitXml切片、EvaluateXPath提取、ReplaceText重写，避免OOM；命名空间须显式声明，XPath用相对路径；ReplaceText禁用XML转义；复杂变换优先Jolt。
XML流实时转换的核心是SplitXml + EvaluateXPath + ReplaceText组合
Apache NiFi本身不直接“解析并修改XML结构”，而是靠处理器链协作完成：先切片、再抽取、最后重写。关键在于避免把整个大XML一次性加载进内存——SplitXml按<record>或自定义标签拆成流文件，每条都是独立XML片段，后续处理器才可逐条处理。
常见错误是跳过SplitXml，直接用EvaluateXPath处理整份文档，导致OOM或XPath匹配失败（XPath默认作用域是单个Document节点，不是根元素下的任意层级）。
-
SplitXml的XML Path配置必须指向可重复出现的子元素，例如/root/item，不能填/root - 拆分后每个FlowFile只含一个
<item>...</item>，此时EvaluateXPath才能用./name/text()安全取值 - 若原始XML无自然分组标签（如只有顶层
<data>包着几十个同级<field>），需先用ReplaceText加包装再SplitXml
EvaluateXPath提取字段时路径必须相对且带命名空间声明
遇到带命名空间的XML（如<ns:person xmlns:ns="http://example.com">），EvaluateXPath默认无法识别ns:person。必须在处理器的Namespaces属性里显式声明：ns=http://example.com，然后XPath才能写成/ns:person/ns:name/text()。
另一个易错点是路径以/开头（绝对路径），但EvaluateXPath输入是拆分后的单个元素，实际上下文是该元素本身。所以应改用.或./开头：
- ❌ 错误：
/person/name/text()（试图从文档根找，但当前FlowFile只有<person>） - ✅ 正确：
./name/text()或name/text()（相对当前节点） - ✅ 命名空间场景：
./ns:name/text()+Namespaces=ns=http://example.com
ReplaceText构建新XML时要关闭“Replacement Strategy”自动转义
用ReplaceText生成新XML时，如果启用了默认的Regex Replace策略且未关掉Escape XML选项，特殊字符如&会被转成&，导致输出非法XML。必须手动设置：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
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保留、超长文本截断这三件事，最容易在压测后期暴露——别只盯着吞吐数字看。
