shardingsphere 默认不提供分布式事务能力，throw 异常仅回滚本地事务；要实现跨数据源回滚，必须启用 xa（如 atomikos）或 base（如 seata）等分布式事务支持，并确保事务上下文正确传播。
在 ShardingSphere 中，throw 抛出异常本身不会自动触发跨数据源的事务回滚——因为 ShardingSphere 默认不提供分布式事务能力，它只是分片路由中间件。真正能否回滚，取决于你是否启用了分布式事务支持（如 Seata、Atomikos 或 ShardingSphere-JDBC 内置的 XA 实现），以及事务上下文是否被正确传播。
确认是否启用分布式事务支持
ShardingSphere 本身不管理事务提交/回滚，它依赖底层事务框架。若未配置分布式事务，即使 throw new RuntimeException()，也只会回滚当前数据源的本地事务，其他分片的数据可能已提交，造成数据不一致。
- 使用 ShardingSphere-JDBC 时，需在
sharding-jdbc配置中启用transaction-type: XA或BASE（基于 Seata） - 使用 ShardingSphere-Proxy 时，需搭配支持 XA 的连接池（如 Atomikos、Narayana）并开启全局事务管理器
- 检查
spring.shardingsphere.transaction.type是否设为XA或BASE（Spring Boot 场景）
确保业务方法运行在事务上下文中
仅抛异常不够，方法必须被 Spring 的 @Transactional 管理，且传播行为支持嵌套或必需新事务：
- 标注
@Transactional(rollbackFor = Exception.class)，显式指定所有异常都触发回滚 - 避免在非 public 方法、final 方法或同一类内调用上使用
@Transactional（代理失效） - 若涉及多服务调用，确保事务传播属性为
REQUIRED（默认），而非NOT_SUPPORTED或NEVER
XA 模式下异常触发回滚的关键点
启用 XA 后，ShardingSphere 会将多个分片操作纳入同一个 XA 事务分支。此时 throw 异常会触发两阶段提交（2PC）的回滚流程：
- 第一阶段：各数据源执行
prepare，保存 undo log 或锁资源 - 第二阶段：事务管理器收到异常后，向所有分支发送
rollback指令 - 注意：MySQL 需开启
innodb_support_xa=ON（8.0.23+ 默认启用），PostgreSQL 需支持PREPARE TRANSACTION
BASE 模式（如 Seata）下的注意事项
若用 Seata + ShardingSphere，需额外保证：
- Seata AT 模式要求每个分片表有
undo_log表，并与对应数据源绑定 - 全局事务 ID（XID）需通过线程上下文透传到所有分片操作中（ShardingSphere 自动集成，但需确认版本兼容性）
-
throw的异常不能被中间 catch 吞掉，否则 Seata 不感知失败，不会发起全局回滚
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
