Vue SSR全局状态核心是服务端数据注水与客户端初始化一致性，需确保状态可序列化、请求级Store隔离、副作用仅客户端执行、hydration前完成数据预取。
Vue 全局状态做 SSR 时，核心矛盾在于：服务端创建的响应式状态无法直接传递到客户端，而客户端又需要“接住”服务端渲染出的 HTML 和对应数据。关键不是让状态“跨端共享”，而是实现服务端数据注水（hydration）与客户端状态初始化的一致性。避坑重点不在技术炫技，而在生命周期、序列化边界和实例隔离。
用可序列化的状态对象替代响应式 Store（服务端友好）
服务端无法执行 new Vue() 或 createPinia() 后的响应式代理（Proxy / defineProperty），也无法序列化函数、Symbol、Map/Set 等非 JSON 安全值。因此全局状态的初始值必须是纯 JS 对象，且只含 JSON 可序列化字段。
- Pinia 推荐使用
store.$state手动提取（而非toRaw(store)），并在服务端调用store.$patch({})预设值 - 避免在 store 中存
router、axios 实例、EventBus等副作用依赖 —— 它们只应在客户端 setup 或 onMounted 中注入 - 服务端生成的初始状态应通过
window.__INITIAL_STATE__ = {...}注入模板，客户端在createApp前读取并store.$state = window.__INITIAL_STATE__.user
确保每个请求独占 Store 实例（防交叉污染）
Node.js 是单进程多请求场景，若在模块顶层创建 Pinia 实例（如 export const pinia = createPinia()），所有请求将共享同一 store，造成用户 A 的数据泄露给用户 B。
- 服务端入口（如
entry-server.js）中，每次请求都调用createPinia()创建新实例，并传入app.use(pinia) - 客户端入口（
entry-client.js）中复用同一个 Pinia 实例，但需在挂载前调用pinia.state.value = window.__INITIAL_STATE__恢复 - 若用 Vuex，同理：服务端用
new Vuex.Store({ state: {...} })按请求新建，不复用 store 单例
跳过服务端的副作用逻辑（仅客户端激活）
全局状态常伴随异步获取、监听路由、订阅 WebSocket 等操作，这些在服务端无意义甚至报错（如访问 window、document）。
使用 `@ainative/vue-sdk` 为 Vue 3 应用添加 AI 聊天功能。适用于以下场景：(1) 安装 `@ainative/vue-sdk`，(2) 在 Vue 组件中使用 `useChat` 组合式函数，(3) 提供……
立即学习“前端免费学习笔记（深入）”；
- 把副作用逻辑包裹在
if (import.meta.env.SSR)或更稳妥地用if (typeof window !== 'undefined')判断 - Pinia 的
onMounted、watch、subscribe等 API 默认只在客户端生效；但自定义 action 内部若含fetch，需显式守卫 - 路由相关状态（如当前 route、query）不要在 store 中直接读
useRoute()，而应在组件中获取后 commit/pin to store，或用pinia-plugin-persistedstate配合 hydration 时机控制
正确触发客户端 Hydration（避免状态不一致警告）
Vue 3.4+ 对 SSR hydration 增加了严格校验：若服务端渲染的 DOM 结构与客户端首次 mount 时的 vnode 不匹配（例如服务端返回 <div>Loading</div>，客户端立即显示真实内容），会抛出 warning 甚至 fallback 到客户端重绘。
- 服务端必须等待所有关键 store 数据 resolve 完成（如
await Promise.all([store.fetchUser(), store.fetchPosts()])）再调用renderToString(app) - 客户端
app.mount()前，确保 store 已用window.__INITIAL_STATE__初始化完毕，且不触发额外 mutation（否则 vnode diff 失败） - 对异步组件、Suspense 边界要格外小心：服务端不会等待
defineAsyncComponent内部的setup，需配合async setup()+await显式控制数据流
不复杂但容易忽略：SSR 状态同步的本质是“服务端算一次、客户端接住、之后各自运行”。只要守住可序列化、实例隔离、副作用守卫、hydration 时机这四条线，就能避开 90% 的水合失败和数据闪烁问题。
