Astro 系列（四）：内容驱动还是应用驱动——Astro 的边界
Astro 入门与实战 系列导航
网站谱系：从纯内容到纯应用
所有网站都落在一条谱系上：
纯内容 ←————————————————————→ 纯应用
博客 文档 电商 仪表盘 SaaS 在线编辑器
内容驱动的站点以展示信息为主，交互是点缀。应用驱动的站点以交互为核心，内容是交互的载体。
这个区分不是二元的，而是连续的。关键是你的站点在谱系上的位置。
内容驱动站点：Astro 的舒适区
以下场景是 Astro 的最佳匹配：
博客和个人网站：文章是核心，评论区或搜索栏是点缀。这是 Astro 最典型的用例，也是它的设计起点。
文档和知识库：大量的 Markdown 内容，结构化的导航，少量的搜索交互。Astro 的 Starlight 主题就是为此而生。
营销和落地页：视觉丰富的静态页面，需要 SEO、快速加载、动画效果。不需要复杂交互。
电商目录：产品列表、详情页是内容展示，加入购物车是少量交互。大量电商站其实是"带购物按钮的内容站"。
这些场景的共同特征：内容量 > 交互量，SEO 重要，页面结构清晰。
应用驱动站点：Astro 的边界
以下场景不适合 Astro 作为主框架：
后台管理系统：表格、表单、过滤器、实时通知——几乎每个 UI 元素都需要交互。全量水合是合理的选择。
SaaS 产品：复杂状态管理、用户认证流、权限控制、实时更新。这些需要客户端状态管理方案。
实时协作工具：同页面多用户操作、WebSocket 连接、冲突解决。岛屿架构的隔离性在这里是劣势。
社交平台：动态 feed、即时消息、复杂的交互链。内容由用户实时生成，不是预渲染的。
这些场景更适合 Next.js App Router、SvelteKit 或 Remix。
灰色地带：混合方案
很多项目不纯粹属于某一端。以下是可以在 Astro 中实现的混合策略：
Astro 作为壳 + SPA 子应用：营销页面、博客、文档用 Astro，后台管理用嵌入的 React SPA。两者共享样式、认证、API。
渐进式架构迁移：从纯 Astro 站点开始，当某个页面需要更多交互时，逐步引入岛屿组件。不需要一次性选定架构。
微前端拆解：用 Astro 做整体站点编排，各功能模块作为独立岛屿加载。适合大团队并行开发。
决策框架
选择 Astro 还是全栈框架，可以用这三个问题判断：
- 页面上多少元素需要响应式交互？ — 如果大部分是静态展示，选 Astro。
- 不同页面之间需要共享多少客户端状态？ — 如果很少或没有，选 Astro。
- 应用的主要价值来自内容还是功能？ — 如果来自内容，选 Astro。
如果你对任何一个问题犹豫，大概率 Astro 就够了。
延伸阅读
实操清单
- 把自己的项目放在内容驱动 ↔ 应用驱动的谱系上定位
- 列出项目中哪些页面是内容型、哪些是应用型
- 如果项目混合了两种类型，考虑是否可以用 Astro + 岛屿的混合方案
created by:codex on deepseek v4 pro