Java事务上下文在多线程异步调用中丢失，根本原因是Spring事务依赖ThreadLocal绑定主线程，子线程无法继承TransactionSynchronizationManager中的资源；强行透传（如TTL）会导致事务状态错乱，正确解法是业务补偿、分布式事务（如Seata）或同步编排。
Java 事务上下文在多线程异步调用中丢失，不是代码写错了，而是 Spring 事务管理机制本身的限制：事务绑定在主线程的 TransactionSynchronizationManager 上，而该管理器底层依赖 ThreadLocal。一旦任务提交到线程池或开启新线程，子线程就拿不到父线程的事务状态——事务自然“失效”，连 @Transactional 注解都形同虚设。
为什么事务上下文会丢？根本不在“异常链”里
事务上下文丢失和 initCause() 完全无关。前者是 TransactionSynchronizationManager 中的 resources、synchronizations、currentTransactionName 等 ThreadLocal 变量未被继承；后者只负责异常堆栈的因果追溯。混淆这两者，容易把日志断层当成事务问题，或反过来，用异常包装掩盖真正的事务隔离失效。
- 主线程开启事务后，所有 DAO 操作都靠 ThreadLocal 拿到同一个 Connection
- 子线程没有这份 ThreadLocal 副本，就会新建 Connection，脱离原事务，变成独立提交
- 哪怕你用
CompletableFuture.supplyAsync(() -> {...}, executor)，只要没显式传递事务资源，就一定不参与主事务
别传 Connection，要传事务语义本身
直接把 Connection 或 DataSource 赋给子线程不仅危险（连接泄漏、并发冲突），而且违背 Spring 的事务抽象原则。正确做法是让子线程“理解并加入”当前事务语义，而非复制物理资源。
- 禁止手动 setConnection() 或 new JdbcTemplate(dataSource)：绕过 Spring 事务代理，彻底脱离管控
-
优先使用声明式传播行为：如需子任务也走同一事务，改用
@Transactional(propagation = Propagation.REQUIRED)并确保它运行在**同一线程**——即放弃异步，改用同步编排 - 若必须异步且要事务一致性：采用最终一致性方案，比如发消息（RocketMQ事务消息 / Kafka幂等+补偿）代替跨线程事务
真要异步又想“事务感”，得换思路
Spring 的 DataSourceTransactionManager 天然不支持跨线程事务传播。强行透传 ThreadLocal 只会让事务状态错乱（如 commit 两次、rollback 无 effect），风险远大于收益。实用路径有三条：
立即学习“Java免费学习笔记（深入）”；
- 业务拆分 + 补偿事务：主流程 commit 后，通过 MQ 触发下游异步操作；失败时由补偿服务回滚或重试
- 使用支持分布式事务的中间件：Seata AT 模式可自动拦截 SQL 并注册分支事务，子线程通过上下文透传（如 TTL + 自定义上下文）携带 xid，参与全局事务
- 轻量级上下文快照 + 手动控制：在主线程 commit 前，把关键业务状态（订单号、金额、操作类型）存入 DB 或缓存；子线程读取快照执行，结果写回并触发校验
避坑提醒：TTL 不是万能钥匙
用 TransmittableThreadLocal 确实能把 TransactionSynchronizationManager 的变量“复制”过去，但这只会让子线程误以为自己在事务里，实际数据库连接已不同，commit 无效，甚至引发连接池耗尽。TTL 适合传 traceId、userId 这类只读上下文，绝不适合传事务资源。
- 检查是否启用了
TransactionSynchronizationManager.isActualTransactionActive()，而不是只看 ThreadLocal 是否非空 - 日志里出现 “Creating new transaction with name…” 却在子线程里，说明事务已被重置，不是透传成功，而是失效重建
- @Async 方法上加 @Transactional 无效——Spring AOP 代理只作用于当前线程，子线程无代理对象
