Hydration 是客户端复用服务端 HTML 并激活交互能力的过程，需严格对齐结构与内容；失败源于服务端与客户端渲染不一致，常见于随机值、环境变量、客户端 API 等差异。
Hydration 是服务端渲染（SSR）中客户端“接管”静态 HTML 的关键步骤，不是重绘页面，而是让已存在的 DOM 活起来——绑定事件、恢复状态、挂载生命周期，整个过程必须严格对齐服务端输出的结构和内容。
Hydration 的本质是“复用+激活”
服务端返回的 HTML 是纯静态的：有按钮、有文字、有布局，但没点击逻辑、没输入响应、没状态记忆。浏览器渲染完这层 HTML 后，JavaScript 才开始执行；此时框架（如 React、Vue、Sycamore）会扫描 DOM，找到对应组件的根节点（比如 id="root"），然后把虚拟 DOM 树与真实 DOM 逐节点比对、关联，把事件监听器和响应式状态“注入”进去。
- 它不创建新 DOM，只复用已有节点
- 它不重新渲染，只“唤醒”交互能力
- 它依赖服务端与客户端渲染结果完全一致——这是成功水合的前提
Hydration mismatch 错误从哪来
只要服务端生成的 HTML 和客户端初始化时预期的结构或文本不一致，就会触发 Hydration mismatch。常见原因包括：
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- 服务端渲染时用了
Date.now()或Math.random()，导致客户端首次 render 结果不同 - 组件在服务端和客户端读取了不同的环境变量（如
process.env.NODE_ENV影响条件渲染） - 使用了仅客户端可用的 API（如
window、localStorage），服务端执行时报错或跳过，造成 DOM 差异 - 样式或字体加载延迟导致 SSR 输出的 DOM 与 CSR 首次计算的 layout 不一致（尤其影响 SSR + CSS-in-JS 场景）
Partial Hydration：让水合更轻量
全量水合会一次性激活整页 JS，带来较大首屏阻塞。Partial Hydration 允许只对需要交互的区域（比如搜索框、购物车按钮、评论表单）做水合，其余静态区块（如文章正文、侧边栏广告）保持“脱水”状态，不加载对应 JS。
- 降低初始 JS 体积和执行时间
- 避免非关键区域的 hydration 开销
- 需配合服务端标记（如
data-hydrate="search"）和客户端按需挂载机制
怎么验证水合是否成功
最直接的方式是打开浏览器开发者工具，检查目标元素是否绑定了事件监听器（Elements → Event Listeners 面板），同时观察控制台是否有 Hydration failed 或 mismatch 报错。
- React 中可启用
hydrateRoot的onRecoverableError回调捕获水合异常 - Vue 3 使用
createSSRApp并调用app.mount()完成水合，失败时抛出警告 - 生产环境建议关闭 hydration 警告，但开发阶段务必开启以暴露潜在不一致
