initCause()仅用于构建异常链以保全根因信息，不传递ThreadLocal上下文；线程上下文丢失源于ThreadLocal不继承，需通过快照复制（如TtlRunnable、MDC预埋）解决。
java里initcause()和线程上下文切换时的异常丢失，是两类不同维度的问题：前者解决**异常链的信息保全**，后者解决**跨线程执行时请求上下文（如用户id、traceid、事务状态）的不可见性**。它们常在异步场景中同时出现，但成因与解法截然不同——混淆二者会导致兜底失效、日志断层、排查失焦。
initCause()：专治“异常失真”，不负责传上下文
initCause()只做一件事：给一个已创建、但尚未设cause的异常对象，绑定原始异常，从而形成可追溯的Caused by链。它不传递ThreadLocal里的请求变量，也不感知线程切换。
- 适用场景：自定义异常类没提供
(String, Throwable)构造器，又必须保留底层异常（如把SocketTimeoutException转为ReconciliationTimeoutException） - 关键约束：只能调用一次；目标异常的
getCause()必须为null；不能在fillInStackTrace()之后调用 - 错误认知：以为调用
initCause()就能让主线程看到子线程里的userId或requestURI——这完全无效
线程上下文丢失：根源在ThreadLocal不继承
当任务提交到线程池或开启新线程后，新线程拥有独立的ThreadLocalMap，主线程存的RequestContextHolder、SecurityContextHolder、MDC等全部为空。此时即使抛出带initCause()的异常，堆栈里也只含技术细节，没有业务维度线索。
- 典型表现：异步任务中日志缺失
traceId；全局异常处理器收不到userId；@Async方法内SecurityContext为空 - 根本对策：不在“事后”还原，而在“事前”快照——把关键字段从主线程提取出来，显式传入子线程
协同解法：异常链 + 上下文快照双加固
真实高可用系统（如金融对账服务）需同时解决两层丢失：技术根因不可见 + 业务上下文不可见。推荐组合策略：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用标准构造器包装异常（优先于
initCause()）：如throw new BusinessException("对账失败", e)，自然形成多级Caused by - 自定义异常携带上下文字段：构造时传入
traceId、userId、requestUri，覆写toString()确保日志自动打印 - 异步任务启动时主动复制上下文：通过
TaskDecorator注入RequestAttributes，或用TtlRunnable封装Runnable - 日志框架预埋MDC：在子线程入口调用
MDC.put("traceId", ...)，并确保finally中清理，避免脏数据污染后续任务
避坑提醒：别让“异常处理”掩盖“上下文治理”
很多团队花大力气统一异常体系、加initCause()、配Caused by格式，却忽略异步线程里log.info("开始处理")连traceId都没有。结果是：堆栈再完整，也查不到这笔请求是谁发的、在哪台机器上超时、走的哪条路由。上下文快照不是锦上添花，而是故障定位的底线能力。
立即学习“Java免费学习笔记（深入）”；
