TanStack Query在Nuxt2与Nuxt3中的SSR缓存差异解析

在服务端渲染(SSR)应用中，状态管理是一个需要特别注意的问题。TanStack Query作为流行的数据获取库，在不同版本的Nuxt框架中表现出不同的SSR缓存行为，这可能导致严重的隐私问题。

问题现象

当在Nuxt2/Vue2环境中使用TanStack Query时，我们发现服务端渲染的查询缓存会在不同用户请求间共享。具体表现为：用户A访问页面获取个人数据后，用户B访问时可能会短暂看到用户A的数据，直到客户端重新获取数据。这种跨请求状态污染(cross-request state pollution)在Nuxt3/Vue3中不会出现，因为Nuxt3的useState机制天然支持请求隔离。

技术原理分析

造成这种差异的核心原因在于Vue2和Vue3的架构差异：

1. Vue2的共享实例：在Nuxt2中，Vue实例是跨请求共享的，即使重置查询缓存，也可能存在多个并发请求相互干扰的情况
2. Vue3的响应式隔离：Nuxt3利用Composition API的useState为每个请求创建独立的状态对象，天然避免了状态污染
3. SSR生命周期：服务端渲染时，应用实例可能被复用，而客户端渲染时又会重新初始化，这种不一致性需要特别处理

解决方案

对于Nuxt2/Vue2项目，可以采用以下方案确保查询隔离：

1. 请求级QueryClient：为每个请求创建独立的QueryClient实例
2. 显式传递客户端：在所有useQuery调用中显式指定queryClient参数
3. 状态序列化：确保只在当前请求上下文中处理hydration

示例实现：

// 插件中初始化
export default (context) => {
  const queryClient = new QueryClient();
  if (process.server) {
    context.ssrContext.VueQuery = queryClient;
  }
  // ...其余初始化逻辑
};

// 组件中使用
const { ssrContext } = useContext();
const queryClient = ssrContext?.VueQuery || useQueryClient();

const { data } = useQuery({
  queryKey: ['privateData'],
  queryFn: fetchData,
}, queryClient);

最佳实践建议

1. Nuxt3项目：直接使用官方示例即可获得良好的请求隔离
2. Nuxt2项目：必须实现上述请求隔离机制
3. 类型安全：为SSR上下文添加类型定义，避免运行时错误
4. 性能考量：虽然创建多个QueryClient实例会增加内存使用，但对隐私敏感数据是必要代价
5. 测试验证：特别要测试并发请求场景下的数据隔离性

总结

TanStack Query在不同Nuxt版本中的行为差异提醒我们，在SSR场景下必须特别注意状态隔离问题。对于新项目，建议直接使用Nuxt3以获得更完善的SSR支持。对于现有Nuxt2项目，则需要通过显式的请求级QueryClient管理来确保数据隔离和隐私安全。