响应式系统SSR“注水”报错本质是客户端激活时DOM结构、文本或节点顺序与服务端输出不一致，导致丢弃HTML重渲染；关键在于确保两端渲染结果严格一致，需统一初始数据、隔离请求状态、规避环境敏感逻辑、校验VNode结构。
响应式系统在 SSR 环境下出现“注水”报错（hydration mismatch），本质不是状态没传过去，而是客户端激活时发现 DOM 结构、文本内容或节点顺序与服务端输出不一致，被迫丢弃服务端 HTML、重新渲染——这既破坏首屏性能，也暴露逻辑隐患。关键不在“怎么把响应式对象塞进客户端”，而在“如何让两端渲染结果严格一致”。
确保服务端与客户端使用同一份可序列化初始数据
服务端无法序列化 Proxy、函数、Symbol、Date 实例等非 JSON 安全值。响应式 Store（如 Pinia/Vuex）的 $state 必须是纯对象，且只含基础类型字段。
- 服务端：调用
store.$state = { user: { id: 1, name: 'Alice' } }显式赋值，不要用toRaw()或直接修改响应式引用 - 客户端：在
createApp()之前读取window.__INITIAL_STATE__，并执行store.$state = window.__INITIAL_STATE__.user - 避免在 store 的
state中存router、axios实例或EventBus—— 这些只应在组件内按需注入
隔离请求级状态，杜绝跨用户污染
Node.js 是单进程多请求模型。若在模块顶层创建全局 Store 实例（如 export const pinia = createPinia()），所有用户将共享同一状态，A 用户登录态可能被 B 用户看到。
- 服务端入口（如
entry-server.js）中，每次请求都调用createPinia()创建新实例，并传入app.use(pinia) - 客户端入口（
entry-client.js）复用单例，但必须在挂载前用服务端注入的数据重置pinia.state.value - 若用 Vuex，同理：服务端用
new Vuex.Store({ state: {} })按请求新建，禁止复用 store 单例
跳过服务端执行的环境敏感逻辑
任何依赖 window、document、localStorage 或时间/随机数的代码，都会导致服务端渲染结果与客户端不一致。
- 动态 class/style 不要用
Math.random()或Date.now()生成唯一 ID；改用服务端可预测的标识（如路由参数、服务端传入的id） - 浏览器专属操作（如监听 resize、读取 viewport 宽度）必须包裹在
onMounted或if (typeof window !== 'undefined')中 - 路由相关状态（如当前 query、params）不要在 store 中直接调用
useRoute()，而应在组件 setup 中获取后 commit 到 store
校验 VNode 结构一致性，避免隐式差异
Vue 的 hydration 要求服务端生成的 HTML 与客户端 render 函数产出的 VNode 树完全匹配：key 位置、v-if/v-for 分支顺序、slot 内容分布都必须一致。
- 禁用服务端不可控的条件判断，例如
/Mobi/.test(navigator.userAgent)—— SSR 无navigator，会走默认分支，CSR 却走移动端分支 - 服务端渲染的静态标记（如
staticCount）需与客户端编译产物对齐；建议统一使用 Vue CLI 或 Vite 构建，避免服务端/客户端使用不同版本的编译器 - 对第三方组件不确定是否 SSR 友好，可用
<ClientOnly>或defineAsyncComponent({ ssr: false })显式跳过服务端渲染
