GraphQL 成本控制：灵活查询也要有防火墙

GraphQL 成本控制：灵活查询也要有防火墙

一、GraphQL 的自由度会带来成本风险

GraphQL 很适合全栈产品快速迭代。前端可以按需查询字段，减少接口来回沟通。但它的自由度也会带来风险：深层嵌套、批量字段、复杂过滤和恶意查询都可能把后端打穿。GraphQL 不是天然安全的查询语言，它需要成本控制。

如果只做鉴权，不做查询复杂度限制，用户虽然只能查自己的数据，却可能用合法权限发起非常重的查询。灵活查询要配防火墙，否则线上问题会来得很赛博，也很现实。

GraphQL 的成本问题有一个隐蔽面：它不按请求数算成本，而是按查询形状算成本。同一个接口端点，A 请求查 3 个字段，B 请求查 30 个字段再连 5 层关系，两个请求的资源消耗可以差 100 倍。传统 REST 可按 endpoint 加限流，但 GraphQL 的单个 endpoint 承载了所有查询，限流粒度必须在 AST 解析之后、按查询复杂度来判断。这不是锦上添花，是门槛。

线上见过不止一次这种事故：一个带多层嵌套关联的合法查询，跑了近两分钟没结束，数据库 CPU 被打满，其他用户的正常请求全部超时。排查到最后发现不是攻击，是某个同事为了"一个页面展示所有数据"写了个深度八层的关系查询。API 能拒绝恶意查询重要，能拒绝善意的笨查询更重要。复杂度防火墙必须上线前置，不能等事故发生后再补。

二、请求链路：解析后先估算成本

flowchart TD A[GraphQL 请求] --> B[解析 AST] B --> C[深度检查] C --> D[复杂度估算] D --> E[权限校验] E --> F[Resolver 执行] D --> G[拒绝高成本查询]

成本控制通常包括最大深度、最大字段数、复杂度分数、分页上限和超时。深度限制能防止无限嵌套，复杂度分数能区分普通字段和重字段。比如user.name成本低，user.transactions(first: 1000)成本高。

分页是底线。任何列表字段都不应允许无限返回。默认 limit 和最大 limit 要写死在服务端，不能只靠前端传参。GraphQL 的优雅不应该换来数据库全表扫描。

三、配置示例：给字段设置成本权重

下面是一份概念配置。不同 GraphQL 框架写法不同，但思想一致。

graphql_limits: max_depth: 6 max_complexity: 1000 default_page_size: 20 max_page_size: 100 field_costs: user: 1 transactions: 20 nftHoldings: 30

复杂度估算不是为了精确到 CPU 毫秒，而是为了挡住明显危险的查询。高成本字段可以要求分页、缓存或后台任务。低频重查询不一定要拒绝，也可以异步生成结果。

还要处理 N+1 问题。GraphQL resolver 很容易一层层查数据库，最终同一个请求触发大量 SQL。DataLoader 批处理和缓存是必备工具。成本控制和 resolver 优化要一起做。

四、可观测性：按 operationName 统计

线上监控要按 operationName 统计 QPS、延迟、错误率和复杂度分数。没有 operationName 的请求可以拒绝或降级，因为它很难排查。前端团队也应该给每个查询命名。

GraphQL 错误不要把内部 SQL 或堆栈直接返回给用户。错误格式可以保留 code 和 requestId，详细日志留在服务端。API 灵活，不代表错误信息可以裸奔。

最后，持久化查询适合生产环境。前端提前注册允许的查询，线上只传查询 ID。这样能大幅降低任意查询风险。对开放 API 可以保留动态查询，但要更严格限流。

缓存也要按查询维度设计。GraphQL 字段组合灵活，缓存粒度如果太粗会浪费，太细又会难管理。对于用户资料、资产列表和配置数据，可以在 resolver 层缓存；对于高度个性化和权限敏感结果，缓存 key 必须包含用户和权限范围。别为了性能把别人的数据缓存给当前用户。

Schema 变更要兼容。前端和后端同时快速迭代时，字段废弃应先标记 deprecated，再观察调用量，最后移除。GraphQL 给了演进能力，不代表可以随手删字段。

五、总结

GraphQL 的灵活性必须配成本控制。最大深度、复杂度分数、分页上限、DataLoader、operationName 监控和持久化查询，都是生产级 GraphQL API 的防火墙。自由查询之前，先让系统有边界。