Java中保证异常下业务数据一致性需结合事务控制、异常分类处理与补偿机制。Spring用@Transactional默认仅对RuntimeException回滚，需显式配置rollbackFor；避免吞异常、同类调用及非public方法加注解；业务异常不回滚但需友好提示，系统异常通常回滚并视情况重试；分布式场景用SAGA模式实现最终一致性，强调幂等与补偿兜底；数据库层面配合约束、乐观锁与操作日志提升可靠性。
Java中保证异常下业务数据一致性，核心在于事务控制 + 异常分类处理 + 补偿或回滚机制。不是简单try-catch就能解决，关键看数据操作是否跨资源、是否涉及分布式场景。
用事务确保单体应用的数据原子性
在Spring环境中，最常用方式是@Transactional注解。它默认只对RuntimeException及其子类触发回滚，检查异常（如IOException）不会自动回滚。
- 显式配置rollbackFor = {Exception.class}可让所有异常都回滚
- 避免在事务方法内吞掉异常（比如空catch），否则事务无法感知失败
- 事务方法不能被同类内方法直接调用（会绕过代理，事务失效）
- 非public方法加@Transactional无效
区分异常类型，决定是重试、补偿还是告警
业务异常不等于系统异常。比如“余额不足”是预期业务规则，应抛出自定义异常（如InsufficientBalanceException），由上层捕获后返回友好提示；而数据库连接超时属于系统异常，可能需要重试或降级。
- 业务异常：不回滚事务，但需明确响应用户（如400 Bad Request）
- 系统异常：通常触发事务回滚，再根据场景决定是否重试（如幂等接口+网络超时）
- 不可恢复异常（如OutOfMemoryError）：记录日志并快速失败，避免拖垮服务
跨服务或最终一致性场景靠补偿事务
微服务中无法强依赖本地事务，常见做法是SAGA模式：把一个大业务拆成多个本地事务步骤，每步执行成功后发消息/写日志，失败则按反向顺序执行补偿操作（如扣款成功后库存扣减失败，就触发退款）。
- 关键点：每个子步骤必须是幂等的
- 补偿操作本身也要有失败兜底（如异步任务重试 + 人工干预入口）
- 可用Seata、Eventuate等框架简化SAGA编排
数据库层面配合提升可靠性
代码层控制之外，数据库设计也影响一致性保障效果：
- 合理使用约束（UNIQUE、CHECK、外键）在存储层拦截非法状态
- 更新时带上版本号或时间戳做乐观锁，防止并发覆盖
- 高频写场景慎用SELECT FOR UPDATE，避免长事务阻塞
- 关键业务表增加操作日志表（如trade_log），便于问题追溯和对账
基本上就这些。不复杂但容易忽略——重点不在写多少catch块，而在清楚每一处异常意味着什么、该由谁负责兜底、数据当前处于哪个一致状态。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
