这种多标签页下的API挂起问题，我之前在类似的GraphQL项目里碰到过，结合你的技术栈（React + Apollo Client v3.6.8 / Go + graphql-go v0.7.9），咱们一步步拆解排查：

一、核心排查方向 #

1. 浏览器并发连接限制与HTTP协议特性 #

浏览器对同一域名的HTTP/1.1并发连接数有默认限制（Chrome一般是6个），如果你的Dashboard API发起了多个请求，加上keep-alive连接被长期占用，就可能导致新请求排队挂起。当关闭一个标签页时，释放了连接，排队的请求就能被处理。

• 验证方式：打开Chrome DevTools的Network面板，查看挂起请求的「Timing」标签，看是否处于「Stalled」状态（等待可用连接）。

2. 认证会话的并发冲突 #

因为项目有认证API，多标签页共享同一用户的会话（比如Cookie、LocalStorage），如果后端会话实现存在并发限制，就会导致请求被串行阻塞：

• 比如Go后端的Session用了互斥锁，同一用户的多个请求会被强制排队；
• 或者Token刷新机制有问题：一个标签页在刷新Token时，其他标签页的请求因旧Token失效被挂起，直到新Token生成。

3. Apollo Client的缓存与请求竞态 #

Apollo Client的默认缓存机制可能引发竞态问题：

• 多个标签页同时发起相同Query，缓存锁导致请求等待；
• FetchPolicy配置不合理（比如用了cache-first），动态数据未触发网络请求，表现为挂起；
• 跨标签页的缓存同步失效，导致某个标签页的请求等待缓存更新。

4. Go后端GraphQL的并发处理瓶颈 #

• GraphQL Resolver中存在阻塞操作（比如同步数据库查询、未使用连接池），导致请求堆积；
• graphql-go/handler的配置限制了并发请求数；
• 后端goroutine被挂起（比如死锁、IO阻塞），未及时处理请求。

二、针对性解决方案 #

1. 优化HTTP连接配置 #

• 切换到HTTP/2：HTTP/2支持多路复用，彻底解决并发连接数限制。确保Go后端开启HTTP/2（Go 1.6+默认支持），Apollo Client的createHttpLink会自动协商HTTP/2协议；
• 合并GraphQL请求：使用apollo-link-batch将多个Query合并成一个请求，减少连接占用；
• 调整Apollo Client请求选项：确保fetchOptions: { credentials: 'include' }正确配置，避免因Cookie传递问题导致请求异常。

2. 修复认证会话机制 #

• 优化后端Session实现：如果用了基于内存的Session，换成Redis等分布式存储，避免全局互斥锁；确保Session操作是无锁或细粒度锁；
• 改进Token刷新逻辑：
  • 前端用LocalStorage设置「刷新中」标记，多个标签页共享该标记，避免同时发起Token刷新请求；
  • 后端支持并发Token刷新请求，同一用户的多个刷新请求返回相同的新Token，避免请求阻塞。

3. 调整Apollo Client缓存策略 #

• 修改FetchPolicy：对于Dashboard的动态数据，使用fetchPolicy: 'network-only'或cache-and-network，强制触发网络请求；
• 配置全局默认选项：

  const client = new ApolloClient({
    uri: '/graphql',
    cache: new InMemoryCache(),
    defaultOptions: {
      watchQuery: { fetchPolicy: 'cache-and-network' },
      query: { fetchPolicy: 'network-only' },
    },
  });
  

• 跨标签页缓存同步：自定义监听storage事件，实现多标签页的缓存同步，避免缓存锁导致的请求挂起。

4. 优化Go后端并发处理 #

• 检查数据库连接池：确保sql.DB的MaxOpenConns和MaxIdleConns设置足够大，匹配并发请求量；
• 排查Resolver阻塞：用Go的pprof工具分析goroutine状态，定位是否有死锁、IO阻塞等问题；
• 调整GraphQL Handler配置：确保handler.Options未设置不必要的并发限制，比如：

  h := handler.New(&handler.Options{
    Schema:        schema,
    Playground:    true,
    // 避免设置过小的超时或并发限制
  })
  

5. 网络层面验证 #

• 用DevTools的Network面板追踪挂起请求的完整生命周期，确认是浏览器连接限制还是后端处理延迟；
• 在预发布环境开启Go后端的日志，记录每个请求的接收和响应时间，定位是否有请求被长时间阻塞。

内容的提问来源于stack exchange，提问作者Georgescu Rares Daniel