非受检异常配合位掩码实现精准事务回滚与补偿：Spring默认仅对RuntimeException回滚，避免配置遗漏；位掩码标记各步骤执行状态，失败时封装failedMask抛出BusinessRollbackException，回滚时依据stepMask & ~failedMask精准补偿已成功操作。
非受检异常（RuntimeException 及其子类）本身不参与 Java 编译期检查，Spring 默认仅对其触发事务回滚；位掩码则是一种轻量、可组合的整型状态标记方式，常用于多条件原子性控制。二者结合，并非直接“用位掩码抛异常”，而是通过**用位掩码精准标识失败环节 + 抛出非受检异常驱动整体事务回滚**，从而在高并发商品操作（如秒杀下单、库存+优惠券+积分联动扣减）中实现“全成功或全撤销”的强一致性。
为什么选非受检异常而非检查异常
Spring 声明式事务默认只对 RuntimeException 和 Error 自动回滚。若用 IOException 或自定义 CheckedException，必须显式配置 @Transactional(rollbackFor = Exception.class)，否则事务静默提交——这在高并发链路中极易埋下数据不一致隐患。使用非受检异常可省去重复配置，降低出错概率，也更符合“业务异常即系统异常”的语义。
位掩码用于标记原子操作阶段状态
在复杂商品操作中（例如：校验库存 → 扣减库存 → 冻结优惠券 → 扣减用户积分 → 创建订单），每个步骤可分配一个唯一 bit 位：
- 0x01 → 库存校验与扣减
- 0x02 → 优惠券冻结
- 0x04 → 积分扣减
- 0x08 → 订单创建
执行过程中维护一个 int stepMask = 0，每成功一步就执行 stepMask |= 0x01 等操作。若某步失败（如优惠券已过期），不立即抛异常，而是先记录失败位（如 failedMask |= 0x02），再统一抛出自定义非受检异常（如 BusinessRollbackException），并将 failedMask 封装进异常对象中。
回滚逻辑依赖位掩码做精准逆向补偿
虽然数据库事务能自动回滚已执行的 DML，但某些场景需额外补偿（如已发MQ通知、已调用外部积分服务）。此时可在 @ExceptionHandler 或 AOP 切面中捕获该异常，读取 failedMask，反向判断哪些步骤**实际已成功落地**（即 stepMask & ~failedMask 中为 1 的位），仅对这些成功步骤执行补偿清理：
- 若
stepMask == 0x03（库存+优惠券成功），但failedMask == 0x04（积分失败），说明前两步已写库，需调用积分服务“释放已扣积分”并解冻优惠券； - 若
stepMask == 0，说明卡在第一步，无需任何补偿，纯数据库回滚即可。
这样避免了“全量补偿”带来的性能开销和幂等风险，也规避了因补偿顺序错误导致的新不一致。
高并发下的关键保障点
位掩码本身是线程安全的整型运算，无锁、无竞争，适合高频更新；配合非受检异常，整个流程不依赖 try-catch 吞异常，确保 Spring 事务拦截器能捕获到原始异常并触发回滚。注意两点：
- 所有数据库操作必须在同一个
@Transactional方法内完成（或传播至同一事务上下文），否则位掩码有效但事务无法跨方法回滚； - 若涉及分布式调用（如远程扣积分），需将该调用放在事务最后，并确保其具备幂等性与可逆性，或改用 TCC/Saga 模式，位掩码在此作为协调状态参考。
