@Transactional 在 Lambda 中异常不回滚的根本原因是异常未穿透到方法边界，事务切面无法捕获；典型场景包括 Stream.forEach、Optional.ifPresent 和 CompletableFuture 异步回调；解决办法是将校验移出 Lambda、手动收集重抛异常或改用显式循环。
Spring 的 @Transactional 在 Lambda 表达式中抛出异常时不会回滚，根本原因不是 Lambda 本身，而是异常被“吞掉”或“未穿透到事务切面”——事务管理器压根没看到它。
Lambda 中异常不触发回滚的典型场景
常见于使用 Stream、Optional 或异步回调时，例如：
- 在
stream().forEach(...)里抛出 RuntimeException，但该异常被 forEach 内部静默处理或未传播到方法体顶层； - 用
Optional.ifPresent(() -> { throw new RuntimeException(); })，异常被限制在 Consumer 内部，方法本身正常返回； - 在 CompletableFuture 的
thenAccept或handle中抛异常，该异常属于异步线程，主事务早已提交。
关键问题：异常没“走到事务拦截点”
@Transactional 依赖 Spring AOP 代理在方法**出口处**捕获未处理异常。而 Lambda 是独立执行单元，其异常不会自动冒泡到被注解的方法签名层面。
比如下面这段代码：
@Transactional
public void processUsers(List<User> users) {
users.stream()
.filter(u -> u.getAge() > 0)
.forEach(u -> {
userMapper.insert(u);
if (u.getId() == null) throw new IllegalArgumentException("id missing"); // ← 这个异常不会触发回滚
});
}
因为 forEach 是 void 方法，内部异常只中断当前 Consumer，processUsers 方法仍正常结束，事务照常提交。
实用解决办法
- 避免在 Lambda 里抛业务异常：把校验和操作提前到 stream 外，或改用显式循环（for / enhanced for），确保异常能穿透方法体；
-
手动收集异常并重抛：在 Lambda 中捕获异常，存入集合，循环结束后统一抛出；
List<Exception> errors = new ArrayList<>(); users.forEach(u -> { try { userMapper.insert(u); } catch (Exception e) { errors.add(e); } }); if (!errors.isEmpty()) { throw new RuntimeException("批量插入失败", errors.get(0)); } -
用支持异常传播的替代写法：如 Apache Commons Collections 的
CollectionUtils.forAllDo（需配合自定义异常处理器），或封装带异常声明的函数式接口 + 显式 try-catch； -
异步场景必须另起事务：若 Lambda 运行在新线程（如
supplyAsync），原事务上下文不继承，需用@Async+@Transactional组合，并确保线程池支持事务传播（通常需TransactionSynchronizationManager手动绑定）。
补充提醒
即使你用了 rollbackFor = Exception.class，也解决不了 Lambda 异常不外泄的问题——参数只影响“捕获到异常后是否回滚”，前提是异常得先被事务拦截器看见。所以核心永远是：让异常真正到达被 @Transactional 标注的方法边界。
