异常堆栈本身不带traceId，因JVM在Throwable构造时已固化堆栈数组；需在异常创建瞬间通过Java Agent字节码增强或自定义Throwable子类注入traceId，并确保traceId全程透传。
异常堆栈本身不带 traceId，不是日志格式没配好，而是 JVM 在 Throwable 构造时就固化了堆栈数组，日志框架只能在输出行里补 ID，无法修改原始堆栈内容。要让异常变量（比如 e）本身携带 traceId，必须在异常创建的瞬间干预，而不是等它被 log.error() 打印时再处理。
为什么普通 MDC + 日志 Pattern 不够用
常见做法是在日志模板里加 %X{traceId}，这能让每条日志行开头显示 ID，但对异常堆栈无效。例如：
-
logger.error("查询失败", e)输出的日志行有 traceId，但e.getStackTrace()里的每一行仍是纯类名+方法+行号，没有 traceId 字符串 - 如果异常被多层 catch-wrapping（如 Spring 的
@ExceptionHandler或 Feign fallback），原始堆栈会丢失，新异常的堆栈又没 traceId - 运维查问题时，靠日志行过滤能定位请求，但看到堆栈里没有 traceId，就无法确认这个堆栈是否属于当前链路，尤其在异步或线程池复用场景下容易误判
真正生效的两种注入方式
目标是让 Throwable 实例本身的堆栈元素（StackTraceElement[]）包含 traceId，而不是只靠日志渲染。目前只有两类方案能稳定达成：
-
Java Agent 字节码增强：在
Throwable.<init>所有构造方法末尾插入逻辑，调用setStackTrace()替换堆栈数组，把每个toString()结果重写为"[trace-abc123] com.example.Service.doWork(Service.java:42)"格式。这是最彻底的方式，无需改业务代码，SkyWalking JavaAgent 就是这样实现的 -
自定义 Throwable 子类 + 强制使用：定义
TracedRuntimeException，在构造时主动读取 MDC 中的 traceId，并通过setStackTrace()染色；再配合 AOP 或全局异常处理器，把原始异常包装成该类型。缺点是需约定异常抛出方式，对第三方库异常不可控
配套必须做的三件事
光“染色”异常还不够，traceId 必须全程在线，否则染色无源可溯：
- HTTP 入口统一生成或透传
X-Trace-ID，并立即存入 MDC；Spring Boot 可用OncePerRequestFilter实现 - 所有异步调用（
@Async、线程池、CompletableFuture）必须手动传递 MDC 内容，可用MDC.getCopyOfContextMap()+MDC.setContextMap()配合Runnable包装 - 日志框架配置中保留
%X{traceId}，确保非异常日志、慢 SQL、SQL 参数等上下文也带 ID，和染色后的堆栈形成交叉验证
不复杂但容易忽略：异常堆栈染色只是最后一环，前提是 traceId 已经在整条链路上跑通。否则你看到的是一堆带 ID 的假堆栈，实际跟请求无关。
