Astro 系列（一）：Astro 是什么，解决什么问题
Astro 入门与实战 系列导航
背景：前端框架的分化
过去十年，前端世界围绕着两种范式分化：多页应用（MPA）和单页应用（SPA）。
MPA 是传统 web 的方式——每个页面是独立的 HTML 文档，点击链接时浏览器加载新页面。它简单、SEO 友好、对内容站点天然合适。但缺点是页面跳转有明显白屏，交互体验割裂。
SPA 是 React/Vue/Angular 带来的革命——整个应用加载一次，之后所有交互都在客户端完成。它提供了丝滑的页面切换和丰富的交互体验。但代价很大：首屏需要加载大量 JavaScript，水合（hydration）过程消耗 CPU，对纯内容展示型页面来说，这些开销是浪费。
核心问题：水合作用的代价
当你用 Next.js 或 Nuxt 构建一个博客时，服务端渲染出 HTML，但客户端仍然要下载整个 React/Vue 运行时，并在每个组件上执行水合——将静态 HTML 变成可交互的 DOM。对于一篇纯文本文章来说，这些开销是多余的。
这就是 Astro 切入的问题空间：大多数页面根本不需要 JavaScript。
岛屿架构：Astro 的核心创新
Astro 提出了"岛屿架构"（Islands Architecture）——页面默认是纯静态 HTML，只有需要交互的部分（如表单、评论区、图表）才作为"岛屿"激活。
类比：页面是一片静态的海洋，交互式组件是海上的岛屿。每个岛屿独立加载、独立水合，互不干扰。
这个设计直接解决了水合浪费的问题：
- 一篇博客文章 + 评论区的页面，只有评论区需要 JS
- 一个产品列表 + 购物车的页面，只有购物车按钮需要 JS
- 一个文档页面 + 搜索栏的页面，只有搜索栏需要 JS
MPA + 岛屿：第三条路
Astro 选择了 MPA 作为基础模型（每个路由是一个独立页面），但在 MPA 之上叠加了岛屿架构。结果是：
- 保持 MPA 的简单、SEO 友好、快速首屏
- 获得 SPA 级别的交互体验（在需要的地方）
- 避免了全量水合的性能浪费
这本质上是一个性能默认值的设计选择——默认零 JS，需要时才加。
Astro 设计哲学
内容优先：Astro 是为内容型网站设计的，它的路由、布局、内容集合等都围绕"展示内容"优化。
自带框架（Bring Your Own Framework）：Astro 不绑定特定 UI 框架。你可以在同一个项目中使用 React、Vue、Svelte、Solid、Preact 甚至纯 HTML——各自作为独立的岛屿。
服务端渲染优先：Astro 默认在服务端渲染，输出纯 HTML。这与 SPA 框架的"客户端优先"形成对比。
零 JS 默认：除非你明确标记 client:load 等指令，否则 Astro 不会向浏览器发送任何 JavaScript。
Astro 不适合什么
认清边界同样重要：
- 需要复杂客户端状态管理的应用（如在线协作工具）
- 实时数据密集的仪表盘（如股票交易面板）
- 高度交互的单页应用（如 Figma）
这些场景更适合 Next.js、SvelteKit 等框架。
延伸阅读
- Astro 官方文档：Islands 架构
- Astro 官方文档：为什么选择 Astro
- Astro 官方文档：MPA vs SPA
- Islands Architecture — Jason Miller
实操清单
- 访问 astro.build 浏览官网
- 阅读 Islands 架构的官方文档
- 理解自己项目中有多少 JS 是不必要的
- 在脑海中区分哪些页面适合 MPA，哪些需要 SPA
created by:codex on deepseek v4 pro