调用history.replace时Apollo GraphQL useQuery触发重拉问题咨询

Apollo Client 默认不会监听history对象的任何变更，不会因为history状态变化主动触发查询重拉。你遇到的全量重拉问题，本质是history.replace触发React Router上下文更新后，挂载useQuery的组件发生意外重渲染/重挂载，触发了Apollo的查询执行逻辑。

触发原因 #

useQuery默认在以下场景会执行查询：

• 组件首次挂载时，若对应查询无可用缓存则发起请求
• 组件重渲染时，若传入useQuery的variables或配置项引用发生变化，即使值完全一致，也会判定参数变更触发重拉
• 组件发生重挂载（非普通重渲染）时，默认会重新执行查询，和缓存状态无关

结合你的实现，问题基本出在两个点：

• 你直接将从location.state读取的值作为内联变量传给useQuery，每次路由上下文更新触发组件重渲染时，内联对象/变量会生成新的引用，被Apollo判定为参数变更
• 路由写法存在问题，history.replace触发路由状态更新后，子页面组件被意外卸载重挂，导致所有useQuery跟着重新执行

修复方案 #

按排查优先级从高到低操作：

1. 固定useQuery入参的引用 #

不要在组件渲染阶段直接写内联的variables、配置对象，用useMemo包裹查询变量，固定不变的配置项直接提到组件作用域外，避免每次渲染生成新引用。

错误写法示例：

// 每次渲染都会生成新的variables、配置对象引用
const { data } = useQuery(GET_LIST_DATA, {
  variables: {
    selectedFilter: history.location.state?.filterVal
  },
  fetchPolicy: 'cache-and-network'
})

正确写法示例：

// 只有筛选值实际变化时，才会生成新的变量引用
const queryVariables = useMemo(() => ({
  selectedFilter: history.location.state?.filterVal
}), [history.location.state?.filterVal])

// 固定配置提到组件外，不会随渲染变化
const listQueryOptions = {
  fetchPolicy: 'cache-and-network'
}

const { data } = useQuery(GET_LIST_DATA, {
  ...listQueryOptions,
  variables: queryVariables
})

2. 调整fetchPolicy匹配业务场景 #

如果筛选参数无变化时不需要实时拉取服务端数据，给对应useQuery设置fetchPolicy: 'cache-first'即可，该策略下Apollo会优先读取本地缓存，只有缓存无对应数据时才会发起网络请求。
如果需要首次加载拿最新数据、后续操作优先读缓存，可以搭配设置nextFetchPolicy: 'cache-first'。

3. 排查组件意外重挂载问题 #

如果前两步操作后仍然触发全量重拉，检查路由配置：

• 不要在路由定义处写内联的组件渲染函数，否则每次路由状态更新，React都会判定为新组件触发重挂载
• 检查组件树上层是否有用location.key、location.pathname作为子树key的逻辑，这类写法会在路由状态变化时直接卸载重挂整个子树，导致所有子组件的useQuery重新执行

4. 优化状态持久化逻辑 #

如果不需要把筛选状态同步到浏览器历史栈，可以改用sessionStorage存储筛选条件，从根源上避免频繁调用history.replace触发的路由上下文更新；如果必须存在history.state中，可以给自定义持久化钩子加300ms左右的防抖，等用户完成筛选操作后再更新history状态，减少不必要的重渲染。

内容的提问来源于stack exchange，提问作者Charlie Stanard