异步线程抛出异常时主线程无法获取原始请求上下文，因ThreadLocal数据不跨线程继承；必须在任务启动时主动快照关键字段（如userId、traceId、URI）并绑定至异常或MDC，方可实现可追溯的日志与告警。
异步线程抛出异常时，主线程无法直接获取原始请求上下文（如用户ID、TraceId、请求路径、参数等），是因为这些信息通常存于 ThreadLocal 中（例如 RequestContextHolder、SecurityContextHolder、MDC），而新线程不自动继承父线程的 ThreadLocal 副本。主线程捕获到的只是一个“裸异常”，堆栈里没有请求维度的上下文线索，排查困难、告警失焦、日志断层。
异常发生时上下文为何不可见
主线程处理完 HTTP 请求后很快退出，Servlet 容器回收或重置 HttpServletRequest 对象；异步线程中若未显式保存并传递上下文，一旦抛异常，JVM 只会记录该线程当时的局部变量和堆栈，不会回溯主线程的请求快照。更严重的是：若异常处理逻辑（如全局 @ExceptionHandler）运行在主线程，它根本收不到异步线程里的上下文——两者物理隔离，无共享内存，也无隐式关联。
关键信息必须在异常抛出前主动捕获
不能依赖“事后还原”，而要在异步任务启动时就将关键上下文快照化、序列化、绑定到异常对象上。常见做法包括：
-
封装自定义异常类：继承
RuntimeException，构造时接收userId、traceId、requestUri、params等字段，并覆写toString()或getLocalizedMessage()，确保日志打印时自动携带 - 利用异常 cause 链注入上下文：在 try-catch 中捕获原始异常后，new 一个带上下文信息的新异常，以原异常为 cause，形成可追溯的异常链
-
通过 MDC 预埋日志上下文：在异步任务开始前调用
MDC.put("traceId", ...)、MDC.put("userId", ...)，确保即使异常未被捕获，Logback/Log4j 输出的日志行仍含关键字段（需配合异步线程清理 MDC）
主线程如何安全地感知并聚合异步异常
主线程本身不执行异步逻辑，因此不能“等待异常发生再还原”。真正可行的方式是：让主线程持有对异步任务的引用，并统一约定异常处理入口。典型模式有：
-
CompletableFuture 的 exceptionally / handle 回调：在回调中主动读取当前已复制的上下文（如从闭包捕获的
requestAttributes），再包装异常或打点日志 -
@Async 方法返回 Future 并显式 get()：主线程调用
future.get()会阻塞并抛出封装后的ExecutionException，其 cause 即原始异常；此时主线程仍处于请求生命周期内，可立即调用RequestContextHolder.getRequestAttributes()补全上下文字段 -
全局异步异常处理器（需配合 TaskDecorator）：在
TaskDecorator中为每个异步任务包裹 try-catch，捕获异常后存入线程安全容器（如ConcurrentHashMap<String, Throwable>），主线程通过唯一 taskId 查询并组装完整异常报告
避免二次污染：上下文快照要“只读”且“轻量”
不要在异步线程中直接传递 HttpServletRequest 或 Principal 对象——它们可能被容器回收或修改。应提取必要字段做不可变快照：
- 用户标识：
SecurityContextHolder.getContext().getAuthentication().getName() - 链路标识：
Tracer.currentSpan().context().traceIdString()或MDC.get("traceId") - 请求特征：
request.getRequestURI()+request.getMethod()+Optional.ofNullable(request.getRemoteAddr()).orElse("unknown") - 业务参数：仅取关键 ID 类字段（如 orderNo、userId），避免序列化大对象或敏感内容
