Angular v22 增量水合：SSR/CSR 混合架构下的按需激活策略

Angular 在 v16 引入全应用水合（Full Application Hydration）后，持续深耕服务端渲染（SSR）与客户端渲染（CSR）的融合策略。v22 版本中，增量水合（Incremental Hydration）已从开发者预览版演进为成熟特性，为复杂应用的性能优化提供了细粒度控制手段。本文将从架构原理、触发器配置到落地实践，系统梳理这一机制的工程化应用。

从全量到增量：水合策略的演进

传统 SSR 应用在客户端启动时需一次性水合整个应用，这导致主线程长时间被阻塞，影响首次输入延迟（FID）。Angular 的增量水合允许开发者将部分组件保持在脱水（Dehydrated）状态 —— 服务端渲染的 HTML 直接呈现，但组件实例、生命周期钩子和变更检测均被延迟加载。

脱水内容的行为特征值得注意：它表现为纯静态 HTML，不创建组件实例，不执行生命周期，也不响应绑定更新。只有当触发条件满足时，Angular 才会异步获取组件代码并完成水合。这一设计使得首屏关键路径外的代码可以从初始包中剥离，显著降低 TTI（Time to Interactive）。

触发器配置：何时激活组件

增量水合通过 @defer 块的 hydrate 触发器定义水合边界。与常规 @defer 触发器不同，hydrate 触发器仅作用于 SSR 初始加载阶段，CSR 导航时则回退到标准触发器。

常用触发器模式

空闲时水合适用于非关键内容：

@defer (hydrate on idle) {
  <analytics-dashboard />
}

支持可选的超时参数 idle(500)，单位为毫秒，确保即使浏览器未调度空闲回调，代码加载也不会无限延迟。

视口内水合结合 Intersection Observer API，适合首屏下方的内容：

@defer (hydrate on viewport) {
  <product-recommendations />
}

交互时水合延迟加载低频交互组件，如设置面板或高级筛选器：

@defer (hydrate on interaction) {
  <advanced-filter />
}

永不水合将内容永久保持静态，适合纯展示区域如页脚版权信息：

@defer (hydrate never) {
  <static-footer />
}

需注意 hydrate never 仅影响初始 SSR 加载，后续 CSR 导航时该块仍会按常规 @defer 逻辑处理。

复合触发策略

实际场景中常需组合触发器。例如首屏内容采用 hydrate on immediate 确保快速可交互，而折叠内容使用 hydrate on viewport：

@defer (on viewport; hydrate on immediate) {
  <heavy-chart />
}

分号分隔的触发器以 "或" 逻辑工作，任一条件满足即触发水合。

事件回放：无感交互的保障

增量水合引入了关键问题：若用户在水合完成前与脱水内容交互，事件是否会丢失？Angular 通过事件回放（Event Replay）机制解决这一问题。当启用增量水合时，框架自动在脱水内容上监听用户事件，待水合完成后按原始顺序重放。

这意味着开发者无需担心竞态条件 —— 按钮点击、表单输入等操作都会被暂存并正确执行。值得注意的是，事件回放已在 provideClientHydration() 中自动启用，无需手动配置 withEventReplay()。

嵌套水合与依赖层级

Angular 的组件系统具有层级性，水合子组件前必须先水合其父组件。当嵌套的 @defer 块触发水合时，框架自顶向下逐级处理，形成自然的加载瀑布。

@defer (hydrate on hover) {
  <parent-cmp />
  @defer (hydrate on interaction) {
    <child-cmp />
  }
}

上述示例中，悬停父区域将触发两级水合，父组件先于子组件完成激活。

hydrate when 触发器有特殊限制：它依赖父组件的表达式上下文，因此仅在父组件已水合时才可评估。若父块仍处于脱水状态，条件表达式无法解析，水合将被延迟。

布局稳定性与首屏优化

增量水合解决了传统 @defer 在首屏内容上的布局抖动问题。过去，首屏的延迟块会先渲染占位符再替换为实际内容，导致 CLS（Cumulative Layout Shift）。增量水合下，服务端直接渲染主模板内容，客户端延迟水合而非延迟渲染，视觉稳定性得到保障。

这一特性使 @defer 可安全应用于首屏区域，如导航栏、轮播图等。结合热图分析，开发者可将低点击率的首屏组件设为 hydrate on interaction，在保持 SEO 友好的同时减少初始 JS 执行量。

实施检查清单

迁移至增量水合时，建议按以下步骤验证：

1. 结构合规：脱水块的根节点不能是纯文本节点，必须包装在 HTML 元素内，因为浏览器无法对文本节点监听事件或执行 Intersection Observer 观察。

2. 占位符保留：即使 SSR 场景下不显示 @placeholder，仍需保留该块以兼容 CSR 导航场景。

3. RouterLink 处理：hydrate never 块内的 routerLink 将退化为硬导航。若需 SPA 路由体验，应避免在永不水合区域使用路由指令，或确保交互触发水合。

4. 性能监控：通过 Lighthouse 或 Web Vitals 对比启用前后的 FID、TTI 和 CLS 指标，量化优化收益。

局限与未来方向

当前实现中，嵌套水合可能产生代码加载瀑布，团队已表示将优化此问题。此外，完全静态的应用架构（类似 Islands Architecture）仍是未来探索方向，增量水合被视为迈向可恢复性（Resumability）的中间步骤。

对于依赖服务端时区的组件（如日期选择器），需谨慎评估 SSR 渲染值的准确性，必要时设置 hydrate on immediate 或 ngSkipHydration 规避时区偏差。

参考来源

• Angular Documentation: Incremental Hydration
• Angular RFC #57664: Incremental Hydration Discussion

web