不能用 initCause() 打包链路 ID，因其仅设置根本原因而不传递 ThreadLocal 上下文；链路 ID 应通过 MDC 注入日志、拼入异常消息或跨线程透传实现。
不能用 initCause() 打包链路 ID。
initCause 不处理线程上下文信息
initCause() 只负责把一个 Throwable 对象设为另一个异常的“根本原因”，它不保存、不复制、也不传递任何业务上下文（比如 traceId、spanId、用户 ID 或请求路径）。链路 ID 属于 ThreadLocal 管理的运行时上下文，和异常链是两个正交机制。
常见误解是：只要在异常上挂了 cause，链路 ID 就会自动带上。实际完全不会——即使你调用 ex.initCause(new RuntimeException("xxx"))，新异常里依然没有 traceId，日志里也看不到 MDC 字段。
链路 ID 的正确落点位置
链路 ID 必须在日志记录环节或异常构造前的上下文快照环节注入，而不是靠异常本身携带：
立即学习“Java免费学习笔记（深入）”；
-
日志框架层面：用 Logback 的
MDC.put("traceId", id)，确保logger.error("msg", ex)输出时自动带入； -
异常包装前：在捕获原始异常后、创建新异常前，把当前 MDC 中的 traceId 提取出来，作为消息的一部分拼进去（例如：
new BizException("[traceId:" + MDC.get("traceId") + "] 订单超时")）； -
跨线程场景：使用
TtlRunnable或TransmittableThreadLocal把主线程的 MDC 快照透传到子线程，再记录日志或抛异常。
代理中间件中推荐做法
在自建代理（如基于 Netty 或 Spring Gateway 的中间件）中，应按如下顺序组织异常处理逻辑：
- 接收请求时，从 header（如
X-Trace-ID）提取并写入 MDC； - 转发失败后捕获底层异常（如
TimeoutException或IOException）； - 构造语义明确的代理异常（如
ProxyUpstreamException），优先使用带 cause 的构造器：new ProxyUpstreamException("上游调用失败", e)； - 记录日志时，确保 logger 调用的是
error(String, Throwable)重载方法，并已配置 MDC 输出模板； - 若该异常类确实无 cause 构造器（极少见），才加空检查后调用
initCause(e)，但绝不依赖它传 traceId。
异常链负责追溯“哪里出错”，MDC 负责标记“谁在调用”。两者配合，才能实现完整可观测性。不混用，不替代。
