Islands Architecture（岛屿架构）
将页面拆分为"静态海洋"和"交互岛屿"的渲染架构。静态部分输出纯 HTML 不加载 JS，只有需要交互的岛屿组件才下载和水合对应的 JS。Astro 是最典型的实现。
核心概念
Islands Architecture 由 Etsy 前端架构师 Katie Sylor-Miller 提出、Jason Miller（Preact 作者）命名和推广。核心思想：大多数网页内容是静态的，只有少量区域需要交互。传统 SPA 为了那 10% 的交互性，让 100% 的页面都承担 JS 下载和水合成本——这是巨大的浪费。
Islands 架构的做法：
- 页面的静态部分（导航栏、正文、页脚等）在服务端渲染为纯 HTML，不附带任何 JS
- 需要交互的组件（搜索框、评论区、轮播图等）被标记为"岛屿"，各自独立水合
- 每个岛屿有自己的 JS bundle，按需加载——未进入视口的岛屿可以延迟加载
结果：页面的 JS 总量和水合成本与交互组件的数量成正比，而不是与页面总大小成正比。一个 90% 静态的博客页面，Islands 架构的 TTI 接近纯静态 HTML。
Astro 的实现
Astro 是 Islands Architecture 最成熟的实现。交互岛屿通过 client:* 指令声明：
<!-- 静态部分：零 JS -->
<Header />
<article>{content}</article>
<!-- 交互岛屿：按策略加载 JS -->
<SearchBar client:load /> <!-- 页面加载即水合 -->
<Comments client:visible /> <!-- 进入视口时水合 -->
<Analytics client:idle /> <!-- 浏览器空闲时水合 -->
Astro 的另一个关键特性是框架无关——岛屿内部可以使用 React、Vue、Svelte、Solid 等任何框架的组件，甚至同一页面上混用多个框架。每个岛屿是一个独立的 hydration 根。
与其他部分水合策略的对比
Islands vs React Server Components（RSC）
两者目标相似（减少客户端 JS 量）但路径完全不同：
| 维度 | Islands (Astro) | RSC (Next.js) |
|---|---|---|
| 静态/动态边界 | 组件级，显式 client:* 指令 | Suspense 级，'use client' 指令 |
| 框架 | 框架无关，可混用 | React 生态内 |
| 哲学 | "默认静态，交互是例外" | "默认动态，静态是优化" |
| 跨岛通信 | 困难（各岛屿独立，需通过 DOM 事件或全局状态桥接） | 自然（Client/Server Components 共享 React 树） |
Islands vs Qwik Resumability
Islands 仍然需要水合（虽然只水合岛屿），Qwik 的 Resumability 彻底消灭了水合——即使是交互组件也不需要重新执行 JS 来"接管"。但 Qwik 要求所有状态可序列化，Islands 对岛屿内部的代码没有这个约束。
Partial Prerendering（PPR）
Next.js 14+ 的 PPR 把 Islands 的思路搬进了 React 生态：静态 shell 在 build time 生成（CDN 级 TTFB），动态部分用 Suspense 边界包裹、streaming 注入。但实现路径依赖 RSC + Suspense，和 Astro 的显式指令模式截然不同。
适用场景
Islands Architecture 最适合内容为主、交互为辅的站点——文档、博客、营销页、电商商品详情页。对于交互密集型应用（编辑器、协作工具、数据看板），岛屿之间的通信开销和状态同步复杂度会抵消其优势，此时传统 SPA 或 RSC 更合适。
引用本术语的文章