dataweave 2.0解析xml默认转为map且丢失根名，需显式提取；命名空间必须声明前缀并用#分隔；write输出xml时属性与文本须同级并用@和#text；字符串输入需read解析，否则无法访问节点。
DataWeave 2.0 处理 XML 不需要“教程式学习”，关键在于理解它对 XML 的默认行为、命名空间处理方式，以及如何避免常见解析失败——比如 Cannot coerce Null to Object 或根节点莫名消失。
XML 输入自动转成 Map，但根元素名会丢失
DataWeave 默认把 XML 解析为 Object，且只保留子节点结构，原始根标签名（如 <orders></orders>）不会作为字段名保留。如果你依赖根名做路由或校验，必须显式提取：
%dw 2.0
output application/json
---
{
rootName: payload pluck $$,
content: payload
}更实用的做法是用 write 函数配合 attributes 和 namespace 参数控制输出，但输入阶段就该意识到：你拿到的不是“原始 XML 字符串”，而是已解析的树形结构。
带命名空间的 XML 必须声明并使用前缀
没声明命名空间就直接访问 payload.ns:Order？会报错 Unknown prefix 'ns'。正确做法是开头用 ns ns "http://example.com/schema" 声明，并在所有路径中带上前缀：
%dw 2.0
ns ns "http://example.com/schema"
output application/json
---
payload.ns#Orders.ns#Order map {
id: $.ns#id,
items: $.ns#Items.ns#Item
}注意：# 是命名空间分隔符，不是点号；ns#Orders 中的 Orders 是本地名，大小写敏感；如果 XML 使用默认命名空间（xmlns="..."），要用 ns "" "..." 声明空前缀。
write 输出 XML 时属性和文本混排容易出错
想生成 <item id="123">apple</item>，但写成 {"item": "apple", "@id": "123"} 会失败——DataWeave 要求属性必须嵌套在 @ 下，且与文本内容同级，不能放在值内部：
%dw 2.0
output application/xml
---
{
item: {
"@id": "123",
"#text": "apple"
}
}常见错误包括：
- 漏掉
#text，导致内容被忽略 - 把
@id写成id或"@id"（字符串键名无效） - 在
output application/xml下返回数组却不包根节点，触发Expected object, got array
从 Java 或 HTTP 接收的 XML 字符串需先 read 再处理
Mule 4 的 payload 如果是 java.lang.String 类型（比如来自 http:request 的原始响应体），DataWeave 不会自动解析 XML——它只会当普通字符串处理。必须显式调用 read：
%dw 2.0
output application/json
---
read(payload, "application/xml") mapObject {
($$): $
}否则你会看到整个 XML 当作单个字符串传入，payload.Order 返回 null。顺便提醒：read 不支持 DTD 或外部实体，含 的 XML 会抛 <code>XMLStreamException，得先用 replace 清除。
最常被忽略的是：XML 命名空间声明本身不参与数据路径匹配，但一旦存在，所有元素访问都强制要求前缀；还有就是 write 输出时，空对象（{}）会被序列化成自闭合标签，而 { "#text": "" } 才生成有结束标签的空元素——这种细节在对接老系统时往往决定成败。
