java多表操作事务一致性需用@transactional确保同进同退：注解仅限public方法、需spring管理、默认仅对runtimeexception回滚，多表写入须在同一事务内完成，并防跨数据源、异步、锁超时等导致的事务失效。
在 Java 多表操作中保证事务一致性，核心是让所有写入操作“同进同退”——要么全部成功落库，要么全部不生效。这不能靠业务代码手动拼 SQL 或逐个 try-catch 实现，而要依赖数据库事务机制 + 框架层的正确封装。
用 @Transactional 正确声明事务边界
Spring 的 @Transactional 是最常用、最直接的方式，但必须注意几个关键点：
- 注解只能加在 public 方法 上，且该方法需由 Spring 容器管理（不能自己 new 或静态调用）
- 默认只对 RuntimeException 及其子类 回滚；若想对检查异常（如 Exception）也回滚，需显式写
@Transactional(rollbackFor = Exception.class) - 事务默认传播行为是
REQUIRED，即有事务就加入，没事务就新建；跨服务调用时，若未开启远程事务支持，事务不会自动传递 - 避免在同一个 Service 类中用 this. 调用另一个带 @Transactional 的方法——这会绕过代理，导致事务失效
多表写入必须在一个事务内完成
比如苍穹外卖提交订单：要同时插入 orders 主表、order_detail 明细表，并清空用户购物车。这三步必须包裹在同一个事务中：
- 先校验库存、计算金额、生成订单号等前置逻辑（不涉及 DB 写入）
- 再执行
orderMapper.insert(order)→ 获取主键 ID - 再循环执行
orderDetailMapper.insert(detail)，每条 detail 关联刚生成的 order.id - 最后执行
shoppingCartMapper.deleteByUserId(userId) - 以上全部在同一个 @Transactional 方法内，任意一步抛异常，全部回滚
避免隐式事务中断或跨数据源失控
以下情况会让事务“看似开启，实则失效”：
- 方法内调用了另一个数据源（如从 MySQL 切到 PostgreSQL），Spring 默认事务管理器只管一个 DataSource，跨库需用 JTA 或 Seata
- 使用了异步处理（如
@Async）、线程池、定时任务触发 DB 修改，这些会脱离原始事务上下文 - MyBatis 执行了
SELECT FOR UPDATE但后续没做 UPDATE/DELETE，或锁超时未捕获，可能引发死锁或长事务 - 事务方法里调用了外部 HTTP 接口，接口失败但 DB 已提交——这不是事务问题，而是需要补偿机制（如 TCC 或消息队列+本地事务表）
必要时配合乐观锁防并发覆盖
当多表更新涉及同一行高频修改（如秒杀扣库存），仅靠数据库事务不够，还需应用层控制：
- 在库存表加
version字段，实体类用@Version标记 - 查询时带 version，更新时 WHERE 条件包含
id = ? AND version = ?，并 SET version = version + 1 - 如果 update 影响行数为 0，说明已被别人抢先修改，此时可重试或提示失败
- 这种方式不阻塞读，适合高并发读多写少场景，但需配合事务一起使用（update 必须在事务内）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
