Apollo Client接入MSW后缓存返回过期空响应的最佳实践

这类缓存返回携带空响应过期值的问题，是 Apollo Client 接入 MSW 做本地开发时的高频共性问题。问题根源来自两种环境的缓存预期错配：正式生产环境下，Apollo 的多层级缓存设计是为了减少重复网络请求、优化交互体验；但在 MSW mock 模式下，开发者会频繁修改 mock 响应、切换 handler 返回值，缓存中暂存的旧空响应/过期数据，会直接拦截掉新配置的 mock 返回结果。

你之前采用的“在每个 hook 调用点加三元判断切换 fetchPolicy”的方案，本质是把环境耦合逻辑散落在所有业务代码里，不仅冗余度高，还很容易因为新增请求时漏写判断再次复现缓存问题，确实有更优雅的实现方式：

方案1：在Apollo Client初始化层全局注入配置 #

完全可以把 fetchPolicy 的判断逻辑上提到 Apollo Client 的全局默认配置里，不需要在每一个 useQuery/useLazyQuery 调用点写分支判断。Apollo Client 本身就支持在实例层级设置全局默认的请求策略，只需要在初始化客户端的入口处判断当前是否开启 mock 模式，一次性配置全量请求的默认策略即可：

// 应用入口的Apollo Client初始化逻辑
const apolloClient = new ApolloClient({
  link: existingRequestLink,
  cache: new InMemoryCache(),
  defaultOptions: {
    watchQuery: {
      fetchPolicy: API_MOCKING ? 'network-only' : 'cache-and-network',
      nextFetchPolicy: API_MOCKING ? 'network-only' : 'cache-first',
    },
    query: {
      fetchPolicy: API_MOCKING ? 'network-only' : 'cache-and-network',
      nextFetchPolicy: API_MOCKING ? 'network-only' : 'cache-first',
    },
  },
});

这种方式下，所有业务代码里的请求调用完全不需要感知当前运行的是不是 mock 模式，配置仅需要维护一份，从根源上避免了散点判断带来的漏改问题。

方案2：联动MSW生命周期自动重置缓存 #

如果不想改动全局的 fetchPolicy 配置，也可以完全对齐 MSW 官方的自动化测试最佳实践，在 MSW 的运行时钩子中自动触发缓存清空，同样不需要改动业务代码。
在 MSW 的 worker/server 配置中，监听 mock 响应返回的事件，只要识别到当前是 mock 开发模式，在每次 mock 请求完成后，直接调用 Apollo 实例的缓存重置方法清空旧缓存：

// msw 浏览器端配置示例
const worker = setupWorker(...allMockHandlers);
worker.events.on('response:mocked', () => {
  // 直接引用全局初始化好的apolloClient实例
  apolloClient.cache.reset();
});

这种方案的优势是适配性更强，哪怕业务代码里临时给单个请求指定了自定义的 fetchPolicy，也不会出现缓存残留的问题，因为每次 mock 请求完成后都会自动清空缓存，和自动化测试场景的逻辑完全统一。

方案3：分层隔离两套环境的客户端配置 #

如果团队对代码解耦要求较高，可以把不同模式下的 Apollo 配置完全拆成独立模块：

• 正式生产环境的客户端配置单独维护，保持原有的缓存策略不变
• mock 开发环境的客户端配置单独维护，内置适配 mock 场景的缓存规则
• 在应用启动入口根据当前环境变量，动态加载对应配置完成客户端初始化，业务代码全程不感知配置差异。

内容的提问来源于stack exchange，提问作者Gus Higuera