本文深入探讨了在 apollo 客户端中，如何通过配置 `fetchpolicy` 来有效管理数据缓存行为，解决重复查询仍触发网络请求的问题。我们将重点介绍 `network-only` 结合 `nextfetchpolicy: 'cache-first'` 的策略，以实现首次加载从网络获取最新数据，后续相同查询优先从缓存读取，同时在后台静默更新缓存，确保数据最终一致性，提升用户体验和应用性能。
在构建现代 Web 应用程序时，数据管理和性能优化是关键。Apollo Client 作为一个强大的 GraphQL 客户端，提供了开箱即用的缓存机制，旨在减少不必要的网络请求。然而，开发者有时会遇到这样的情况：即使是完全相同的查询，Apollo 似乎也未能如预期地从缓存中读取数据，而是重复向服务器发起请求。这不仅增加了服务器负载，也可能导致用户体验下降。本文将详细解析这一问题，并提供基于 fetchPolicy 的专业解决方案。
理解 Apollo 的缓存行为
Apollo Client 的默认 fetchPolicy 是 cache-first，这意味着它会首先检查本地缓存。如果缓存中存在所需数据，则直接返回；否则，才发起网络请求。这种策略在多数情况下表现良好，但在某些特定场景下，如需要确保首次加载最新数据，或在短时间内频繁切换相同查询变量时，可能会出现与预期不符的行为。
例如，在一个日历应用中，用户可能频繁地在不同周之间切换。当用户从“本周”切换到“下周”，再切换回“本周”时，如果“本周”的数据在缓存中已经存在，我们期望 Apollo 能够直接从缓存中读取，而不是再次发起网络请求。然而，如果配置不当，即使是完全相同的查询（包括变量），也可能导致重复的网络请求。
对于手动操作缓存的需求，Apollo 提供了 client.readQuery 和 client.writeQuery 等 API。这些方法允许开发者直接读取或写入缓存中的数据。然而，对于自动化的查询缓存行为，特别是针对 useQuery 钩子，fetchPolicy 才是更核心的控制机制，通常无需手动干预 readQuery 或 writeQuery。
使用 fetchPolicy 控制缓存行为
fetchPolicy 是 useQuery 钩子中的一个重要选项，它决定了 Apollo Client 如何处理数据请求和缓存。理解并合理配置 fetchPolicy 是优化应用性能的关键。
常用的 fetchPolicy 值包括：
- cache-first (默认)：首先检查缓存。如果缓存中有数据，则返回缓存数据。否则，发起网络请求。
- network-only：始终跳过缓存，直接发起网络请求。请求完成后，会将数据写入缓存。
- cache-only：只从缓存中读取数据，不发起网络请求。如果缓存中没有数据，则返回错误。
- cache-and-network：同时返回缓存数据（如果存在）和发起网络请求。当网络请求完成后，缓存会被更新，组件也会重新渲染。
- no-cache：不读取也不写入缓存，始终发起网络请求。
- standby：查询不会自动执行，除非通过 client.refetchQueries 或 client.reFetch 手动触发。
结合 network-only 和 cache-first 实现智能缓存更新
针对本文开头描述的日历应用场景，我们期望首次加载时获取最新数据，后续切换回相同查询时能优先从缓存读取，但同时也要确保数据最终能够得到更新。这时，可以巧妙地结合 network-only 和 nextFetchPolicy 选项。
nextFetchPolicy 允许我们为查询的后续执行指定不同的 fetchPolicy。
import { useQuery, gql } from '@apollo/client';
const MY_QUERY = gql`
query GetWeeklyData($startDate: String!, $endDate: String!) {
weeklyData(startDate: $startDate, endDate: $endDate) {
id
title
date
// ... 其他字段
}
}
`;
function WeeklyCalendar({ startDate, endDate }) {
const { loading, error, data, refetch } = useQuery(MY_QUERY, {
variables: { startDate, endDate },
fetchPolicy: 'network-only', // 首次执行时，强制从网络获取最新数据
nextFetchPolicy: 'cache-first', // 后续执行时，优先从缓存读取
// pollInterval: 2000 // 如果需要定期刷新数据，可以设置此项
});
if (loading) return 加载中...
;
if (error) return 错误: {error.message}
;
return (
周视图数据
{data.weeklyData.map(item => (
- {item.title} - {item.date}
))}
);
}
工作原理分析：
- 首次加载 (fetchPolicy: 'network-only')：当组件首次挂载或 startDate/endDate 变量发生变化时（被视为新的查询），useQuery 会强制发起网络请求，确保用户看到的是最新的数据。请求完成后，数据会被写入 Apollo 缓存。
-
后续相同查询 (nextFetchPolicy: 'cache-first')：当用户切换到其他周，然后又切换回之前已经查询过的“本周”（即 startDate/endDate 变量与之前完全相同），useQuery 会遵循 nextFetchPolicy 的指示。此时，它会首先检查缓存。
- 如果缓存中存在该查询的完整数据，Apollo 会立即从缓存中返回数据，组件迅速渲染，提供即时响应。
- 同时，Apollo 仍会在后台静默地发起一次网络请求，以检查服务器是否有更新。如果服务器返回了新数据，缓存会被更新，组件也会随之重新渲染，从而确保数据最终的一致性。
这种策略完美解决了“首次加载最新数据”和“后续查询优先缓存，同时保持数据新鲜度”的需求。它在性能和数据准确性之间找到了一个极佳的平衡点。
注意事项与最佳实践
-
数据新鲜度与延迟更新：上述 cache-first 策略会在后台进行网络请求以更新缓存。如果你的应用需要更严格的“1-2秒后强制刷新”机制，可以考虑以下方法：
- pollInterval：在 useQuery 选项中设置 pollInterval: 2000（2000毫秒即2秒）。这将使 Apollo 每隔指定时间自动重新发起网络请求来更新数据。但请注意，这会增加网络请求频率，可能不适用于所有场景。
-
refetch 结合 setTimeout：在组件加载新数据后，使用 setTimeout 延迟调用 refetch() 方法。
useEffect(() => { const timer = setTimeout(() => { refetch(); // 延迟2秒后强制刷新数据 }, 2000); return () => clearTimeout(timer); // 清理定时器 }, [startDate, endDate, refetch]);这种方法提供了更精细的控制，但需要手动管理副作用。
变量一致性：Apollo Client 的缓存是基于查询字符串和变量的组合。确保当你想从缓存中读取数据时，查询的 GraphQL 文档和变量都与之前写入缓存的完全一致。任何微小的差异都可能导致 Apollo 认为这是一个新的查询，从而发起网络请求。
-
其他 fetchPolicy 场景：
- 如果某个查询的数据几乎不变化，或者对实时性要求不高，可以使用 cache-only 策略来完全避免网络请求。
- 对于需要同时显示旧数据（来自缓存）和加载新数据（来自网络）以提供最佳用户体验的场景，cache-and-network 是一个很好的选择。
总结
Apollo Client 的 fetchPolicy 是一个强大而灵活的工具，用于精细控制数据请求和缓存行为。通过合理配置 fetchPolicy，特别是利用 network-only 结合 nextFetchPolicy: 'cache-first' 的策略，我们能够有效解决重复查询导致的网络请求问题，同时确保数据的新鲜度和最终一致性。这不仅能显著提升应用的性能和响应速度，也能为用户带来更流畅、更愉悦的体验。理解这些策略并将其融入日常开发实践，将是构建高性能 Apollo 应用的关键。
