@transactional在new thread中失效，因threadlocal不跨线程，子线程无事务上下文，数据库操作自动提交；解决需改用线程池传上下文、编程式事务或异步任务剥离事务边界。

这个问题的核心在于：spring 的 @transactional 是声明式事务，底层依赖 threadlocal 绑定事务上下文（如 connection、transactionstatus），而原生 new thread() 创建的线程无法继承主线程的 threadlocal 值——所以子线程压根“看不见”事务，更谈不上回滚。

为什么 @Transactional 在 new Thread 里完全失效

Spring 事务拦截器（TransactionInterceptor）只在代理方法入口生效；子线程中既没走代理，也没事务上下文，所有数据库操作都走默认自动提交模式（autocommit=true）。哪怕主线程抛异常、回滚，子线程的数据早已落库，无法撤销。

这不是配置问题，也不是注解写错，而是机制性隔离——ThreadLocal 天然不跨线程，这是 JVM 层面的设计，Spring 无法绕过。

真正可用的三种解决路径

不能硬扛 ThreadLocal 限制，得换思路。生产环境推荐以下三类方案，按场景优先级排序：

• 用线程池 + TransactionSynchronizationManager 手动传递上下文
  适用于需复用主线程事务、且子任务逻辑轻量（如日志记录、缓存更新）的场景。
  主线程调用 TransactionSynchronizationManager.getCurrentTransactionName() 等获取关键状态，封装进 Runnable；子线程启动前，用 TransactionSynchronizationManager.bindResource() 手动挂载 Connection 和同步器。注意：必须确保子线程使用同一 DataSource，且不能 commit/rollback，仅跟随主线程命运。
• 改用编程式事务（PlatformTransactionManager）+ 显式控制
  放弃 @Transactional，主线程开启事务后，将 TransactionStatus 对象传给子线程；子线程内通过 transactionManager.commit(status) 或 .rollback(status) 主动参与事务生命周期。
  ⚠️ 关键点：子线程必须和主线程共享同一个 PlatformTransactionManager 实例，且数据库连接不能被关闭或归还连接池。
• 根本规避：异步任务剥离事务边界
  把子线程做的事拆成“事务内标记 + 事务外执行”。例如：
  — 主线程在事务中插入一条 task_queue 记录，状态为 PENDING；
  — 提交事务后，由独立的定时任务或消息监听器（如 RabbitMQ 消费者）拉取并执行；
  — 执行失败可重试、补偿、告警，不污染主流程事务。

哪些“看似可行”的做法要立刻放弃

这些是常见误区，实测无效或引入更大风险：

• 在子线程里重新加 @Transactional：会开启全新事务，与主线程无关，回滚互不影响；
• 用 InheritableThreadLocal 尝试继承：Spring 未使用它，且 Connection 等资源不可序列化、不可继承；
• 把整个业务逻辑塞进一个大事务 + 同步等待子线程：违背异步初衷，还放大锁持有时间，易超时、死锁；
• 手动 setAutoCommit(false) 操作 Connection：脱离 Spring 事务管理，无法触发 AOP 回滚逻辑，极易漏处理。

本质不是“怎么让 @Transactional 跨线程”，而是“要不要让这个操作属于当前事务”。多数时候，答案是否定的——异步任务本就不该卡住主事务。选对边界，比强行穿透更稳健。