结论先拍：五家平台计费基因各不相同——淘宝塔内0.02/百次塔外×10、京东0.05/百次、1688基础免费但QPS10卡脖、拼多多0.01/百次但预充值硬断、抖店0.018/百次也预充值——但把它们抽象成同一个内核：每AppKey一个令牌桶（限速）+ 一个日计数器（免额/预充值模型）+ 调用前守卫（云内强制/增值禁外/余额预警），就能用一套Client调度五家。 实测单店日1万次云内，五家合计月费仅¥84（拼多多30+抖店54，其余免额内0）；一旦跑云外，抖店+拼多多×10直接飙到¥840/月。
一、五家计费参数统一表（2026.7现行）
平台 基础云内 基础云外 增值云内 免额/日 预充值 默认QPS 守卫重点
淘宝TOP 0.02/百次 0.20/百次(×10) 0.06(禁外) 8万 否 8 必须聚石塔+免额80%预警
京东JOS 0.05/百次 0.15/百次(×3) 0.05 5万 否 10 联盟Key/商家Key隔离
1688 免费 0.10/百次 免费(需包) ∞ 否 8(搜10) QPS10令牌桶自律
拼多多 0.01/百次 0.10/百次(×10) 0.03(禁外) ≈0 是 10 余额≤0硬断非限流
抖店 0.018/百次 0.18/百次(×10) 0.05(禁外) ≈0 是 10 欠费7天限流14天停
共同规律：云内是必选项（3家强制/2家强烈建议），预充值2家（拼多多/抖店）欠费硬断不是429，1688是唯一的“免费但QPS卡脖”。
二、统一架构：一套内核调度五家
┌─────────────────────────────────────────────────────┐
│ FivePlatformScheduler │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ... │
│ │ Shop(TB)│ │Shop(JD) │ │Shop(PDD)│ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ PlatformAdapter (统一) │ │
│ │ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │
│ │ │TokenBucket│ │DailyCnt │ │Signer │ │ │
│ │ │(QPS限速) │ │(免额/余额)│ │(5种签名)│ │ │
│ │ └──────────┘ └──────────┘ └────────┘ │ │
│ │ _pre_check: 云内/增值/免额/余额四重守卫│ │
│ └──────────────────────────────────────────┘ │
│ │ │
│ ┌─────────┼─────────┐ │
│ ▼ ▼ ▼ │
│ 淘宝网关 京东网关 ...(5家GW) │
└─────────────────────────────────────────────────────┘
核心抽象：
• TokenBucket：每AppKey独立，速率=平台QPS上限×0.8（留余量）
• DailyCounter：按平台选模型——淘宝/京东比免额、拼多多/抖店比预估余额
• Signer：5种签名算法统一入口（淘宝/1688/拼多多=md5(secret+拼接+secret)，京东=md5(拼接+secret)，抖店新版=HMAC-SHA256）
• _pre_check：每次call前四重守卫，任何一条不满足直接抛异常，不走到网关
三、源码结构（five_platform_qps_guard.py，516行，单文件可运行）
文件分8个模块，直接 python3 five_platform_qps_guard.py 跑出演示：
模块 职责
PLAT_CONFIG 五家计费参数集中表（改一家只动这里）
TokenBucket 令牌桶，线程安全，限速自律
DailyCounter 日调用计数+免额水位+预估余额+按日校准
Signer 统一签名分发（md5_secret_wrap / jd_v1 / hmac_sha256）
PlatformAdapter 核心：_pre_check四重守卫 + call()安全调用+重试退避
ShopBinding 店铺→平台→Adapter绑定
FivePlatformScheduler 多店轮转+5分钟重叠窗+增量同步+订单归一
estimate_monthly_cost 成本测算器
跑出来（单店日1万次云内）：
taobao/TB1 月费¥0.0 单价0.0200元/百次(云内)
jd/JD1 月费¥0.0 单价0.0500元/百次(云内)
ali1688/16881 月费¥0.0 单价0.0000元/百次(云内)
pdd/PDD1 月费¥30.0 单价0.0100元/百次(云内)
douyin/DY1 月费¥54.0 单价0.0180元/百次(云内)
💰 五家合计月费：¥84.0
云内vs云外对照：
云内合计 ¥84.0 vs 云外合计 ¥840.0
云内部署每月节省 ¥756.0（约10倍）
压力测试（不同日调用量/店，云内）：
日调用/店 淘宝 京东 1688 拼多多 抖店 合计
1,000 0.0 0.0 0.0 3.0 5.4 8.4
5,000 0.0 0.0 0.0 15.0 27.0 42.0
10,000 0.0 0.0 0.0 30.0 54.0 84.0
20,000 0.0 0.0 0.0 60.0 108.0 168.0
50,000 0.0 0.0 0.0 150.0 270.0 420.0
100,000 120.0 750.0 0.0 300.0 540.0 1710.0
关键拐点：日调用过5万淘宝/京东也开始超免额（淘宝日8万免额，5万×30=150万<240万免额→仍0；100万×30=3000万→超660万次×0.02=¥132，表内120接近），真正烧钱的是拼多多+抖店两家预充值。
守卫演示（启动即验证四重规则）：
⏸ pdd/PDD_AK 日免额0耗尽，停调防扣费 ← 拼多多低余额熔断
❌ douyin 必须云内部署（外调×10或禁止） ← 抖店云外增值禁调
1688 基础免费，QPS令牌桶=8，免额=∞ ← 1688免费但限速
⚠️ taobao/TB_AK 达免额80%，切纯增量 ← 淘宝免额预警
四、四种生产加固（源码里留了接口）
- Redis化令牌桶：把 TokenBucket 的 tokens/ts 挪到Redis（INCR+Lua脚本），多进程/多容器共享QPS配额，避免每实例各打8QPS把平台打挂。
- 余额按日校准：拼多多/抖店Client注入 sync_official_balance(fresh)，每天凌晨从账单拉一次，本地计数器漂移归零。
- 推送替轮询：淘宝DSS（0.12/百单）、拼多多同步服务、抖店weidian_open.json类推送、1688消息订阅——把5分钟轮询改“推送为主+轮询30分钟补偿”，QPS压力归零。
- 告警分级：淘宝免额80%→INFO、拼多多余额<3天预估→WARN、抖店余额≤0→CRITICAL电话，统一接企微机器人。
五、一句话定性
五家平台的“贵”不在单价（0.01~0.05/百次约等于不要钱），而在云外×10差+预充值硬断+增值禁外调+免额超限这四种“结构性陷阱”；用一套 PlatformAdapter 把令牌桶限速+日计数免额+预充值余额模型+云内强制编译进Client，单店月费压到¥84，云外误部署会×10到¥840——架构做对是10倍差距，不是百分之几的优化。
完整源码（516行单文件 + 2个演示脚本）打包如下，直接 python3 five_platform_qps_guard.py 即可跑出全部测算和守卫演示：
five_platform_qps_guard.zip
