Apollo Client 的核心：内存缓存（InMemoryCache）
Apollo Client 内部使用 InMemoryCache 来存储从 GraphQL 服务器获取的数据。这个缓存层是其高效数据管理的基础。当一个查询被执行时，InMemoryCache 会尝试查找是否存在已缓存的数据。如果存在，并且缓存策略允许，它将直接返回这些数据，从而避免了网络往返的开销。
在 index.js 中配置 ApolloClient 时，我们通常会实例化 InMemoryCache 并将其传递给客户端：
import { ApolloClient, InMemoryCache, ApolloProvider } from "@apollo/client";
import { RouterProvider } from "react-router-dom"; // 假设使用了 react-router-dom
const client = new ApolloClient({
uri: process.env.BASE_URL, // GraphQL 服务器地址
cache: new InMemoryCache(), // 实例化内存缓存
});
const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
<React.StrictMode>
<ApolloProvider client={client}>
<RouterProvider router={router} /> {/* 您的路由配置 */}
</ApolloProvider>
</React.StrictMode>
);通过 ApolloProvider 将配置好的 client 传递给 React 组件树，所有子组件都可以通过 useQuery 等钩子访问到这个客户端及其缓存。
深入理解 fetchPolicy 选项
fetchPolicy 是 useQuery 钩子中一个强大的配置选项，它决定了 Apollo Client 如何处理数据请求，即是优先从缓存中读取，还是总是发起网络请求，以及如何更新缓存。合理设置 fetchPolicy 是实现数据持久化和优化性能的关键。
fetchPolicy 提供了多种策略，以适应不同的数据获取需求：
-
cache-first (默认策略)
- 工作原理： Apollo Client 会首先检查其内存缓存。如果所有请求的数据都已存在于缓存中，则直接返回这些数据。否则，它会向 GraphQL 服务器发起网络请求，获取数据后将其缓存，并返回。
- 优点： 优先从缓存获取数据，最大限度地减少网络请求，显著提高应用响应速度，是实现数据持久化的理想选择。当用户在页面之间导航或刷新页面时，如果数据未过期且查询条件未变，应用将直接从缓存加载，提供即时体验。
- 适用场景： 大多数读取操作，尤其是那些数据不经常变化或对实时性要求不高的场景。
-
cache-only
- 工作原理： 只从缓存中读取数据。如果缓存中没有所需数据，则不会发起网络请求，而是返回一个错误。
- 优点： 性能最高，完全避免网络请求。
- 适用场景： 确定数据已经存在于缓存中的情况，例如在用户离线时显示缓存数据，或者在数据已通过其他方式（如订阅或变异）更新到缓存后。
-
cache-and-network
- 工作原理： 立即从缓存中返回数据（如果存在），同时并行地发起网络请求。当网络请求返回时，它会更新缓存并再次返回数据。
- 优点： 提供了最佳的用户体验，用户可以立即看到旧数据，然后无缝地更新为最新数据。
- 适用场景： 对数据实时性有一定要求，但又希望快速显示内容的情况，如社交媒体动态、新闻列表等。
-
network-only
- 工作原理： 总是向 GraphQL 服务器发起网络请求，获取最新数据。获取到的数据会更新到缓存中。
- 优点： 确保获取到最新数据。
- 适用场景： 对数据实时性要求极高，或需要强制刷新数据的情况，如用户提交表单后立即刷新列表。
-
no-cache
- 工作原理： 总是向 GraphQL 服务器发起网络请求，但获取到的数据不会被缓存。
- 优点： 适用于不需要缓存的数据，或敏感数据。
- 适用场景： 临时性数据、一次性数据或不希望被缓存的数据。
-
standby
- 工作原理： 不会自动执行查询。它只在通过 refetch 或 fetchMore 等方法手动触发时才执行。
- 优点： 适用于需要在特定用户操作后才加载数据的情况。
- 适用场景： 懒加载组件、模态框中的数据等。
在 useQuery 中应用 fetchPolicy
为了实现问题中描述的“页面重载时数据持久化，仅在查询变化时发起新请求”的需求，cache-first 是最合适的选择，因为它正是 useQuery 的默认行为。即便如此，明确指定 fetchPolicy 也能增强代码的可读性和意图。
以下是修改后的组件代码示例：
import { useQuery } from "@apollo/client";
import { useSearchParams } from "react-router-dom"; // 如果你的查询变量来自 URL 参数
// 假设 queryGql 是一个定义好的 GraphQL 查询文档
// 假设 queryVariables 是根据组件状态或 URL 参数动态生成的查询变量
const Component = () => {
// 可以根据需要从 useSearchParams 获取变量，例如：
const [searchParams] = useSearchParams();
const someId = searchParams.get('id');
const queryVariables = { id: someId }; // 示例：将 URL 参数作为查询变量
const { loading, error, data } = useQuery(queryGql, {
variables: queryVariables,
fetchPolicy: 'cache-first', // 明确指定缓存优先策略
});
if (loading) {
return <div>加载中...</div>;
}
if (error) {
return <div>错误: {error.message}</div>;
}
const results = data?.data || []; // 假设数据结构是 data.data
return (
<div>
{results.length > 0 ? (
results.map((result) => (
<Card name={result.name} key={result.id} /> // 假设 Card 组件接收 name 和 id
))
) : (
<div>没有找到结果。</div>
)}
</div>
);
};
export default Component;在这个示例中，fetchPolicy: 'cache-first' 明确告诉 Apollo Client，在执行 queryGql 时，首先检查缓存中是否存在与 queryVariables 匹配的数据。如果存在，则直接使用缓存数据；如果不存在（例如首次加载，或 queryVariables 发生变化导致缓存中没有对应数据），则发起网络请求，并将结果存入缓存。
最佳实践与注意事项
- 理解 fetchPolicy 与 variables 的关系： Apollo Client 的缓存是基于查询字符串和变量的。这意味着，即使是相同的查询，如果 variables 不同，Apollo 也会将其视为不同的查询，并可能导致新的网络请求（取决于 fetchPolicy）。这正是实现“仅在查询变化时发起新请求”的关键。
- 选择合适的策略： 大多数情况下，cache-first 是一个很好的默认选择，因为它平衡了性能和数据新鲜度。但对于需要强实时性的数据（如股票价格），可能需要考虑 network-only 或 cache-and-network。
- 缓存更新： 虽然 fetchPolicy 负责数据获取，但有时您可能需要手动更新缓存或强制重新获取数据。useQuery 返回的 refetch 函数可以用于手动触发网络请求，而 useMutation 配合 update 或 refetchQueries 选项则可以在数据变异后更新相关查询的缓存。
- 内存管理： InMemoryCache 会随着时间积累数据。对于大型应用，可能需要考虑更高级的缓存管理策略，例如 typePolicies 来定制缓存行为，或者在特定情况下清理缓存。
总结
通过深入理解并合理配置 Apollo Client 的 fetchPolicy 选项，开发者可以在 React 应用中实现高效的数据持久化和智能的网络请求管理。cache-first 策略作为默认且推荐的选择，能够显著提升用户体验，减少不必要的网络流量。结合 InMemoryCache 的强大能力，Apollo Client 为构建高性能、响应迅速的 GraphQL 应用提供了坚实的基础。掌握这些概念，将使您能够更灵活地应对各种数据管理挑战。
