GraphQL把大量查询集中在一个HTTP端点，例如/graphql。传统反向代理只看URL，很难判断这次请求是轻量字段查询，还是会触发多个数据库和下游API的复杂操作。于是会出现同一URL有时20毫秒、有时20秒，而缓存和限流策略又无法简单按路径设置。
GraphQL与普通REST代理的差异
| 项目 | GraphQL特点 | 代理影响 |
|---|---|---|
| URL | 大量操作共用一个端点 | 路径级缓存和限流粒度不足 |
| 方法 | 常用POST，也可能使用GET | POST默认缓存行为有限 |
| 响应 | 可同时包含data与errors | HTTP状态不足以判断业务成功 |
| 复杂度 | 由查询结构与字段决定 | 代理通常不了解解析成本 |
为什么HTTP 200仍有错误
GraphQL执行可能得到部分数据并返回errors数组。代理只统计2xx会低估故障。应用监控应记录操作名、错误类别和下游耗时，同时避免记录完整查询变量中的个人信息和Token。
POST响应能不能缓存
技术上可以由应用和代理明确设计，但不能简单以URL为缓存键。查询文本、变量、用户身份、权限、Locale和租户都会影响响应。错误缓存可能把一个用户的数据返回给另一个用户。更安全的做法是使用受控的持久化查询、明确可缓存操作和完整缓存键。
持久化查询有什么价值
客户端发送操作哈希，服务端从允许列表找到查询，可减少请求体并提高审计能力。它不是自动性能优化：变量、身份和Resolver仍决定成本。版本发布还需要保证查询登记与客户端兼容。
Batch为什么可能放大风险
多个操作放在一个HTTP请求中，可以减少握手和Header开销，也可能绕过按请求次数限流、产生超大响应或让一个失败触发整批重试。网关和服务端应限制批量操作数量、总复杂度、请求体与执行时间。
请求体限制该设置多大
代理、WAF和应用都可能限制请求体。复杂查询、变量或文件上传会触发413。应以业务最大合法请求为基础设置，并对文件上传使用明确规范或独立上传流程。无限提高限制会增加解析和内存风险。
超时应该放在哪一层
客户端、CDN、代理、GraphQL Server、Resolver和下游服务都要有截止时间。服务端应把剩余时间向下游传递，避免外层已504，内部查询仍继续消耗资源。Nginx超时分层见Nginx 504与读取超时排查。
DataLoader能解决所有慢查询吗
DataLoader可在单请求内批处理和缓存，缓解N+1问题，但键设计、请求级生命周期和后端批量接口仍需正确。跨用户或跨请求共享缓存可能造成数据泄露。应通过Resolver Trace验证实际调用次数。
Mutation超时为何不能盲目重试
代理返回504时，Mutation可能已提交数据库。客户端和网关不应默认重放。使用幂等键、稳定操作ID和状态查询，服务端记录业务结果，才能安全恢复。
WebSocket订阅又是一条链路
GraphQL Subscription可能基于WebSocket或SSE，使用长连接、心跳和不同认证刷新机制。HTTP Query正常不代表订阅稳定。应协调代理升级、空闲超时、连接上限与断线恢复。
观测应记录什么
- Operation Name和持久化查询ID；
- 解析、验证、Resolver和下游耗时；
- GraphQL errors分类与HTTP状态；
- 查询复杂度、深度和返回大小；
- 缓存命中与Batch大小；
- 请求ID、用户匿名标识和租户。
排查顺序
- 按Operation而非URL拆分性能；
- 解析响应体中的errors；
- 定位慢Resolver与N+1；
- 检查代理体积、缓冲和超时；
- 审查缓存键、Batch和复杂度限制；
- 验证Mutation幂等；
- 单独测试订阅长连接。
结论
GraphQL代理优化的关键是让网关与观测理解“操作”，而不是只看到统一URL。缓存、限流、超时和重试都应结合查询语义，才能避免性能优化演变成越权或重复写入。
