Hydration、Islands 与服务端组件

Hydration、Islands 与服务端组件

这篇笔记还在编辑中，内容可能会继续补充、调整或重写。

HTML 到可交互页面之间还有什么

SSR 可以更早返回 HTML，但页面要响应框架事件，通常仍需下载 JavaScript、恢复组件树并绑定行为，这个过程称为 Hydration。HTML 已经可见不等于应用已经可交互；大型同步 Hydration 仍可能造成主线程阻塞和输入延迟。

几种现代模型

  • 全量 Hydration：客户端恢复完整应用，模型简单但 JavaScript 和恢复成本可能较高。
  • 选择性或渐进 Hydration：优先恢复用户即将交互的边界。
  • Islands：页面大部分保持静态，只为需要交互的局部组件发送客户端代码。
  • 服务端组件：部分组件只在服务端执行，以序列化结果与客户端组件组合。
  • 流式 SSR：服务端逐步发送可用片段，并让数据、错误和 Suspense 边界独立完成。

这些词来自不同框架，具体语义不能混用。选型应回到代码发送量、交互边界、数据位置、缓存和部署环境。

边界设计

跨服务端与客户端边界的数据必须可序列化。数据库连接、服务端秘密和文件系统能力只能留在服务端；浏览器事件、DOM API 和本地状态只能存在于客户端边界。

边界过粗会发送过多 JavaScript，边界过细则增加序列化、网络往返和理解成本。组件是否交互、是否访问浏览器 API、数据是否可缓存，是划分边界的主要依据。

Hydration 不一致

服务端 HTML 与客户端首次渲染不一致时会出现警告、丢弃 DOM 或视觉闪烁。常见原因包括随机数、当前时间、时区、浏览器专属 API、服务端与客户端数据版本不同，以及不合法 HTML 被浏览器重写。

实践任务

  1. 构建一个静态内容为主、只有搜索框和收藏按钮需要交互的页面。
  2. 比较全量客户端应用与 Islands 版本的 JavaScript 和 INP。
  3. 故意使用当前时间制造 Hydration 不一致，再通过明确的数据边界修复。
  4. 使用慢数据源验证流式边界的加载、错误和重试体验。

验收标准

  • 能区分 HTML 可见、可操作和完成 Hydration 的时间点
  • 服务端秘密不会跨边界进入客户端产物
  • 交互边界有加载、错误和无 JavaScript 降级考虑
  • 时区、随机数和数据版本不会造成 Hydration 不一致
  • 架构选择有 JavaScript 体积与真实交互指标支持

参考资料