xml命名空间导致payload.*匹配失败，因dataweave默认忽略命名空间；需用%namespace声明并以prefix#element语法访问，空字符串前缀对应默认命名空间，输出时须显式添加@xmlns属性。
XML命名空间导致 payload.* 匹配失败
这是最常见问题：带命名空间的 XML（如 <root xmlns:ns="http://example.com"><item>A</item></root>）中，直接写 payload.root.item 会返回 null。DataWeave 默认忽略命名空间，所有元素被视为“无命名空间”，而实际节点带有前缀和 URI，匹配不上。
解决方式不是去掉命名空间，而是显式声明并使用它：
- 在脚本顶部用
%namespace声明前缀与 URI 的映射，例如：%namespace ns "http://example.com" - 之后所有路径访问必须带上该前缀：
payload.ns#root.ns#item - 注意语法：
ns#element（不是ns:element或ns.element） - 若 XML 使用默认命名空间（
xmlns="http://example.com"），需用空字符串前缀：%namespace "" "http://example.com"，然后写payload.#root.#item
多个命名空间混用时如何避免冲突
真实 XML 常含多个命名空间（如 SOAP 消息里 soapenv、xs、业务自定义 ns），硬编码所有前缀易出错且难维护。
推荐做法是分层处理：
- 用
%namespace分别声明每个前缀，名称尽量贴近原始 XML 中的用法（如%namespace soap "http://schemas.xmlsoap.org/soap/envelope/"） - 访问嵌套结构时，前缀必须与对应节点的实际声明一致；不能跨命名空间复用前缀
- 若需动态判断命名空间（比如同一字段在不同版本 XML 中命名空间不同），DataWeave 2.0 不支持运行时切换命名空间，只能靠条件逻辑 + 多组
%namespace声明 +if分支分别处理 - 避免用通配符（如
payload.*）遍历带命名空间的节点——它只会匹配无命名空间的子节点
write 输出 XML 时保留或省略命名空间
从 JSON 或 Map 构造 XML 时，DataWeave 默认不输出命名空间，即使输入有。要控制输出行为，关键在 write 函数的参数和属性写法：
- 用
output application/xml时，命名空间需显式写入属性：{"@xmlns:ns": "http://example.com", "ns#root": {"ns#item": "A"}} - 若想省略前缀但保留默认命名空间，用空字符串键：
{"@xmlns": "http://example.com", "#root": {"#item": "A"}} - 注意：
@xmlns和@xmlns:prefix是特殊属性名，必须加@，且值为字符串 URI - 错误写法：
"xmlns:ns": "..."（缺@）或"ns#root": {...}却没声明%namespace—— 这会导致输出时前缀丢失或报错
%dw 2.0
output application/xml
%namespace ns "http://example.com"
---
{
"@xmlns:ns": "http://example.com",
"ns#root": {
"ns#item": "A"
}
}解析带命名空间的 XML 后，defaultNamespace 不起作用
DataWeave 2.0 中没有 defaultNamespace 这个关键字。这是常见误解，源于把其他 XML 工具（如 XSLT 或某些 Java 库）的概念套用过来。
正确做法只有两种：
- 对默认命名空间（
xmlns="..."），必须用%namespace "" "URI"声明，再用.#element访问 - 对带前缀的命名空间，必须用
%namespace prefix "URI"，再用.prefix#element - 不存在全局“默认”绑定；每个
%namespace声明只作用于当前脚本，且不可被子表达式继承 - 如果 XML 结构复杂、命名空间嵌套深，建议先用
payload mapObject (value, key) -> {key: value}打平查看实际键名，确认哪些节点带命名空间、哪些不带
命名空间不是装饰，是 XML 的一部分；DataWeave 不自动“理解”它们，也不做隐式映射。漏掉一个 %namespace，或写错一个 #，整个路径就失效——这点比 JSON 处理严格得多。
