在Apache Camel的集成场景中，我们经常需要把外部系统发来的JSON、XML等格式数据反序列化为Java对象，以便在Processor或Bean中直接操作。但反序列化之后，Camel Exchange的In消息体已经被替换成POJO，原始的字符串或字节流似乎“消失”了。实际上，Camel提供了多种机制，让我们在享受类型转换便利的同时，依然能够保留并访问最初始的输入消息。
为什么反序列化后会丢失原始消息
Camel的消息模型基于Exchange，其中In消息的Body在每一次类型转换时都可能被覆盖。当你使用uniMarshal()或者声明了.json()等数据格式时，Camel会调用对应的Type Converter或Data Format，把In Body替换为反序列化后的对象。如果不做额外处理，原来的字符串内容就不再直接存在于消息体中。
这种设计的初衷是为了让路由逻辑更简洁，开发者不需要关心底层传输格式。但在实际工作中，我们常常需要在反序列化后做审计日志、报文重放、签名验证，或者当反序列化失败时把原始报文记录下来便于排查。因此，理解Camel如何管理消息体生命周期，是保留原始输入的前提。
利用StreamCache开启消息体重用
最简单也最基础的做法是开启StreamCache。默认情况下，如果消息体是Stream类型（例如HTTP请求体），它只能被读取一次。开启streamCaching之后，Camel会把流缓存到内存或磁盘，允许后续多次读取原始内容。
在Spring Boot环境中，可以通过配置全局开启：
// 在Spring Boot的application.properties中
// camel.springboot.stream-caching=true
// 或者在Java DSL路由中针对某条路由开启
from("direct:start")
.streamCaching()
.unmarshal().json(JsonLibrary.Jackson, Order.class)
.process(exchange -> {
// 即使已经反序列化，依然可以读取原始字符串
String raw = exchange.getIn().getBody(String.class);
exchange.setProperty("rawInput", raw);
});
上面代码中，streamCaching()确保Body可以被反复转换。在unmarshal之后调用getBody(String.class)，Camel会从缓存中重新读出原始文本，而不是报错或返回null。我们把这个值存到Exchange属性rawInput里，后续任何节点都能通过exchange.getProperty("rawInput")拿到。
需要注意的是，StreamCache会消耗一定内存或临时文件资源。如果原始报文非常大，建议结合Camel的streamCaching配置调整阈值，或者只在确实需要保留原始输入的路由上局部开启，而不是全局强制。
通过自定义Processor显式保存原始消息
如果你不想依赖StreamCache的自动行为，也可以在反序列化之前，用Processor把原始Body复制一份。这种方式逻辑更直观，也更容易控制保存的内容格式。
下面是一个在反序列化前保存原始字符串的示例：
from("jetty:http://0.0.0.0:8080/api/order")
.process(exchange -> {
// 反序列化前，先以字符串形式读取并暂存
String original = exchange.getIn().getBody(String.class);
exchange.setProperty("originalPayload", original);
})
.unmarshal().json(JsonLibrary.Jackson, Order.class)
.bean(orderService, "handleOrder")
.process(exchange -> {
// 在业务处理之后，依然可以访问原始输入
String raw = (String) exchange.getProperty("originalPayload");
log.info("原始报文为: " + raw);
});
这种写法的好处是，不需要理解Type Converter在背后是否修改了消息体，我们主动在最早节点把内容提取出来。即使后续路由里消息被多次转换，属性中的字符串始终不变。
缺点是如果输入本身是二进制或超大文本，提前转成String可能占用较多堆内存。此时可以保存原始InputStream并配合StreamCache，或者只保存长度、摘要等元信息，具体取决于业务需要。
使用Exchange属性与Header的区别
很多初学者会问：为什么不直接把原始消息放到Header里？在Camel中，Header通常用于描述消息的元数据，例如Content-Type、请求ID等，而Body才是真正的业务负载。把巨大的原始报文放进Header，不仅不符合语义，还会让日志输出、序列化变得臃肿。
Exchange属性（Property）是专门用于在路由内部传递中间状态的容器，不参与协议头的映射，也不会被JMS、HTTP等传输组件误发到外部系统。因此，保留原始输入最规范的做法是写入Property，例如exchange.setProperty("rawBody", original)。
| 存储位置 | 适合内容 | 是否随协议外发 |
|---|---|---|
| Body | 当前主要处理对象 | 是 |
| Header | 轻量元数据 | 是 |
| Property | 路由内部中间状态 | 否 |
通过上表可以看出，Property在“保留原始输入但不干扰对外传输”这一点上是最合适的。如果你的原始报文需要在不同系统间透传，那另当别论，此时应作为Body或特定Header处理。
反序列化失败时的原始消息留存
在真实环境中，外部数据可能格式错误。Camel的unmarshal一旦失败会抛出Exception，导致后续Processor根本执行不到。为了在这种情况下也能拿到原始输入，可以使用doTry和doCatch结构。
from("direct:safeUnmarshal")
.process(exchange -> {
exchange.setProperty("rawBackup", exchange.getIn().getBody(String.class));
})
.doTry()
.unmarshal().json(JsonLibrary.Jackson, Order.class)
.doCatch(Exception.class)
.process(exchange -> {
String raw = (String) exchange.getProperty("rawBackup");
log.error("反序列化失败，原始报文: " + raw);
exchange.getIn().setBody("invalid request");
})
.end();
在doTry之前先把原始报文备份到Property，即使unmarshal抛出异常进入doCatch，我们依然能通过Property取到出问题的文本。这样运维人员可以直接看到是哪一条数据不合法，而不必让用户重新发送并猜测错误原因。
该模式对对接第三方不稳定接口尤其有用。配合Camel的错误处理策略，还可以把原始报文写进死信队列（DLQ）的消息体或属性中，形成完整的故障现场记录。
结合Type Converter与Raw Body的最佳实践
如果你的路由非常复杂，中间经过多个组件，每次都手动存Property会比较繁琐。此时可以封装一个通用的Camel组件或Processor，在路由起始处统一保存原始输入，并通过命名约定（如RAW_BODY）让所有开发者都知道如何获取。
示例封装如下：
public class RawBodySaver implements Processor {
public static final String RAW_BODY = "RAW_BODY";
public void process(Exchange exchange) {
Object body = exchange.getIn().getBody();
if (body instanceof String) {
exchange.setProperty(RAW_BODY, body);
} else {
// 非字符串时尝试转成字符串备份
exchange.setProperty(RAW_BODY, exchange.getIn().getBody(String.class));
}
}
}
在路由中只需.process(new RawBodySaver())即可。之后无论经过多少marshal、unmarshal、transform，任何节点都能用exchange.getProperty(RawBodySaver.RAW_BODY)读取最开始的输入。这种实践在团队规范落地后，能显著降低“原始消息去哪了”的沟通成本。
总结来说，Apache Camel并没有在反序列化后真正删除原始输入，只是把它从In Body中替换掉了。只要我们善用StreamCache、Exchange属性以及Processor的先后顺序，就能在不破坏类型化开发体验的前提下，随时保留并访问原始输入消息。
Apache_Camel反序列化原始消息修改时间：2026-08-02 08:18:36