上下文丢失的根本原因是线程切换导致ThreadLocal数据未传递，而非拒绝策略；正确做法是显式提取并传入userId、requestId等关键信息，或使用ContextAwareThreadPoolTaskExecutor自动传递安全上下文。
这个问题其实不是“自定义拒绝策略导致上下文丢失”，而是混淆了两个独立但常被同时遇到的问题：一个是线程池拒绝策略的配置逻辑，另一个是异步线程中请求上下文（如 request、securitycontext、mdc 等）天然丢失的本质原因。拒绝策略本身不会造成上下文丢失；它只在队列满、线程数达上限时决定如何处理新任务。真正让异步任务拿不到用户 id、request 或 traceid 的，是线程切换后 threadlocal 数据未传递。
上下文丢失的根本原因不在拒绝策略，而在线程隔离
Spring MVC 中的 HttpServletRequest、SecurityContext、RequestContextHolder 等都依赖 ThreadLocal 绑定到当前 Servlet 线程。@Async 启动的新线程与主线程无继承关系，ThreadLocal 值不会自动复制。哪怕你用 CallerRunsPolicy 让主线程自己执行任务，此时看似“没换线程”，但注意：CallerRunsPolicy 触发的前提是线程池已饱和，而主线程此时往往已退出请求生命周期（比如 Controller 方法早已 return），Request 对象已被容器回收或复用——所以即使任务由主线程执行，拿到的也可能是 null 或他人数据。
正确做法：主动传递关键上下文，而非依赖线程复用
不要指望拒绝策略或线程池配置能“修复”上下文。应显式提取并传入异步方法所需信息：
- 把 userId、tenantId、requestId、IP 等从 RequestAttributes 或 SecurityContextHolder 中提前读出，作为参数传给 @Async 方法
- 避免在异步方法体内调用 RequestContextHolder.getRequestAttributes() 或 SecurityContextHolder.getContext()
- 若需透传 MDC 日志上下文，可在调用前用 MDC.getCopyOfContextMap() 获取快照，进异步方法后用 MDC.setContextMap() 恢复
- 对 RestTemplate 或 WebClient 等客户端，可封装带 traceId 和认证头的模板实例，而非依赖线程绑定的上下文
线程池配置要合理，但别让它掩盖上下文问题
虽然拒绝策略不引发丢失，但不当配置会放大问题表现（例如大量任务堆积后集中触发 CallerRunsPolicy，导致主线程阻塞、请求超时、上下文更不可靠）：
- 用 ThreadPoolTaskExecutor 替代 SimpleAsyncTaskExecutor，禁用 Executors 工厂方法
- 设置有界队列（setQueueCapacity），避免内存无限增长
- 拒绝策略优先选 CallerRunsPolicy，但需接受它可能拖慢上游——这是权衡，不是缺陷
- 线程名加前缀（如 setThreadNamePrefix("async-user-")），方便日志中区分上下文归属
进阶方案：用 ContextAwareThreadPoolTaskExecutor 自动传递
若项目中大量异步调用且上下文字段固定，可封装一个装饰型线程池，自动拷贝 ThreadLocal：
- 继承 ThreadPoolTaskExecutor，重写 execute(Runnable) 和 submit(Runnable)
- 在提交前捕获主线程的 RequestAttributes、SecurityContext、MDC 快照
- 包装 Runnable，使其在执行前先将快照恢复到新线程的 ThreadLocal 中
- 执行完毕后清理，防止内存泄漏（尤其 RequestAttributes 的 remove()）
这种方案适合中大型系统统一治理，但要注意：不能盲目复制所有 ThreadLocal，需识别哪些是安全可传递的（如 traceId、userId），哪些是容器强绑定的（如原始 HttpServletRequest 对象本身）。
