Apollo Client 中跳过查询缓存问题的分析与解决方案

问题背景

在使用 Apollo Client 进行 GraphQL 查询时，开发者经常会遇到一个典型场景：根据条件跳过查询（skip query）。一个常见用例是根据用户是否登录（是否存在 token）来决定是否获取用户数据。然而，当配合 Apollo Client 的缓存清理机制使用时，这种模式可能会产生意料之外的行为。

核心问题表现

具体表现为：当用户登出时，应用会清除 Apollo Client 的缓存（通过 clearStore 方法），但在后续的跳过查询中，即使查询被跳过，返回的 data 仍然包含之前缓存的旧数据，而不是预期的 undefined。这会导致用户数据更新不及时的问题，特别是当不同用户使用同一设备登录时。

技术原理分析

造成这种现象的根本原因在于 Apollo Client 的查询生命周期管理机制：

1. 查询跳过时的行为：当使用 skip: true 时，查询不仅会跳过网络请求，还会跳过所有缓存更新通知。这意味着即使缓存被清除，被跳过的查询也不会收到相关通知。

2. 组件生命周期的影响：如果包含查询的组件在整个过程中保持挂载状态（没有卸载），那么当查询从跳过状态恢复时，它会继续使用上次查询的结果作为初始状态，然后等待新的缓存更新。

3. 缓存清理的局限性：clearStore 方法确实会清空缓存，但这种清理操作不会自动反映到当前被跳过的查询上，因为被跳过的查询已经切断了与缓存更新的连接。

解决方案

1. 组件强制重新挂载

最可靠的解决方案是确保在用户登出/登录状态变更时，强制重新挂载包含查询的组件。这可以通过以下方式实现：

// 在应用的根组件或适当层级添加key属性
const App = () => {
  const [appKey, setAppKey] = useState(0);
  
  const handleLogout = async () => {
    // ...其他登出逻辑
    await apolloClient.clearStore();
    setAppKey(prev => prev + 1); // 强制重新挂载
  };

  return <MainComponent key={appKey} />;
};

这种方法不仅解决了 Apollo 查询的缓存问题，还能确保所有组件状态都被重置，避免残留任何前用户会话的状态。

2. 手动重置查询状态

作为替代方案，可以在登出时手动重置查询状态：

const { data, refetch, client } = useUserGetCurrentQuery({
  skip: !token,
});

const logout = async () => {
  // 重置特定查询
  client.writeQuery({
    query: UserGetCurrentDocument,
    data: null,
  });
  // ...其他登出逻辑
};

不过这种方法需要更精细的状态管理，且不如组件重新挂载方案彻底。

最佳实践建议

1. 状态变更时的完整重置：对于身份认证状态变更这类关键操作，建议总是采用完整的组件树重置策略。

2. 合理划分组件边界：将与用户会话相关的组件隔离在独立的子树中，便于在认证状态变更时只重置必要的部分。

3. 避免长期挂载的全局查询：对于全局性的用户数据查询，考虑将其放在适当层级的组件中，而不是最顶层的组件。

4. 开发环境下的严格检查：在开发过程中，特别注意跨用户会话的状态残留问题，这往往是安全性和数据隔离的重要隐患。

总结

Apollo Client 的缓存机制虽然强大，但在与条件查询配合使用时需要特别注意其生命周期行为。通过理解查询跳过时的内部机制，我们可以采用组件强制重新挂载等策略确保应用状态的纯净性。这种方案不仅解决了眼前的问题，也为应用的状态管理提供了更健壮的基础。