[!info] related notes

• 代表框架: Astro
• 相似模型: React Server Components, React 服务端组件与客户端组件, Next.js
• 相关机制: Hydration, CSR、SSR 与 SSG
• 所属入口: 前端工程化 MOC

Islands Architecture

一句话定义

Islands Architecture 是一种前端架构模式：页面大部分内容先成为静态或服务端生成的 HTML，只有少量真正需要交互或个性化的区域被当作“岛屿”，单独加载 JavaScript 并 hydration。

可以把它想成：

静态 HTML 海洋
├── 文章正文
├── 标题
├── 图片
│
├── [Search Island]      → 有 JS
└── [Carousel Island]    → 有 JS

它解决的核心问题是：不要因为页面上只有少数区域需要交互，就把整个页面都变成一个巨大的客户端 JavaScript 应用。

Astro 中的实现

Astro 是 Islands Architecture 的代表实现之一。默认情况下，UI Framework Component 可以只输出 HTML/CSS，不自动把组件 JavaScript 发送给浏览器。

需要交互时，再显式声明客户端指令：

<MyReactComponent client:load />
<SearchBox client:visible />

不同指令还能表达“什么时候值得加载”：

• client:load：页面加载时立即加载和 hydration。
• client:idle：浏览器空闲时再加载。
• client:visible：进入视口时才加载。
• client:only：跳过服务端 HTML 渲染，纯客户端执行。

因此 Island 不只是在问“客户端还是服务端”，还可以进一步控制客户端 JavaScript 的加载时机。

为什么这种模式有效

传统单体 SPA 容易形成：

整个页面
  ↓
一个大 JavaScript App
  ↓
下载 + parse + execute + hydrate

Islands Architecture 则试图变成：

HTML-first page
├── 大量无需 JS 的内容
└── 少量独立 interactive islands

典型收益：

• 客户端 JavaScript 更少
• hydration 范围更小
• 不同岛屿可以独立、并行激活
• 低优先级交互可以延迟加载
• 内容型页面更容易保持快速首屏

与 React Server Components / Next.js 的关系

它和 React Server Components、Next.js 有相似目标：

把不需要浏览器执行的代码留在服务器或构建阶段，只给真正需要交互的区域发送客户端 JavaScript。

但不能把二者视为同一种机制。

维度	Astro Islands	Next.js App Router / RSC
出发点	HTML-first	React tree first
默认客户端 JS	Astro/框架组件默认可不发 JS	Server Components 不进 client bundle；Client Components 需要 client runtime
交互边界	client:* island	"use client" module boundary
hydration	每个 client island 独立 hydration	Client Component 子树 hydration
服务端模型	Astro component / server island	React Server Components
主要优势场景	内容型网站、博客、文档、营销站	复杂 React Web App、Dashboard、SaaS、全栈应用

所以：

Astro:
HTML + interactive islands

Next.js:
React Server Component tree + Client Component boundaries

“Client Component 像一个交互岛”是很好的学习类比，但并不是严格的实现等价。

Client Island 与 Server Island

现代 Astro 还区分：

• Client Island：浏览器中的独立交互组件。
• Server Island：页面其余部分可以静态缓存，但某个个性化/动态区域单独延迟到服务器生成。

这说明 Islands Architecture 的核心并不是简单的“静态站点”，而是：

把页面按独立执行与更新边界拆开，让昂贵的动态能力只发生在真正需要的位置。

边界与常见误解

Island 不等于任意组件

只有存在独立交互、个性化或延迟执行价值的区域，才有必要成为 island。机械地把每个按钮都拆成岛，并不会自动得到更好的架构。

少 JS 不等于零 JS

有搜索、编辑器、弹窗、播放器等交互时仍然需要 JavaScript；优化目标是“按需加载”，不是强行消灭 JavaScript。

Islands 与 SSR 不是同一个维度

SSR 描述请求时如何生成 HTML；Islands 描述页面如何划分客户端激活边界。一个 SSR 页面也完全可以采用 Islands Architecture。

历史背景

“Component Island”这一术语在 2019 年由 Etsy 前端架构师 Katie Sylor-Miller 提出，随后 Preact 作者 Jason Miller 在 2020 年进一步系统化讨论。Astro 后来帮助推广了这种架构，并把它变成框架的核心默认模型。

最短记忆方式

页面是 HTML 的海洋，只有需要交互的地方才浮出 JavaScript 岛屿。

学习 Next.js 时可以借这个模型理解“尽量缩小 Client Boundary”，但要继续记住：Astro Islands 与 React Server Components 是相似目标下的不同实现。