Apollo v3.3 客户端缓存更新意外触发服务端请求及UI不重渲染排查

自动触发额外整表请求的触发逻辑 #

• 初始拉取列表时配置的cache-and-network策略是核心诱因：该策略设计为“只要对应订阅者感知到缓存变动，就会自动发起后台网络同步”，本身并非纯本地读取的策略。
• 缓存匹配规则不匹配放大了问题：Apollo 3.3.7版本采用精确匹配规则识别缓存条目，只要readQuery、writeQuery时传入的变量，和组件当初订阅列表查询时传入的变量存在哪怕细微差异（比如键顺序不同、数字/字符串类型不匹配、JSON解析带来的序列化偏差），就会被判定为“缓存缺失”，从而自动按照初始的cache-and-network策略发起整表拉取请求。
• 缓存写入时机的已知bug：如果将缓存更新逻辑放在客户端自定义resolver中执行，不会自动触发缓存变动的订阅通知，组件感知不到本地写入的更新，就会自动走默认的网络拉取流程补数据。

本地缓存更新后UI不渲染的原因 #

• 归一化缓存字段丢失：写入列表数据时，map更新的product节点如果没有保留完整的__typename、id等归一化主键字段，Apollo缓存不会识别到实体的实际变动，绑定对应数据的组件自然不会触发重渲染。
• 订阅通知未触发：3.3.7版本存在已知问题——直接在resolver中执行cache.writeQuery操作时，不会主动向所有缓存订阅者广播最新的缓存值，就会出现“缓存值确实变了，但UI没收到更新通知”的情况。

可落地的修复步骤 #

• 统一所有查询使用的变量对象：放弃在写入逻辑中临时对变量做JSON.parse转换的写法，保证readQuery、writeQuery、组件useQuery时使用的变量是同一结构、同一类型、同一键顺序的对象，避免被判定为不同的缓存条目。
• 调整查询的拉取策略配置：在列表页的useQuery调用中补充nextFetchPolicy参数，将首次加载完成后的后续读取策略改为纯本地缓存读取，从根源上掐掉自动网络请求的触发逻辑，配置示例：

const { data } = useQuery(GET_PAGING_PRODUCT, {
  variables: fixedPagingVariables,
  fetchPolicy: 'cache-and-network', // 保留首次加载的后台同步能力
  nextFetchPolicy: 'cache-first' // 首次加载完成后，所有后续变动读取都只走本地缓存
})

• 修正缓存写入的结构完整性：在更新单个product的inventory字段时，完整展开原有对象的所有字段，显式补全__typename，保证缓存归一化逻辑正常工作：

products: getListProduct.products.map((product) => {
  if (product.id === productId) {
    return {
      ...product,
      inventory,
      __typename: product.__typename
    };
  }
  return product;
})

• 手动触发缓存广播：在cache.writeQuery执行完成后，主动调用一次cache.broadcastWatches()，强制将最新的缓存值推送给所有绑定该查询的组件，解决3.3.7版本广播时机延迟导致的UI不更新问题。
• 调整缓存更新逻辑的挂载位置：尽量将本地缓存更新逻辑放在对应Mutation的update回调中执行，而非客户端自定义resolver中——Mutation的update回调会自动触发缓存广播，不会出现通知遗漏的问题。

补充说明：你当前的实现中，将缓存更新逻辑封装在名为updateInventoryCache的客户端resolver中，本身就和Apollo的默认执行时机不匹配，这是触发额外请求、UI不更新的高发场景。

内容的提问来源于stack exchange，提问作者Steve doe