用途：解释服务端渲染的静态 HTML 如何通过 JavaScript 附加事件处理器变为可交互应用，并对比多种水合策略，帮助在性能与交互性之间做取舍。
主要能力：
- 水合基础：服务端渲染 HTML → 浏览器先显示（快 FCP）→ 下载并执行 JS → 框架遍历 DOM、附加监听器、初始化状态 → 达到可交互（TTI）。
- 水合间隙：内容可见到可交互之间的时间，页面看似就绪但按钮无效。
- 常见挑战：TTI 延迟、水合不匹配（服务端与客户端渲染结果不同，如时区/时间差异）、包体积过大、遍历 DOM 的 CPU 成本。
- 策略对比：完全水合（整页水合，模型简单但包大、TTI 慢）；渐进式水合（按优先级，先首屏，滚动/空闲/交互时再水合）；选择性水合（React 18+ Suspense，组件独立水合，用户交互可提升优先级）；部分水合（静态组件不发 JS）；岛屿架构（静态 HTML 海洋中的独立交互组件，各自独立水合，如 Astro 的 client:load、client:visible、client:idle）；可恢复性（Qwik 序列化状态与处理器，跳过水合）。
使用方式：按场景选择——SPA/仪表盘用完全水合；内容站用岛屿；电商产品页用部分/渐进式；营销页用岛屿或 SSG；高交互应用用完全水合加代码分割。避免水合不匹配（客户端专属值放入 useEffect）、避免水合阻塞于数据请求、避免顶层导入重型库（改用动态导入）。
适用场景与限制：适用于讨论 SSR 框架性能优化、架构选型与调试水合问题。资料未提供具体框架版本要求、安装命令、收费或平台信息；示例代码为概念性说明，实际实现依框架而定。