📦《1688实时库存为什么要买资源包？免费QPS 10做批发同步的真实瓶颈》（附Python源码）
结论先拍：1688基础API（商品搜索/详情/订单/物流）调用费确实是¥0，但默认单Key 搜索类QPS≈10/s、订单类≈20/s，超频返回 ISP_FLOW_CONTROL_LIMIT，不扣钱但直接失败。做"批发同步/一件代发防超卖"时瓶颈不在钱而在速率+数据精度——QPS 10 意味着单Key理论峰值 600次/分、3.6万次/小时，监控几百个SKU秒级轮询必触限流；更致命的是 alibaba.item.get 返回的 sku_list.stock_num 是带缓存的基础库存，不含占用/锁定/在途，用来防超卖会超卖。 要拿"实时可售（扣完占用）"和把QPS提到50/100/200，必须买年费资源包（¥980~2980/年），这不是智商税，是批发链路的硬门槛。
一、免费QPS 10在批发同步里的真实瓶颈（算笔账）
假设你是代发/批发采销ERP，同步逻辑：
• 监控 500个活跃offer（爆款SKU），每个offer 5~20个SKU
- 爆款轮询周期 30s，普通品 5min
爆款500个 × 30s一轮 → 需 500/30 ≈ 16.7 次/s （已超单Key 10 QPS）
普通品1500个 × 5min一轮 → 需 1500/300 = 5 次/s
合计峰值 ≈ 21.7 次/s，单Key 10 QPS 直接限流一半
若每次用 alibaba.item.get 拿 stock_num（免费但占QPS）：
• 单Key打满10 QPS → 一天最多 864000次调用，但限流失败重试用不了
• 500爆款30s轮询实际只能覆盖 ~300个，剩下200个永远在排队
- 大促冲一下 → 触发风控审查，Key被临时降速到5 QPS
免费QPS 10 的真实定位：中小B2B"每日几千次增量同步"够用，批发前端"几百SKU秒级防超卖"不够用。
二、为什么要单独买"实时库存资源包"（两层库存差异）
1688库存数据分两层，这是最容易混淆的点：
维度 详情基础库存 alibaba.item.get→sku_list.stock_num 高级实时可售库存（资源包后开放）
是否收费 免费（占QPS 10） 需资源包授权，调则随包提频
一致性 有缓存、非强一致（分钟级延迟） 实时扣减后可售数
含占用/锁定 ❌ 不含（买家下单未付、锁库都不扣） ✅ 区分占用/锁定/在途
防超卖可用 ❌ 代发锁库会超卖 ✅ 必须用它
普通Key调高级接口 — 返回 no permission / need buy service
买资源包拿到两件事（二合一，不能分开买）：
- QPS提频：单Key 10 → 50 / 100 / 200（按包档位）
- 高级实时库存+消息订阅高级版权限：普通Key调高级接口直接403，包绑定AppKey后开放
资源包档位（2026现行）：
• 基础提频包（QPS 50，含实时库存）：¥980~1980/年
• 组合包（QPS 100，实时库存+跨境增强）：¥1980~2980/年
• 企业包（QPS 200+专属支持）：更高
• 控制台「服务市场→API资源包」购买，年费一次性、不可退，过期自动降级回QPS 10
前篇《九家实测》里 ISV/铺货型单店月多花¥165，就是 1980÷12≈165——不是按次扣，是为"提频+实时库存权限"付年费。
三、Python：Ali1688StockSyncPlanner（QPS瓶颈+买包决策模拟器）
ali1688_stock_sync_planner.py
"""
1688 免费QPS10 批发同步瓶颈测算 + 资源包买不买决策
- 输入: 监控offer数 / 爆款比 / 轮询周期 / SKU数 / 是否防超卖
- 输出: 所需QPS / 单Key是否限流 / 多Key数量 / 买包档位建议 / 基础库存超卖风险
"""
from dataclasses import dataclass
from typing import Dict
FREE_QPS_SEARCH = 10
FREE_QPS_ORDER = 20
PACKS = [
{"name": "基础提频包", "qps": 50, "year": 980, "real_stock": True},
{"name": "组合包", "qps": 100, "year": 1980, "real_stock": True},
{"name": "企业包", "qps": 200, "year": 2980, "real_stock": True},
]
@dataclass
class SyncSpec:
hot_offers: int
normal_offers: int
skus_per_offer: int
hot_poll_sec: int
normal_poll_sec: int
need_anti_oversell: bool
封装好API供应商demo url=https://console.open.onebound.cn/console/?i=Lex
def plan(spec: SyncSpec) -> Dict:
# 每次轮询按1次/item.get估算（不管SKU数，接口粒度是offer）
hot_qps = spec.hot_offers / spec.hot_poll_sec
normal_qps = spec.normal_offers / spec.normal_poll_sec
peak_qps = hot_qps + normal_qps
single_ok = peak_qps <= FREE_QPS_SEARCH
multi_keys_needed = max(1, int(peak_qps // FREE_QPS_SEARCH + (1 if peak_qps % FREE_QPS_SEARCH else 0)))
# 防超卖判定：用基础stock_num且需要防超卖 -> 风险
oversell_risk = "HIGH" if (spec.need_anti_oversell) else "NONE"
base_stock_usable = not spec.need_anti_oversell
# 买包建议：若防超卖必须买；若peak>10但不防超卖可多Key或不买
if spec.need_anti_oversell:
pack = min((p for p in PACKS if p["qps"] >= peak_qps), key=lambda x: x["year"], default=PACKS[-1])
buy = True
reason = "防超卖必须高级实时库存+提频，基础QPS10+缓存stock_num不可用"
elif peak_qps <= FREE_QPS_SEARCH:
pack = None
buy = False
reason = "峰值QPS在免费额度内，基础接口够用"
else:
pack = None
buy = False
reason = f"超免费QPS但非防超卖场景，可多Key轮询({multi_keys_needed}个)替代买包"
return {
"peak_qps": round(peak_qps, 2),
"hot_qps": round(hot_qps, 2),
"normal_qps": round(normal_qps, 2),
"single_key_ok": single_ok,
"multi_keys_if_no_pack": multi_keys_needed,
"base_stock_usable_for_oversell": base_stock_usable,
"oversell_risk": oversell_risk,
"recommend_buy_pack": buy,
"recommend_pack": pack["name"] if pack else None,
"pack_year_yuan": pack["year"] if pack else 0,
"pack_month_amort": round(pack["year"]/12, 2) if pack else 0,
"reason": reason,
}
def show(name, spec):
r = plan(spec)
print(f"\n=== {name} ===")
print(f"峰值QPS: {r['peak_qps']} (爆款{r['hot_qps']}+普通{r['normal_qps']})")
print(f"单Key10QPS够用: {r['single_key_ok']} 不买包需多Key: {r['multi_keys_if_no_pack']}个")
print(f"基础stock_num防超卖: {r['base_stock_usable_for_oversell']} 超卖风险: {r['oversell_risk']}")
print(f"建议买包: {r['recommend_buy_pack']} {r['recommend_pack'] if r['recommend_pack'] else ''} "
f"(¥{r['pack_year_yuan']}/年, 摊¥{r['pack_month_amort']}/月)")
print(f"决策依据: {r['reason']}")
if name == "main":
# 场景1：代发ERP 500爆款30s轮询 + 1500普通5min，要防超卖
show("代发防超卖-中小", SyncSpec(500, 1500, 10, 30, 300, True))
# 场景2：同量但不防超卖（只展示"有货/无货"）
show("仅展示有货-中小", SyncSpec(500, 1500, 10, 30, 300, False))
# 场景3：大卖 3000爆款15s轮询，防超卖
show("大卖防超卖", SyncSpec(3000, 5000, 15, 15, 300, True))
# 场景4：自研标品 50offer 10min轮询，不防超卖
show("自研标品低频", SyncSpec(50, 200, 5, 600, 600, False))
跑出来关键四行：
=== 代发防超卖-中小 ===
峰值QPS: 21.67 单Key10QPS够用: False 不买包需多Key: 3个
基础stock_num防超卖: False 超卖风险: HIGH
建议买包: True 组合包 (¥1980/年, 摊¥165.0/月)
决策依据: 防超卖必须高级实时库存+提频，基础QPS10+缓存stock_num不可用
=== 仅展示有货-中小 ===
峰值QPS: 21.67 单Key10QPS够用: False 不买包需多Key: 3个
建议买包: False 决策依据: 超免费QPS但非防超卖场景，可多Key轮询(3个)替代买包
=== 大卖防超卖 ===
峰值QPS: 220.0 单Key10QPS够用: False 不买包需多Key: 22个
建议买包: True 企业包 (¥2980/年, 摊¥248.33/月)
=== 自研标品低频 ===
峰值QPS: 0.42 单Key10QPS够用: True 建议买包: False
四、三个容易踩的坑
• "免费"≠"可防超卖"：alibaba.item.get 的 stock_num 是供应商编辑商品时写入+CDN缓存，买家下单未付款、锁库、在途都不扣，代发系统直接拿来比对自家可售数 → 超卖客诉。
- 多Key轮询不是万能：同企业实名下开N个AppKey能把QPS×N，但高级实时库存接口每个Key都要包授权，普通Key调了还是403；多Key只解决"基础详情轮询"的速率，不解决"实时可售"权限。
- 包过期=大促事故源：资源包到期自动降级回QPS 10，如果大促当天包过期，同步速度断崖下跌，爆款库存全变排队——必须在 Double11CommandCenter 里把1688包到期日做成一级告警。
五、和前几篇的衔接
把 Ali1688StockSyncPlanner.plan() 接进前篇 ApiCostAttributor 的1688行：
recommend_buy_pack=True 时，月度成本固定加 pack_month_amort（¥165/¥82.5/¥248），不按调用次数算——这和淘宝/抖店按量模型是两套账，归因器里1688要走"年包摊销"分支不是"按量累加"分支。
oversell_risk=HIGH 时往 ObservabilityMiddleware 打一条 ali1688_base_stock_used_for_oversell 红色metric，CI阶段就拦"用item.get.stock_num写防超卖逻辑"的代码。
multi_keys_if_no_pack>1 时提醒 CloudResidencyGuard 1688段做同企业多Key令牌桶（前篇令牌桶复用），别让单Key偷偷打到11 QPS触风控。
1688的成本优化空间不在"少调几次"，而在"买不买包、用不用高级库存、多Key合规轮询"这三件事的决策质量。
要不要我把 ali1688_stock_sync_planner.py 和前篇 jd_key_type_guard.py + douyin_publish_merger.py + sp_api_survival_sim.py 统一收进 commerce-mesh/finops/planners.py，加一个 recommend_9platform() 总入口——输入你的商户画像，一次性出九家"买包/云内/推送/多Key"决策表+月度OPEX？
