graphql-request 7.x版本对4xx状态码响应处理的变更分析

在graphql-request库从6.x升级到7.x版本后，开发者需要注意一个重要变更：库对HTTP 4xx状态码响应的处理方式发生了改变。这一变更可能会影响到那些依赖非200状态码返回GraphQL错误信息的应用。

背景知识

GraphQL规范本身并不强制要求使用特定的HTTP状态码。虽然大多数实现会使用200状态码返回GraphQL响应，但有些服务端实现会使用4xx状态码（如422）来表示特定的业务错误，同时仍然在响应体中包含完整的GraphQL错误信息。

版本差异

在6.x版本中，graphql-request会解析所有HTTP响应的内容，无论状态码是什么。这意味着即使服务端返回4xx状态码，只要响应体包含有效的GraphQL响应，客户端仍然能够获取到其中的错误信息。

然而在7.x版本中，库新增了对response.ok的检查。如果HTTP状态码不是2xx，库会直接抛出错误而不会尝试解析响应体。这一变更导致开发者无法获取到服务端返回的GraphQL错误信息。

影响范围

这一变更主要影响以下场景：

1. 使用422等4xx状态码返回业务错误的GraphQL服务
2. 依赖response.errors处理业务逻辑的客户端代码
3. 需要向后兼容旧版本服务端的应用

解决方案

对于需要保持6.x行为的应用，目前有以下几种解决方案：

1. 升级到graffle库：graphql-request的维护者推荐迁移到graffle库，该库是graphql-request的下一代版本，可能已经解决了这个问题。

2. 自定义fetch适配器：可以通过覆写fetch方法强制将response.ok设为true，使库继续解析响应体：

const client = new GraphQLClient(url, {
  fetch: async (...args) =>
    Object.defineProperty(await fetch(...args), 'ok', { value: true }),
});

3. 降级到6.x版本：如果短期内无法修改代码，可以考虑暂时停留在6.x版本。

最佳实践

对于长期维护的项目，建议：

1. 与服务端团队协商统一的错误处理规范
2. 考虑迁移到graffle库
3. 在客户端实现健壮的错误处理逻辑，兼容不同状态码情况

这一变更反映了GraphQL生态对HTTP状态码使用的标准化趋势，开发者需要根据自身业务需求选择合适的应对策略。