直接回答：SSR 把组件渲染成 HTML 发过去，浏览器还要再跑一遍全部组件 JS 重建状态、绑事件（hydration），页面才能交互——首屏 HTML 已可见却点不动的空窗期（uncanny valley）与全量 JS 执行成本就是 hydration 税。岛屿架构只让真正可交互的组件（岛屿）水合，其余静态内容永远不发 JS，把成本从 O（全页面） 降到 O（交互点）。
展开解析：优化路线谱系：传统全量水合（Next.js 默认）——简单但页面越复杂税越重；岛屿架构（Astro、Fresh）——组件按 client:load/client:idle/client:visible 指令声明水合时机与策略，静态文章页可零 JS，交互组件各自独立水合互不阻塞；渐进/选择性水合（React 18 Suspense 边界）——水合按 Suspense 边界分段，用户点击未水合区域时该段可插队优先；可恢复性 resumability（Qwik）——最激进，状态序列化进 HTML，事件触发时才按需加载对应代码，理论上零 hydration 执行。选择维度：内容站（博客、文档）岛屿架构收益最大——90% 内容静态；复杂应用（后台、协作工具）交互面大，岛屿收益缩水，选择性水合或代码分割更实际。工程细节：岛屿间通信要显式设计（各自独立水合，共享状态走 store 或自定义事件）；水合不匹配（服务端与客户端渲染结果不一致）是 SSR 的常年 bug 源——时间、随机数、浏览器环境探测必须延后到 mount 后；衡量收益看 TTI 与 INP 而非只看 LCP。
追问方向：resumability 与 hydration 的状态恢复机制有何本质差异？岛屿间共享布局组件如何处理？
（约 500 字）