速率限制

按凭据 + 会员档位限流

panshi.io 不按 IP 限流（避免共享 NAT 连带惩罚），而是按 (凭据, 会员档位) 组合分桶。

当前档位

桶	窗口	上限	说明
global_ip	10s	60	未登录 / 匿名访问的总体护栏
global_user	60s	200	登录用户的全局上限
tier_api_free	60s	60	Free 档 API 速率
tier_api_pro	60s	600	Pro 档 API 速率（10×）
tier_api_vip	60s	1200	Max 档 API 速率（20×）
order_user	10s	10	下单专用桶（防 webhook / 脚本洪水）
login	60s	5	登录尝试
ai_user_day	24h	10	AI 生成调用（另有月配额见下）

AI 月配额

独立于上表，按会员档位：

档位	AI 月配额
Free	0-3
Pro	10
Max (VIP)	30

引流期新用户 Max 90 天，月配额 30。

超限响应

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 17

{"error":"rate_limited","retry_after_sec":17}

客户端 务必读 Retry-After（秒）退避，不要硬循环重试。

幂等豁免

带 Idempotency-Key header 的重复请求（命中缓存）不计入 限流窗口，只对第一次计数。TTL 24 小时，任意唯一字符串。

WebSocket

• 单连接同时订阅频道数 ≤ 50
• 每秒消息数受速率约束
• 异常刷 ping / sub / unsub 洪水会被服务端断开
• 断开后客户端应指数退避重连

Binance-compatible /fapi/*

/fapi/* 走签名鉴权（不走 tier_api_* 桶），有自己的限流：

• weight 表与 Binance 官方一致
• panshi 内部还有一层 token bucket 保护下游 Binance
• 超限响应 schema 同上

常见 pitfalls

• Free 档想接高频策略 → 升级 Pro / Max，或合并 alert 批量下单
• TV webhook 触发过密 → 单 webhook_token 的频率要克制；如需高频开多个 token 分流
• 轮询代替订阅 → 用 WebSocket 可大幅降 QPS
• 重连风暴 → WS 断开必须指数退避
• 忽略 Retry-After → 硬重试会进入惩罚窗口，越撞越久

反馈

档位不够用？app.panshi.io/feedback 或 GitHub Issue 说明场景 + 预期 QPS。