Astro 适用场景：能做什么、不能做什么

学完前两章，你已经知道 Astro 是什么、为什么快。这一章换个角度：它到底能用在哪些地方？又有哪些活它干不好？

选框架最怕「跟风」。别人说快就上，结果项目越做越别扭。先把边界看清楚，后面才不踩坑。

Astro 最擅长的：内容站

Astro 从出生就是按「内容驱动网站」设计的。下面这几类，是它的舒适区：

1. 博客 / 个人网站：写文章、发笔记，Markdown 直接变成页面，配合内容集合管理得井井有条。
2. 文档站：技术文档、产品手册这类「以读为主」的站点，Astro 天生合适。
3. 企业官网 / 产品页：展示公司、介绍产品，几乎全是静态内容，SEO 权重高。
4. 营销落地页：活动页、推广页，追求打开速度和转化率，Astro 的零 JS 默认正中下怀。
5. 作品集 / 社区站：设计师、开发者秀作品，或论坛式的社区门户。
6. 电商内容页：商品展示、分类列表这类「展示多、变动少」的部分，用 Astro 很香。

借助岛屿，也能做轻交互

你可能会担心：全是静态，那我的网站是不是不能「动」了？

不会。群岛架构的精髓就是「默认静态，按需交互」。下面这些交互，Astro 完全能胜任：

• 顶部导航的下拉菜单（client:load）。
• 页面底部的评论区、图片轮播（client:visible）。
• 根据用户登录状态显示头像（服务端岛屿 server:defer）。
• 一个会算价格的交互式报价表（React / Vue 岛屿）。

也就是说：页面主体静态，少数地方「点几个岛屿」就能获得现代应用的交互感。这种「静为主、动为辅」的形态，覆盖了绝大多数网站。

哪些活 Astro 干着别扭

反过来，下面几类 Astro 不是不能做，但会越做越累：

1. 强实时协作：在线画板、多人同时编辑的表格、实时对战游戏。整页都在高频变化，用完整 SPA 更顺。
2. 重状态共享的后台：如果大量组件要实时共享同一份状态（比如一个复杂的仪表盘里到处联动），岛屿间的隔离反而成负担，得靠 Web API 手动打通。
3. 重度交易系统：实时库存、购物车、支付流程这类，通常需要一整套后端和 API，全栈框架更对口。

和 Next.js 摆一起看

提到建站框架，很多人会拿 Astro 和 Next.js 比。这里借用社区一份实测对比（来源：dev.to《Astro vs Next.js for static sites, a 2026 corporate website stack decision guide》），给你一个直观参照。注意：数据来自具体项目实测，不同项目会有出入，但趋势有代表性。

八个维度对比

维度	Astro	Next.js	胜方
构建速度	约 0.5–1 秒（12 页）	几秒到几十秒	Astro
产物体积	约 728 KB	约 2.3 MB	Astro
默认 SEO	零 JS 纯 HTML 输出	需额外配置	Astro
GEO 友好度	原生友好	需额外配置	Astro
交互能力	群岛架构	全栈	Next.js
维护成本	低（纯静态）	中（要养 Node 服务）	Astro
生态广度	中等	丰富	Next.js
学习曲线	低	中高	Astro

关键差异怎么理解

构建速度：Astro 默认把模板直接编译成 HTML，不跑整套 React 服务端渲染。项目小的时候，构建快到几乎无感。

SEO / GEO 友好：这是 Astro 最大的牌——默认输出就是干净纯 HTML，搜索引擎和 AI 摘要都好读。Next.js 默认会带一套运行时和脚本，想拿到同样干净的 HTML 得专门开 output: 'export'。

什么时候该选 Next.js：电商（实时库存、购物车、支付）、SaaS（登录、仪表盘、实时数据）、需要内置 API 路由的后台。这些场景下，Next.js 的全栈能力和丰富生态更顺手。

一个帮你做决定的树

把上面的判断浓缩成一棵「决策树」，建站前对照一下：

你的站点主要是？
├─ 内容展示型（官网、博客、文档）
│   └─ 选 Astro ✅
├─ 应用型（登录、实时数据、支付）
│   └─ 选 Next.js ✅
├─ 混合型（站点 + 博客 + 轻交互）
│   └─ Astro + 岛屿 ✅
└─ 电商型（商品列表、购物车、支付）
    └─ 选 Next.js ✅

社区那篇实测报告的结论也干脆：纯内容站、站点加博客、站点加轻交互，都推荐 Astro；电商 / SaaS 这类重后端、重实时的，推荐 Next.js。

混合场景：Astro 也能顶

值得强调的是，Astro 不是「只能做静态站」。借助岛屿，你的 Astro 站点可以：

• 嵌入 React / Vue 组件做局部交互；
• 用服务端岛屿做个性化内容；
• 开启按需渲染（output 设为 server 或 hybrid），让部分页面在服务端实时生成。

也就是说，即便你的项目是「官网 + 一点动态」，Astro 也能一手包办，不必硬拆成两个框架。

选错也不要紧：Astro 很“好退”

有人担心：万一选了 Astro，做到一半发现其实需要全栈能力，是不是得推倒重来？通常不至于。

Astro 的组件写法就是 HTML 的扩展，你写的 .astro 文件、Markdown 内容、CSS 样式，换框架时大多能复用或轻松迁移。真要加后端，你既可以开启按需渲染接 API，也能把 Astro 当成「前端层」去对接独立的后端服务。很多团队就是这么干的：内容站用 Astro，重业务逻辑另起一个服务。

一句话：先用 Astro 把「内容展示」这块稳稳做好，需要更多能力时再按需加，不必一开始就为用不上的复杂度买单。

小结

这一章帮你划了边界：

1. Astro 擅长：博客、文档、官网、营销页、作品集、电商内容页。
2. Astro 勉强：强实时协作、重状态共享后台、重度交易系统——这类更该用全栈框架。
3. 判断口诀：内容是主角用 Astro，交互是主角用全栈框架。
4. 混合项目里，Astro 靠岛屿和按需渲染也能顶住。

下一章起，我们动手前的准备：先把环境装好。