B站库存接口在更新模式上提供了一个明确的选择：mode=1为增量更新，mode=2为全量更新，默认值为1。增量模式下，zp_entity_stock_offset传入正数表示增加库存，传入负数表示减少库存。这一设计看似简单，但结合电商库存扣减的并发本质，增量语义实际上将可售量计算的最终责任完全转移到了调用方——平台侧只是在当前值基础上做加减，它不关心这个“当前值”是否已经被其他并发请求修改过。

一、增量模式下的竞态条件：为什么“各自读、各自写”会出问题

假设某SKU在B站平台的当前可售库存为100。ERP系统在同一时间窗口内处理了三笔订单，每笔需要扣减1件。如果系统对每一笔订单独立执行“读取当前库存 → 计算增量(-1) → 调用B站库存接口”的流程，三个处理单元可能几乎同时读到“100”这个基准值，然后各自发出一个zp_entity_stock_offset=-1的请求。平台侧依次执行三次减1，最终库存变为97，这个结果在数学上是正确的。但问题在于，如果系统在读取和写入之间还叠加了其他异步操作——例如补货入库的增量请求、其他渠道的库存回写——最终的累加结果就可能偏离预期。更危险的是，当系统试图做“库存不足时阻止扣减”的前置判断时，基于过期快照做出的判断可能让多个请求同时通过校验，而平台侧的累加最终使库存变为负数。

二、ERP侧的串行化：将并发收敛为顺序

解决这一问题的核心原则是：对同一SKU的B站库存写操作，在ERP系统内部实现串行化。具体手段可以是在应用层使用分布式锁（如基于Redis的Redisson或基于数据库的行锁），锁的粒度精确到sku_id。当某个SKU的库存更新请求到达时，先获取该SKU的锁，然后执行“获取最新快照 → 计算增量 → 调用接口 → 释放锁”的完整流程。后到达的请求在锁上等待，获取锁后读取到的是前一笔操作完成后的最新值，从而避免了基于同一份过期快照做出决策。

串行化会带来一定的响应延迟，但对于库存写操作而言，宁可牺牲几十毫秒的吞吐，也不能接受一笔错误的扣减。如果业务场景对延迟极度敏感（如秒杀开抢瞬间），可以在锁之外叠加一层“短窗口聚合”机制：将500毫秒内到达的同一SKU的多笔扣减请求合并为一次增量调用，增量值为这些请求的总和。聚合既减少了锁竞争的频率，也降低了接口调用次数，是一种在串行化与吞吐之间取得平衡的工程手段。

三、增量与全量的边界：全量模式何时才是安全的

mode=2的全量更新并非在所有场景下都不可用。它的适用场景应当严格限定在“系统能够确认当前不存在尚未完成的并发写操作”的时刻。例如，每日凌晨低峰期的定时对账任务，在暂停该SKU所有增量写入的前提下，读取B站平台当前库存并与ERP中央库存比对，发现差异后以全量模式将B站库存强制设置为目标值。全量更新的风险在于它会“抹掉”任何未被感知的中间状态——如果平台侧存在其他来源的库存变动（例如B站后台的人工调整），全量覆盖会将这些变动一并清除。因此，全量模式的使用应当有明确的操作日志和审批记录，而不是作为日常同步的默认手段。

四、平台缓存延迟对增量计算的影响

需要额外考虑的一个因素是平台侧的数据生效延迟。多数电商平台的库存接口在写入成功后，前端展示和后续查询可能存在数十秒到数分钟的缓存生效窗口。这意味着，ERP系统在调用增量接口后立即回查，可能读到的是旧值，而不是刚刚写入的结果。如果系统依赖“写入后立即回查”来验证增量操作是否成功，就会陷入误判。合理的做法是：增量调用成功即视为业务完成，回查验证应当放在对账任务中异步执行，且对账的时间窗口应设置在缓存生效延迟之后（例如写入完成5分钟后再进行比对）。将“调用成功”与“数据可见”解耦，是应对平台缓存特性的基本设计原则。