为内容优先与应用优先的 Web 产品选择合适的技术栈

当你选择一个 web 技术栈时，你不仅仅是在挑选一个框架。你是在锁定一种运营成本。

为一个内容型网站选择一个应用型技术栈，意味着在接下来的三年里，你将不得不与水合（hydration）bug 作斗争，处理复杂的缓存层，并为渲染一篇博客文章支付计算时间。为高度交互式的应用选择一个静态技术栈，意味着你将花费三年时间构建复杂的客户端状态变通方案，仅仅是为了保持界面的同步。

技术栈的选择是一个基于你的产品形态的架构决策，而不是一场人气竞赛。

选错技术栈的代价

Web 行业在过去的十年里一直试图构建一个能统治一切的工具。这种努力产生了令人难以置信的工程技术，但也产生了一个失败模式：用 F1 引擎来驱动高尔夫球车。

应用技术栈中的内容网站： 你用 Next.js 构建了一个文档网站。现在你需要维护一个 Node.js 服务器，管理复杂的构建管道，并承受沉重的 JavaScript 负载。读者的浏览器下载了 150KB 的 React 代码，仅仅是为了显示静态文本。这造成了运营拖累，并降低了在慢速网络上的用户体验。
静态技术栈中的应用： 你试图在一个静态站点生成器中构建一个协作仪表板。你必须发明自己的身份验证流程，通过 URL 传递所有状态，并手动管理复杂的数据获取，因为框架假设内容在构建时是固定的。

谱系：内容优先 vs 应用优先

在评估框架之前，请确定您的产品在谱系上的位置。

内容优先（文档重）

主要目标是阅读、学习或发现。

性质： 主要是只读。快速的首次内容绘制（FCP）和 SEO 至关重要。
交互： 稀疏且局部（例如，搜索栏、主题切换器）。
示例： 文档、营销网站、博客、出版物。
结构需求： 发送 HTML。除非必要，否则不要发送 JavaScript。

应用优先（应用重）

主要目标是执行、编辑或管理。

性质： 高度交互、需要身份验证、状态驱动。
交互： 普遍存在。整个屏幕都会响应用户输入。
示例： SaaS 仪表板、协作编辑器、复杂的电子商务结账系统。
结构需求： 发送应用程序。管理复杂的客户端-服务器状态。

技术栈决策树

不要猜测。遵循需求。

flowchart TD
    A[主要目的是什么？] -->|阅读与发现| B{SEO 关键吗？}
    A -->|交互与工作流| C{需要实时状态吗？}
    B -->|是| D[内容优先技术栈]
    B -->|否| D
    C -->|是| E[应用优先技术栈]
    C -->|否| F{交互是局部的吗？}
    F -->|是| D
    F -->|否| E

    D --> G[Astro, Eleventy, Hugo]
    E --> H[Next.js, Remix, Nuxt]

    classDef content fill:#e0f2fe,stroke:#2563eb,stroke-width:2px;
    classDef app fill:#fef08a,stroke:#d97706,stroke-width:2px;
    class G content;
    class H app;

框架如何映射到谱系上

何时选择 Astro（内容优先的领导者）

Astro 专为内容而设计。它默认渲染为静态 HTML，仅为标记为交互式的特定组件发送 JavaScript（这种方法称为群岛架构）。

你得到了什么： 开箱即用的近乎完美的性能，零 JS 基线，原生的 markdown/内容集合支持。
代价： 如果你的页面 90% 变成了交互式群岛，你就在管理一个复杂的群岛，这时候你可能更应该使用一个应用框架。

何时选择 Next.js（应用优先的标准）

Next.js 专为应用程序设计。它提供了一个全栈环境，集成了路由、数据获取和多种渲染策略（SSR、CSR、SSG）。

你得到了什么： 针对复杂状态的统一心智模型，用于数据获取的服务器组件，以及为 SaaS 和动态产品构建的生态系统。
代价： 更高的运营复杂性，强制的水合作用（消耗 CPU 时间），以及运行 Node 服务器的开销。

实例分析

场景 1：SaaS 营销网站

产品： 一个包含 20 个页面的 B2B 产品营销网站。它有定价页面、博客和几个交互式计算器。 错误： 为了“保持一致性”，将其与主应用程序建在同一个 Next.js 仓库中。营销团队现在受到应用部署周期的阻碍。 解决方案： 用 Astro 构建营销网站。它可以瞬间部署到 CDN，为了 SEO 瞬间加载，并且计算器可以构建为 React 群岛。

场景 2：电子商务仪表板

产品： 供仓库管理员更新库存和处理退款的内部仪表板。 错误： 使用静态站点生成器并严重依赖客户端数据获取，导致了地狱般的加载动画和混乱的身份验证流程。 解决方案： 用 Next.js 或 Remix 构建它。在页面加载前使用服务器端渲染检查身份验证并获取数据。整个屏幕都是一个应用程序；像对待应用程序一样对待它。

场景 3：混合型企业平台

产品： 一份需要用户账户、付费墙和个性化阅读列表的大型出版物。 解决方案： 这是一个边缘情况。你可以使用带有强大边缘缓存的 Next.js，或者使用启用 SSR 和独立后端服务的 Astro。这里的决定主要取决于团队的专业知识，而不仅仅是产品形态。