GraphQL 限流按成本算：一个重查询就能把你打满
桶容量与恢复速率按查询成本计算，嵌套层级和连接数量直接决定你能跑多快。
发生了什么#
Shopify 的 GraphQL 管理 API 用「计算成本」的方式限流：每个查询会先估算成本，从桶里扣减，桶按时间恢复。查询里嵌套的连接（connections）越多、请求的字段越多，成本越高。这与 REST 的「每秒请求数」完全不同，很多团队迁移后第一次遇到限流就是在这里。
关键细节#
- 限流基于查询成本，不是请求数量
- 嵌套连接与字段数量会显著抬高成本
- 桶容量与恢复速率随套餐与 API 类型不同
- 响应里会返回当前成本与剩余额度，可用于自适应限流
- Bulk Operations 适合大批量场景，不占用实时配额
对商家与开发者的影响#
最常见的错误是「一个查询拿全量数据」：为了少发请求，把订单、行项目、客户、配送全塞进一个查询，结果单次成本超标，反而更慢。
正确做法是分层查询 + 缓存：列表页只取必要字段，详情页再补。同时对返回的限流信息做自适应退避。
建议动作#
- 在客户端读取限流返回头，动态调整并发
- 列表查询限制连接数量，避免一次拉几千条
- 大批量导出改用 Bulk Operations
原文与编译说明
- 原文标题
- GraphQL rate limits and query cost
- 发布来源
- Shopify 开发者文档
- 发布时间
- 2025-04-01
本文为中文编译摘要，包含站方补充的背景与影响分析，不是原文的逐字翻译。版权归原作者与发布方所有。若原文后续更新或信息有误，以官方页面为准；发现错误可发邮件到 admin@fgwljs.com 指出。
新闻栏目由 风格技术 技术团队维护，每个工作日筛选 Shopify 官方渠道与行业媒体的更新。功能是否可用，以店铺后台实际显示与官方文档为准。
