位掩码替代嵌套循环实现高效库存扣减：用BitSet压缩SKU状态，单层遍历匹配规则，分布式锁保障原子性；按共享维度分桶校验库存，预计算路径字典支持前端实时联动。
嵌套 for 循环本身不适用于高并发、多规格 SKU 的库存联合扣减——它在千万级组合下极易引发指数级计算爆炸，且无法保障原子性与实时一致性。真正可行的路径是：用位掩码（BitMask）压缩状态空间 + 单层遍历驱动规则匹配 + 分布式锁/乐观更新保障扣减安全。下面分三块讲清关键落地逻辑。
位掩码替代笛卡尔积枚举
传统嵌套循环生成 SKU 组合（如颜色×尺寸×版本）在属性维度＞5、每维取值＞10时，组合数轻松破百万，前端渲染卡顿、后端校验超时。改用位掩码可将每个 SKU 映射为一个整数 ID，所有有效 SKU 集合用 BitSet 存储：
- 预定义规格顺序（如：[颜色, 尺寸, 版本] → 索引 [0,1,2]），各维度取值数量记为 [3,4,2]
- SKU “红-M-标准版” → 位置索引 (0,1,0) → 编码为 0×(4×2) + 1×2 + 0 = 2，即 bit#2 置 1
- 全量有效 SKU（库存＞0）用一个 BitSet 表示，查询“选中红+M后哪些版本可用”，只需按位与操作：bitSet & colorRedMask & sizeMMask，毫秒级返回可用版本位图
联合扣减不靠嵌套遍历，靠状态聚合与桶式归并
用户下单含多个 SKU（如购物车含红-S、蓝-M、红-M），需确保整体库存充足且互斥（例如红-S 和红-M 共享“红”色总库存池）。此时不能用 for(i) for(j) 校验每对关系，而应：
- 将 SKU 按共享约束维度分组（如按“颜色”分桶），每桶内只做一次 sum(需扣减量) ≤ 当前桶总库存 的判断
- 扣减动作统一走原子 SQL：UPDATE inventory_pool SET available = available - ? WHERE pool_key = ? AND available >= ?
- 失败则整单回滚；成功则同步更新各 SKU 对应的明细库存（用位掩码定位具体 SKU 记录）
动态禁用与前端联动靠预计算路径字典
用户选择“红”后，要实时禁用所有库存为 0 的尺寸选项。若每次点击都查库+嵌套循环过滤，响应必然延迟。正确做法是：
- 离线预计算“有效路径字典”：对每个规格值组合（如“红”），记录其覆盖的所有位掩码索引集合（即所有红系 SKU 的 bit IDs）
- 运行时仅需查字典 + BitSet.and() 运算，即可快速得出“红”下还有几个尺寸可选，甚至直接返回可选尺寸列表
- 前端通过轻量 JSON（如 {"red": ["S","M"]}）渲染，无需再做任何嵌套判断
不复杂但容易忽略：位掩码不是万能加速器，它依赖规格维度稳定、取值范围可控。若出现用户自定义属性或无限扩展规格（如刻字内容），需降级为 Trie 树+倒排索引混合方案。核心始终是——用空间换确定性，用预计算换实时性，而不是靠循环嵌套硬扛复杂度。
