位掩码算法用于高并发下单时精准回滚已扣减规格：下单前用位掩码声明操作意图，执行中逐个原子扣减并记录已执行位图，失败时通过位运算快速定位需回滚的规格并反向恢复库存。
电商多规格库存（如颜色+尺码组合）在高并发下单时，容易因部分规格扣减失败导致状态不一致——比如“黑色-L”库存扣成功，“白色-M”却因超卖或DB异常失败，此时必须精准回滚已扣减的规格，不能影响其他正常库存。捕获异常 + 位掩码算法，不是用来替代事务，而是为“失败后精准撤回”提供轻量、高效、无锁的标记与定位能力。
用位掩码预标规格操作意图
在下单开始前，不直接操作库存，而是将本次请求涉及的所有规格组合映射为唯一 bit 位。例如：
- SKU1001-黑色-L → bit 0（值 1）
- SKU1001-黑色-M → bit 1（值 2）
- SKU1001-白色-L → bit 2（值 4）
- SKU1001-白色-M → bit 3（值 8）
用户选择“黑色-L ×1 + 白色-M ×2”，则生成操作掩码：1 | 8 = 9（二进制 1001）。该掩码存入本地上下文或临时 Redis key（带过期），作为本次操作的“指纹”。它不改变库存，只声明“我要动哪几个规格”，为后续失败回滚提供可追溯依据。
分步扣减 + 异常捕获驱动条件回滚
按顺序对每个规格执行原子扣减（推荐 Redis Lua 脚本），每成功一步，更新一个“已执行位图”（bitmask）：
- 先扣“黑色-L”：Lua 检查并 DECRBY，成功则设置 bit 0 → 当前已执行掩码 = 1
- 再扣“白色-M”：同理，成功则置 bit 3 → 已执行掩码 = 1 | 8 = 9
- 若中途某步失败（如 DB 写入报错、Redis 连接中断），立即进入 catch 块
此时已执行掩码为 1，原始意图掩码为 9。只需计算：已执行掩码 & ~原始意图掩码？不，实际是反向操作：用“已执行掩码”和“原始意图掩码”做交集，就能知道哪些位是真正完成的；再逐位解析，反向 INCR 对应规格的 Redis 库存即可。无需查库、无需遍历数组，O(1) 定位要回滚的规格集合。
位运算加速失败路径清理
假设原始意图掩码是 mask_intent = 15（1111），执行到第 3 步失败，已执行掩码 mask_done = 7（0111）。那么需回滚的规格就是 bit 0、1、2 对应的三个 SKU 变体。
PHP 中可这样快速提取：
$toRollback = $mask_done & $mask_intent; // 确保只取交集内有效位
for ($i = 0; $i < 32; $i++) {
if ($toRollback & (1 << $i)) {
$skuVariant = getVariantByBit($i); // 根据 bit 位查出对应规格ID
$redis->incr("stock:{$skuVariant}");
}
}
整个过程不依赖数据库事务跨表回滚，也不需要维护额外的状态表，位运算本身极快，配合 Redis 原子命令，回滚延迟控制在毫秒级。
避免掩码冲突与扩容限制
单个整型字段最多支持 32 或 64 个规格变体，对绝大多数商品足够（服装类常见 ≤ 20 种组合）。若遇超大规格商品（如定制化配置项达百级），可改用 Redis 的 Bitmap 数据结构（如 SETBIT），用商品 ID 作 key，规格索引作 offset，同样支持 O(1) 位操作与批量扫描。关键仍是：**先用掩码声明意图，再按序执行并记录进度，失败时靠位运算反推已变更项，实现最小粒度原子回滚**。
