Java批量操作安全回滚的核心是关闭自动提交并手动管理事务：获取连接后设setAutoCommit(false)，执行executeBatch()，成功则commit，异常则rollback，并在finally中恢复状态；需用BatchUpdateException识别失败点，统一回滚整个批次；Spring中注意@Transactional生效条件及补偿机制设计。
Java 中批量操作异常时要安全回滚数据，核心是**把批量执行纳入显式事务边界，并在异常发生时主动 rollback**。JDBC 默认自动提交（auto-commit = true），每条语句独立生效，一旦某条失败，前面成功的已无法撤回——这根本不是“批量”，而是“伪批量”。真安全回滚必须关掉自动提交、统一控制提交/回滚时机。
必须关闭自动提交并手动管理事务
这是所有安全回滚的前提。不设 setAutoCommit(false)，就不存在“整个批次一起成功或一起失败”的可能性。
- 获取连接后立即调用
connection.setAutoCommit(false) - 批量执行（
executeBatch()）完成后，仅当无异常才调用connection.commit() - 只要捕获到
BatchUpdateException或任何其他异常（如SQLException），必须立刻调用connection.rollback() - 务必在
finally块或 try-with-resources 中恢复连接状态（如重置为 auto-commit=true）并关闭资源
正确识别批量中的失败点
BatchUpdateException.getUpdateCounts() 返回的数组，每个元素对应一条语句的结果：
-
Statement.SUCCESS_NO_INFO (-2)：执行成功，但没返回影响行数 - ≥ 0 的整数：该语句实际影响的行数
-
Statement.EXECUTE_FAILED (-3)：该语句执行失败
注意：从第一个 -3 开始，后续条目常也为 -3（驱动行为略有差异）。不要依赖具体索引做局部恢复，而应以“首次出现 -3”为信号，**对整个批次执行统一回滚**——这才是 ACID 原子性的体现。
Spring 环境下避免事务失效陷阱
若使用 @Transactional 注解，需警惕常见失效场景：
立即学习“Java免费学习笔记（深入）”；
- 方法必须是
public，否则代理不生效 - 不要在同一个类中自调用（A 方法调 B 方法，B 有
@Transactional），事务不会启动 - 异常不能被静默吞掉：catch 后只打印日志却不 re-throw，事务会照常提交
- 受检异常（如
SQLException）默认不触发回滚，需显式写@Transactional(rollbackFor = SQLException.class)
文件或跨服务等非数据库操作需另设补偿机制
数据库事务只管本库操作。如果批量逻辑还涉及写文件、调外部 API、发消息等，单纯 DB 回滚不够：
- 文件操作：提前备份原文件，失败时还原；或用 NIO2 的
FileChannel.truncate()回退到预存位置 - 跨服务调用：采用 Saga 模式，为每步定义正向操作和对应的补偿接口（如“扣库存”对应“补库存”），失败时按反序调用补偿
- 所有补偿动作必须幂等，建议用唯一事务 ID 做执行记录，防止重复回滚
