电商系统中轻量可靠的上下文锁定方式是让runtimeexception携带traceid：自定义异常继承runtimeexception并添加final traceid字段，由调用方显式传入；网关入口生成后透传，关键节点主动绑定，异常链中持续传递，日志首行打印、监控显式打标，跨线程需手动透传traceid。
直接让 RuntimeException 携带 traceId，是电商系统中轻量、可靠且业务侵入小的上下文锁定方式。关键不是“加个字段”就完事，而是确保 traceId 在异常创建那一刻就被固化、可提取、不丢失。
定义带 traceId 的自定义异常
继承 RuntimeException，只增加一个 final 字段和 getter，不重写 getMessage() 或 printStackTrace()：
- traceId 必须由调用方显式传入，不能在构造器里从 MDC 读取——MDC 可能为空、已被清理，或跨线程失效
- 推荐在网关或入口服务生成 traceId 后，一路透传到业务层；捕获原始异常时，立即用当前上下文的 traceId 包装：throw new BizException("库存扣减失败", currentTraceId, e)
- 避免把 traceId 拼进 message，否则日志解析器无法结构化提取，也干扰错误语义
在订单/支付等关键节点主动绑定
电商核心链路（如下单、锁库存、创建支付单）抛出异常前，必须确保 traceId 已注入：
- 例如在库存校验失败时，不直接 throw new IllegalStateException("库存不足")，而是 throw new InventoryException("库存不足", traceId)
- 若该异常后续会被包装（比如被 Feign fallback 或全局兜底处理器捕获），新异常仍需接收并保留原 traceId，形成 traceId 不断链的异常链
- 不依赖“日志格式自动补 traceId”，因为堆栈本身不含 traceId，异步或跨服务后容易断链
日志与监控中真正用起来
异常对象只是容器，价值体现在消费端：
- 全局异常处理器（如 @ControllerAdvice）中，优先调用 ex.getTraceId()，fallback 到 MDC 或生成临时 ID
- 上报 Sentry/SkyWalking 时，将 traceId 作为 tag 显式设置，而非靠日志行匹配
- 打印日志时用 log.error("InventoryException[{}]: {}", ex.getTraceId(), ex.getMessage(), ex)，保证 traceId 出现在首行，便于 grep 和 ELK 过滤
跨线程场景必须手动透传
CompletableFuture、@Async、定时任务、消息消费者中，ThreadLocal 已失效，但自定义异常依然有效——前提是创建子任务时就把 traceId 提出来：
- 不要写 CompletableFuture.runAsync(() -> {...})，而要写 CompletableFuture.runAsync(() -> { log.info("[{}] 扣减库存", traceId); ... }, executor)
- 或封装 TraceableRunnable：new TraceableRunnable(originalRunnable, currentTraceId)，在 run() 中先 setTraceIdToMDC，再执行原逻辑
- 消息体（如 Kafka header）中携带 traceId，消费者拿到后第一时间注入异常构造上下文，确保后续任何异常都自带 ID
