Apollo Client缓存未随查询变量更新：Next.js用户页查询异常

你遇到的缓存串扰，本质是Apollo内存缓存的keyArgs配置错误导致的。
Apollo默认会把查询传入的、影响结果的变量作为缓存条目的索引维度——比如传入的userId不同，就会匹配到独立的缓存位置。但你在给分页查询写自定义合并逻辑时，给posts和userPosts都设置了keyArgs: []，这相当于明确告诉Apollo：不管这个查询传入什么参数，所有结果都写入同一个全局缓存槽，不对变量做区分。
这就直接连锁引发了所有异常现象：

• 当你从用户A的个人页切到用户B的个人页时，虽然请求里传的userId已经变成了B的id，但Apollo会跳过变量匹配，直接把之前存在同一个缓存槽里的A的帖子返回，根本不会触发新的网络请求
• 用户信息查询之所以能正常更新，是因为你没给这个查询配置自定义typePolicy，走了Apollo默认的缓存规则，会把用户id作为缓存索引的一部分，所以不会出现串扰
• 你之前尝试加fetch-policy: no-cache时，因为完全跳过了缓存读写流程，所以点赞这类操作把结果写回缓存时，当前查询读不到更新后的状态，自然看不到实时的点赞反馈。

修正keyArgs配置 #

留空的keyArgs是所有问题的核心，需要把所有会影响查询返回结果的变量列进去，让Apollo能按变量维度区分不同的缓存条目：

• 对于首页的全局动态流posts，把分页相关的变量（比如limit、分页光标cursor）纳入keyArgs，保证首页的分页缓存不会和其他页面的缓存混淆
• 对于用户页的userPosts，必须把userId、分页相关变量纳入keyArgs，让不同用户的帖子存在独立的缓存空间

修正后的Apollo客户端配置参考：

cache: new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        posts: {
          // 替换成你实际使用的分页变量名，不要留空数组
          keyArgs: ['limit', 'cursor'],
          merge(existing: PaginatedPosts | undefined, incoming: PaginatedPosts): PaginatedPosts {
            return {
              ...incoming,
              posts: [...(existing?.posts || []), ...incoming.posts],
            };
          },
        },
        userPosts: {
          // 这里必须加上userId，才能区分不同用户的帖子缓存
          keyArgs: ['userId', 'limit', 'cursor'],
          merge(existing: PaginatedPosts | undefined, incoming: PaginatedPosts): PaginatedPosts {
            return {
              ...incoming,
              posts: [...(existing?.posts || []), ...incoming.posts],
            };
          },
        },
      },
    },
  },
})

配置后的实际效果 #

调整完keyArgs之后，你完全不需要给查询强制设置无缓存策略：

• 不同用户的帖子会存在独立缓存槽，切换用户页面时Apollo会自动匹配对应userId的缓存，不会串用上一个用户的内容
• 缓存流程正常保留的情况下，点赞等变更操作更新缓存后，页面会自动拿到最新的帖子状态，不需要手动刷新
• 因为你用了Next.js做服务端渲染，服务端每次处理请求都会生成独立的临时Apollo实例，客户端水合时才会把服务端拉取的缓存同步到浏览器，天然不会出现跨用户请求的缓存泄漏问题，不需要额外做缓存清理操作。

内容的提问来源于stack exchange，提问作者Vasilis Voyiadjis