🎬《抖音二手商品发布接口对接：直播场景下二手ERP的订单爆发与限流应对》（附Python源码）

一、与闲鱼模型的本质差异（适配层必须先想清）

前篇 IdleItemPublishMapper 的 stuff_status int 不能直接套到抖音——必须过 ConditionTranslator 双向转换，且多了"禁售档"和"标题一致性"两道校验。

二、限流：双阈值是最反直觉的坑

三、库存：二手类目的"天然超卖"是设计如此

• 下单减库存：保证不超卖，但易被恶意拍占

• 付款减库存(无预占版)：库存紧张时多用户同时付款会出现不同程度超卖——"付款减库存造成'超卖'，是该模式的'天然'属性，并非BUG，是符合预期的"

• 付款减库存(有预占版)：提交订单后预占库存，预占时效(3 min)内支付成功则扣减，超时/取消则释放；超过时效继续支付会重新预占（失败则返回售罄）

• 系统识别规则：一级类目20057 二手、20023 珠宝、20021 古董、20110 特色手工艺、20004 茶、20080 时尚饰品 —— 无论商家配置何种扣减类型，最终都执行"支付减库存(有预占版)"

所以二手ERP的正确姿势：下单先预占、付款再确认、超时必释放——LiveStockGuard 把这个三态做成显式状态机，源码实测：预占30件→确认20件→清理10件过期预占→直播池回到50。

四、源码运行实证

【1】限流配额
   product/addV2            应用  30 QPS  总限2000
   sku/syncStock            应用 700 QPS  总限900
   order/logisticsAdd       应用 600 QPS  总限900

【2】成色枚举 ↔ 统一模型
   int= 99 → 99新  (禁售=False)
   int= 85 → 8新   (禁售=True)    ← 禁售档识别正确
   int= -1 → 未使用 (禁售=False)
   int= 70 → 8新   (禁售=True)

【3】库存扣减策略（按一级类目路由）
   类目20057(二手): 付款减库存(有预占版)  ← 强制
   类目20023(珠宝): 付款减库存(有预占版)  ← 强制
   类目10001(其他): 付款减库存(无预占版)

【4】商品发布校验
   99新 iPhone13              → ✅
   8新 禁售                   → ❌ 成色8新属于禁售档
   99新 乐高(标题写95新)      → ❌ 标题成色与商详定级不一致

【7】直播库存守卫（预占版，类目20057）
   预占30件后: 直播池=20 (预留给付款)
   确认20件 + 清理10件过期预占后: 直播池=50  ← 自动释放回池 ✅

五、四个接入铁律

1. product_format_new 必须是JSON字符串：所有二级及以上字段要外部格式化+数据类型转换，这是抖音参数传递的统一规则（前篇搜索的坑），传dict必报parameter-invalid。

2. 成色三校验缺一不可：① 档位合法 ② 非禁售（>8新） ③ 标题成色与商详定级一致。第③点是平台明确要求的标题规范，不一致=审核驳回。

3. 可售=审核通过，不只上架：商品状态机由 status/check_status/draft_status 三字段控制，只有 status=0 AND check_status=3 才售卖，上架/恢复都要重新提审。发布后必须回查状态机，呼应前篇 PublishVerifier 的"接口成功≠APP展示"。

4. 直播库存必须双池隔离：直播池和货架池共用一个数字→爆单几乎必然超卖。源码用 live_pool/shelf_pool 分离，直播结束再把未售库存归集回主池。

六、和前几篇的衔接

把本篇三个组件装进既有体系：

• BucketPool（多Key分桶） 替代/增强前篇 RateLimiter——抖店场景的限流是应用维度+总限流双阈值，单令牌桶不够，必须按Key分桶；sku_hint 哈希绑定保证同SKU永远落同Key，避免库存双写错乱；

• ConditionTranslator + PublishValidator 作为 ProductPublisher 的前置校验，与前篇 IdleItemPublishMapper 共用统一 Product 实体的 condition_int/condition_text，三平台（闲鱼int / 淘宝 / 抖音枚举）成色在 master_sku 主数据层汇合；

• LiveStockGuard（预占3min） 接入前篇 StockEngine——抖店侧的扣减走"预占→确认/释放"，回写用 sku/syncStock（700 QPS，主力通道），注意它的限流比 addV2 宽松得多，库存回写不必像发布那样紧张；

• call() 的限流重试 复用前篇 WriteRetryQueue（指数退避+死信），"总限流"触发的失败必须可重试，否则直播峰值丢单；

• 状态机回查喂 ObservabilityMiddleware：成色禁售拦截率、预占超时率、直播池耗尽次数——后两个是直播超卖的前兆指标。