子事务失败是否影响父事务取决于传播行为：默认REQUIRED时共用事务，子异常导致整体回滚；REQUIRES_NEW则开启独立事务，子失败不影响父；NESTED通过保存点实现局部回滚。
在 Java 中，事务嵌套时子事务失败是否影响父事务，取决于事务传播行为（Propagation Behavior）的配置，而不是“天然嵌套”就自动回滚。默认情况下，Spring 的 @Transactional 并不真正支持物理嵌套事务（JDBC 不支持），而是通过传播机制模拟嵌套逻辑。
默认传播行为：REQUIRED 是关键
Spring 默认使用 PROPAGATION_REQUIRED。此时：
- 若当前已有事务，子方法加入该事务（共用同一个事务上下文）；
- 子方法抛出未被捕获的 运行时异常（RuntimeException）或 Error，整个事务（含父、子操作）都会标记为 rollback-only；
- 父事务方法后续即使正常执行，最终也会整体回滚。
✅ 示例场景：
@Transactional
public void parent() {
insertOrder(); // A
child(); // B → 抛出 RuntimeException
updateStock(); // C → 不会执行（事务已标记回滚）
}
@Transactional
public void child() {
insertOrderItem();
throw new RuntimeException("库存不足");
}→ 最终 insertOrder() 和 insertOrderItem() 全部回滚。
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
⚠️ 注意：若 child() 中捕获了异常且未重新抛出，父事务不会感知失败，将正常提交。
想让子事务失败不影响父事务？用 REQUIRES_NEW
设置子方法为 @Transactional(propagation = Propagation.REQUIRES_NEW)：
- Spring 会挂起当前事务，开启一个全新物理事务；
- 子事务独立提交或回滚，不影响父事务状态；
- 即使子事务回滚，父事务仍可继续执行并提交（前提是它自己不出错）。
✅ 示例：
@Transactional
public void parent() {
insertOrder();
child(); // 新事务，失败只回滚自己
updateStock(); // 仍会执行
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void child() {
insertLog();
throw new RuntimeException(); // 仅 log 回滚，order 和 stock 不受影响
}⚠️ 注意：
-
REQUIRES_NEW会导致事务隔离（如数据库连接、锁、一致性视图）完全独立； - 日志类、通知类操作常用此模式，避免因辅助逻辑失败拖垮主流程。
其他传播行为的影响简列
-
SUPPORTS/NOT_SUPPORTED/NEVER：不创建事务，子方法失败自然不影响父事务（但也不受事务保护）； -
MANDATORY：必须在已有事务中运行，否则抛异常，失败则父事务同命运； -
NESTED（需底层支持，如 JDBC 保存点）：- 在同一事务内建立保存点（savepoint）；
- 子事务回滚仅回退到保存点，父事务可继续；
- 需数据库和
DataSourceTransactionManager支持（Hibernate/JPA 默认不启用，需显式配置）。
实际开发中的关键提醒
- 运行时异常（
RuntimeException及其子类）默认触发回滚；检查异常（Exception）默认不回滚，除非用@Transactional(rollbackFor = Exception.class)显式声明； -
@Transactional仅对 public 方法生效，且调用必须走 Spring 代理（避免本类内部直接调用）； - 日志、异步操作、远程调用等脱离当前事务上下文的操作，无法被事务管理——不要误以为加了
@Transactional就万事大吉。
不复杂但容易忽略。
