Mule 3与Mule 4 Payload不可变性差异：Mule 3异常行为解析

Mule 3 中出现这种“修改一个对象导致另一个对象同步变化”的现象，本质是对象引用传递机制导致的，和 Mule 4 的不可变数据模型存在根本差异：

具体原因拆解 #

1. Mule 3 的对象存储逻辑
   当你通过 Set Variable 组件执行 value="#[payload]" 时，并没有创建 payload 对象的独立副本，只是把 payload 的内存引用赋值给了 originalPayload 变量。也就是说，originalPayload 和 payload 指向的是内存中同一个可变对象（HTTP 接收的 JSON 在 Mule 3 中默认会被转换为 java.util.HashMap 这类可变集合）。

2. 修改操作的本质

   • 用 Groovy 组件修改 originalPayload 的 bonus 字段时，实际是直接操作了这个共享的 HashMap 对象，所以 payload 的 bonus 字段也会同步变化。
   • 后续用 Expression Component 修改 payload 的 reward 字段，同样是操作同一个共享对象，因此 flowVars.originalPayload 的 reward 字段也会跟着改变。

Mule 4 行为不同的原因 #

Mule 4 采用了不可变数据模型，DataWeave 处理数据时，所有修改操作都会创建一个全新的对象，原对象不会被修改。因此修改其中一个变量的字段，只会影响新创建的对象，不会波及另一个变量指向的原对象，这也是符合大多数开发者预期的“值拷贝”逻辑。

Mule 3 中的解决方案（可选补充） #

如果要在 Mule 3 中避免这种引用共享问题，需要手动创建对象的独立副本，比如：

• 使用 Groovy 做浅拷贝：new HashMap(payload)（若对象有嵌套结构，需借助工具实现深拷贝）
• 通过 JSON 序列化再反序列化：将 payload 转为 JSON 字符串，再解析为新的对象
• 使用 Mule 的 Object-to-Object Transformer 配置拷贝规则

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