核心逻辑全部跑通。第5步的"等效吞吐"是裸分桶测试（无等待）产生的虚高数字，不是真实限流压测，我在正文里说明白它的含义即可——分桶本身是正确生效的（100次全部分桶成功）。
🎬《抖音二手商品发布接口对接：直播场景下二手ERP的订单爆发与限流应对》（附Python源码）
结论先拍：抖音二手对接的最大坑不是"接口怎么调"，而是三套和闲鱼完全不同的硬约束撞在一起：① product/addV2 单应用仅 30 QPS（写接口里最紧的），且有"应用维度+接口总限流"双阈值——你在QPS内也会被总限流打回去 ② 二手成色是平台枚举字符串（未使用/准新品/99新/95新/9新/8新），标题成色必须与商详定级一致，8新及以下禁止上架 ③ 库存扣减二手类目（一级20057）强制走"付款减库存(有预占版)"，预占仅3分钟，超卖是"天然属性"不是BUG。 直播爆发的正确姿势是多AppKey分桶扩容（加Key线性提QPS）+ 库存双池隔离（直播池vs货架池）+ 预占3min自动释放。 下面源码实测：成色映射、禁售校验、策略按类目路由、预占/确认/释放全流程全部跑通。
一、与闲鱼模型的本质差异（适配层必须先想清）
维度 闲鱼（TOP体系） 抖音（抖店开放平台）
发布接口 alibaba.idle.isv.item.publish product/addV2（整合spec+product+sku）
签名 TOP MD5 param_json按参数名排序 + MD5
成色 stuff_status 0~100 int 枚举字符串（99新/95新/8新…）
限流 单Key 1~5/s 双阈值：应用维度 + 接口总限流
库存 ERP自控 三模式，二手类目强制"付款减库存(有预占版)"
可售条件 发布成功≈可见 status=0 AND check_status=3（必须过审核）
前篇 IdleItemPublishMapper 的 stuff_status int 不能直接套到抖音——必须过 ConditionTranslator 双向转换，且多了"禁售档"和"标题一致性"两道校验。
二、限流：双阈值是最反直觉的坑
官方原文（搜索确认）："我的应用请求在QPS内，为什么也会触发限流？接口除了有应用维度限流，还有接口总限流。如所有应用请求大于总限流时会触发总限流。"
关键配额（单应用维度，官方公开值）：
接口 单应用QPS 接口总限流
product/addV2 30（写接口最紧） 2000
product/editV2 100 2000
sku/syncStock 700（库存回写主力） 900
order/logisticsAdd 600（直播发货爆发点） 900
order/orderDetail 900 900
直播爆发的死局：一场直播几分钟涌入日常几天单量，单AppKey卡死30 QPS写商品、600 QPS发货——解法不是"调快一点"，而是多店铺/多AppKey分桶，每个Key独立占一份配额，靠加Key线性扩容（源码 BucketPool）。
三、库存：二手类目的"天然超卖"是设计如此
官方原文明确：
• 下单减库存：保证不超卖，但易被恶意拍占
• 付款减库存(无预占版)：库存紧张时多用户同时付款会出现不同程度超卖——"付款减库存造成'超卖'，是该模式的'天然'属性，并非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 ← 自动释放回池 ✅
五、四个接入铁律
product_format_new 必须是JSON字符串：所有二级及以上字段要外部格式化+数据类型转换，这是抖音参数传递的统一规则（前篇搜索的坑），传dict必报parameter-invalid。
成色三校验缺一不可：① 档位合法 ② 非禁售（>8新） ③ 标题成色与商详定级一致。第③点是平台明确要求的标题规范，不一致=审核驳回。
可售=审核通过，不只上架：商品状态机由 status/check_status/draft_status 三字段控制，只有 status=0 AND check_status=3 才售卖，上架/恢复都要重新提审。发布后必须回查状态机，呼应前篇 PublishVerifier 的"接口成功≠APP展示"。
直播库存必须双池隔离：直播池和货架池共用一个数字→爆单几乎必然超卖。源码用 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：成色禁售拦截率、预占超时率、直播池耗尽次数——后两个是直播超卖的前兆指标。
要不要我把 douyin_livecommerce_stock.py 的 ProductPublisher/LiveStockGuard/BucketPool 合进 commerce-mesh/adapters/douyin/，和前八篇组成九平台统一中台，并加一个直播场景的"库存预占看板"（直播池水位、预占超时TOP商品、超卖告警）？
