“注水”是 vue ssr 中将服务端生成的静态 html 与客户端 vue 实例关联、恢复响应式和交互能力的过程，不重建 dom 而复用结构挂载逻辑；报错“hydration node mismatch”源于客户端 vnode 与服务端 html 结构不一致，常见于非确定性内容、环境误判或条件渲染漂移。
“注水”（Hydration）是 Vue SSR 中的关键环节，不是往页面里灌水，而是把服务端生成的静态 HTML “唤醒”，让它重新关联 Vue 实例、恢复响应式和交互能力。它不重建 DOM，而是复用已有的结构，在其上挂载事件监听、响应式依赖和组件逻辑。
为什么叫“注水”？
这个词借用了化学中“水合”的概念——物质与水结合形成新结构。在前端语境里，HTML 是“干”的（无状态、无行为），Vue 的响应式系统是“水”，二者结合后才成为可交互的完整应用。“注水”强调的是“已有结构 + 新能力”的融合过程，而非从零渲染。
报错“Hydration node mismatch”是怎么回事？
这个错误表示：客户端 JavaScript 渲染出的 VNode 结构，和服务端吐出的 HTML DOM 树对不上。Vue 在首次挂载时会逐节点比对，一旦发现标签、属性、子节点顺序、key 或 v-if/v-for 展开结果不一致，就会中断注水，降级为清空 DOM 并重新渲染——导致闪屏、状态丢失、事件失效。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
常见诱因包括：
- 组件中使用了 非确定性内容：比如
new Date().toISOString()、Math.random()、performance.now()，服务端和客户端值不同，造成 class 或文本不一致 -
环境判断失误：在 setup() 或 data() 中直接访问
window或document，服务端报错或返回默认值，客户端却正常执行，结构自然不匹配 -
条件渲染逻辑漂移：例如服务端判定
v-if="user.token"为 false，渲染了登录框；但客户端 token 已存在（如 localStorage 有残留），却渲染了首页 —— 整个子树结构完全错位 -
keep-alive 或异步组件未对齐：服务端跳过某些组件（如设了
ssr: false），但客户端没做同样处理，导致 slot 内容或包裹层级不一致
怎么稳定注水、避免报错？
核心原则就一条：服务端和客户端必须基于**完全相同的输入**，产出**结构完全一致**的输出。具体落地看这几处：
-
数据要可预测、可同步：所有影响渲染的数据，必须通过服务端预取（
asyncData/fetch/useAsyncData）提前拿到，并注入到初始 state（如window.__INITIAL_STATE__），客户端初始化 store 时直接还原，而不是等 mounted 后再请求 -
副作用只在客户端运行：路由守卫、WebSocket 连接、第三方 SDK 初始化、DOM 尺寸测量等，全部用
if (typeof window !== 'undefined')包裹，或放在onMounted中 -
避免服务端不可控的动态内容：时间类、随机类、用户代理类字段，要么统一用服务端传入的上下文（如请求时间戳），要么延迟到注水完成后再更新（用
nextTick+onMounted） -
组件级别可控：对不兼容 SSR 的组件（如含 canvas、video、富文本编辑器），明确标注
defineAsyncComponent({ ssr: false })或用<clientonly></clientonly>包裹，确保服务端和客户端都跳过它
出错了怎么办？别硬扛
Vue 不会静默失败。遇到 mismatch，控制台会清晰提示哪一行、哪个节点不匹配。这时不要删 warning 或关 hydration —— 而应把它当作精准的调试线索：
- 对比服务端 renderToString 输出的 HTML 字符串，和浏览器开发者工具里看到的源代码，逐层检查差异点
- 临时关闭服务端渲染（如 Nuxt 中设置
ssr: false），确认客户端逻辑本身是否正确 - 检查模板中是否有隐藏空格、换行、注释节点干扰了子节点数量判断（尤其在
v-for和插槽中） - 若用 UI 库（如 Element Plus、Ant Design Vue），确认其版本是否完全支持 Vue 3 SSR，部分组件内部逻辑可能隐式依赖客户端环境
