异步线程抛出异常时主线程无法获取原始请求上下文，因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></string>），主线程通过唯一 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），避免序列化大对象或敏感内容