android messenger 不支持 stamp 机制和链路追踪上下文透传，只能通过 bundle 或 parcelable 显式传递 trace_id 等字段；每跳通信均需手动提取并重写上下文，否则链路断裂。
Android 的 Messenger 本身不支持 Stamp 机制，也没有内置的链路追踪上下文透传能力——这是 Symfony Messenger 或分布式 OpenTracing 系统的概念，不能直接套用到 Android IPC 场景中。
Android Messenger 没有 Stamp 或 Envelope 概念
Android 的 Messenger 是基于 Handler + Message + IBinder 的轻量封装，其消息载体只有 Message 类型。该类仅提供以下可跨进程序列化的字段：
-
what（整型操作码） -
arg1/arg2（简单整数参数） -
obj（要求实现Parcelable或Serializable） -
data（Bundle，唯一支持键值对元数据的容器） -
replyTo（Messenger，用于服务端回传）
它没有类似 Symfony 的 Envelope 包裹层，也不支持自定义邮票（Stamp）扩展。所谓“Stamp 机制”在 Android 原生 Messenger 中并不存在。
想传 TraceID？只能塞进 Bundle 或自定义 Parcelable
若需在跨进程调用中传递链路追踪 ID（如 trace_id、span_id），唯一可行路径是利用 Message.getData() 返回的 Bundle，或把上下文打包进 obj 字段：
-
Bundle最常用：客户端发送前 putString("trace_id", "0123456789abcdef")，服务端通过msg.getData().getString("trace_id")读取 - 若业务消息已是自定义
Parcelable对象（如OrderRequest），建议在其内部字段中显式添加String traceId，而非依赖外部元数据 - 避免用
obj传HashMap或非 Parcelable 对象——会抛RuntimeException（"Parcelable encountered IOException"
示例片段：
// 客户端
Message msg = Message.obtain();
msg.what = 1001;
Bundle data = new Bundle();
data.putString("trace_id", currentTraceId);
data.putString("span_id", currentSpanId);
msg.setData(data);
try {
mService.send(msg);
} catch (RemoteException e) { /* ... */ }
服务端回传时也要手动携带上下文
服务端处理完请求后，若需将结果连同原始 trace 上下文一并返回，必须主动从入参 msg.getData() 中取出并重新写入 reply Message：
- 不能依赖“自动继承”或“隐式透传”——
Messenger不维护任何上下文生命周期 - 若忘记复制
trace_id，下游客户端将丢失链路连续性，导致调用链断裂 - 尤其注意多级转发场景（A→B→C）：每跳都需显式提取 + 重写，否则中间节点会丢上下文
真正容易被忽略的是：Android Messenger 的通信模型是纯消息驱动、无状态、无上下文栈的。你写的每一行 msg.getData().putString(...) 都是硬编码的契约，一旦客户端和服务端字段名不一致，或某一方漏读/漏写，整个链路追踪就失效——它不像 HTTP header 或 gRPC metadata 那样有统一注入点和传播协议。
