[!info] related notes

• 核心架构: Islands Architecture
• 相关渲染概念: Hydration, CSR、SSR 与 SSG
• 相邻框架: Next.js

Astro

这是什么

Astro 是一个以内容型网站为主要优势场景的 Web Framework，常用于：

• 博客
• 文档
• 营销站
• 数字花园
• 内容型电商页面

它最值得建立的心智不是“又一个 React/Vue 框架”，而是：

HTML-first，JavaScript 按需进入页面。

默认模型

Astro 组件中的服务端/构建阶段逻辑用于生成 HTML；默认情况下，不因为使用一个 UI Framework Component 就自动把它的客户端 JavaScript 一并发送给浏览器。

Astro / framework component
        ↓
server/build render
        ↓
HTML + CSS
        ↓
Browser

只有真正需要浏览器交互的部分，才显式声明客户端运行策略。

Islands Architecture

Astro 帮助推广了 Islands Architecture：

静态 HTML 海洋
├── Article
├── Header
├── Image
└── Interactive Island
      └── JavaScript + Hydration

例如：

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

这表示：

• SearchBox 页面加载时就需要交互。
• Chart 只有进入视口后才值得加载客户端 JavaScript。

所以 Astro 不只控制“哪块需要 JS”，还能控制“什么时候加载 JS”。

与 Next.js Server/Client Components 的联系

Astro Islands 和 Next.js App Router 有一个很相似的目标：

不要因为页面局部需要交互，就把整页实现代码全部发送给浏览器。

但架构模型不同：

Astro
= HTML-first + independently hydrated islands

Next.js App Router
= React Server Component tree + Client Component boundaries

因此可以把 Next.js Client Boundary 类比成“交互岛”来建立直觉，但不能认为二者实现机制相同。

为什么 Astro 特别适合内容型网站

如果页面大部分是：

• 文字
• 图片
• Markdown
• 导航
• 文章列表

只有少量：

• 搜索
• 评论
• Carousel
• ThemeSwitcher

需要 JavaScript，那么默认发送一个完整 SPA runtime 往往没有必要。

Astro 的默认策略会让这种页面自然保持较小的客户端 JavaScript 成本。

不是所有应用都应该优先 Astro

如果产品本质是：

• 大型 authenticated application
• 高度交互 Dashboard
• 大量跨组件客户端状态
• 编辑器 / 工作台
• 复杂 React 应用生态

那么 Next.js、纯 React SPA 或其他应用型框架可能更自然。

这不是“哪个框架性能更好”的简单排名，而是应用结构是否符合框架默认模型。

最短记忆方式

Astro = HTML first
      + JavaScript on demand
      + Islands Architecture