每隔几年，Web 就会重新发明一次轮子，然后想起来轮子本来就挺好用。眼下这个轮子 是一堆 HTML 文件，它的名字叫静态站点生成器。我就是用这套模型在构建和运行一个 会发布它自己的双语博客，所以我有些立场。 静态站点不是怀旧，也不是妥协——对于 2026 年的内容站点来说，它就是正确的默认 选项，谁要伸手去够一台服务器，举证责任在谁。但「默认静态」不等于「处处静态」， 而那些诚实的限制比营销话术重要得多。
下面讲这条弧线、这套工具箱，以及我会让你在哪里停下。
那条弧线：静态 → 动态 CMS → 又是静态
最早的 Web 是被动静态的。你手写 HTML，用 FTP 传上去，工作就完成了。它撑不起 编辑团队和成千上万的页面，于是动态 CMS 把它吃掉了：WordPress、Drupal、Joomla。 一个数据库、一个 PHP 运行时、一层主题、一个插件生态。此后十年，这就是发布的 正道，而且对非技术的编辑来说至今如此——对内容团队而言，没什么能取代 WordPress 的后台。
然后轮子又回来了。2016–2019 年前后的 JAMstack（JavaScript、APIs、Markup） 说法是：在构建期预渲染页面，从 CDN 提供，把动态部分推给 API 或构建步骤。 Gatsby，然后 Next.js，然后 Astro 和 Hugo，让它变得体面。它的卖点从来不是 「因为我们怀旧所以静态」，而是「因为产物就是一摞文件，而文件是你能服务出去的最便宜、 最快、最安全的东西」。
关键的转变在于数据工作发生在哪里。它没有消失——它从请求时挪到了构建时。这就是 全部的诀窍。一个过去每次请求都要查数据库的页面，现在只需要在构建时查一次，结果 被烤进 HTML 里。
静态站点为什么会回来
五股力量，大致按它们在争论中真正拍板的频率排序。
CDN 让「静态」等于「全球且瞬时」
一摞文件在边缘缓存起来毫不费力。没有要预热的源站，没有冷启动，没有会耗尽的
数据库连接池。你可以把静态站点放到任何 CDN 上，或者放到一台 nginx 后面、靠
Cache-Control 干活的小 VPS 上，就能在全球拿到低于 100ms 的响应。动态渲染得
为了这个拼命；静态则是白拿，因为最难的部分在建构建时就已经做完了。
Core Web Vitals 和 SEO 把速度变成了排名输入
Google 把页面体验变成了排名信号，Core Web Vitals 成了记分牌。零 JavaScript
或极少 JavaScript 的静态 HTML，天然就更容易赢下 LCP、CLS 和 INP——能出错的
东西本来就少。如果你的流量来自自然搜索，这就不是虚荣，而是产品本身。这也是为什么
这个博客把 SEO 当作构建产物而不是马后炮：
标题、canonical、hreflang、sitemap 和 JSON-LD 都是逐页生成的，你想漏也漏不掉。
成本塌缩了
一个静态站点可以只花一个域名和一台小机器的钱。在慷慨的免费额度上甚至可以白嫖。 没有应用服务器，没有托管数据库，没有被爬虫在凌晨三点按请求计费的计算。对于一个 内容站点来说，这笔账毫无悬念。
攻击面缩到了几乎为零
你无法利用一个根本不存在的请求处理器。没有 PHP，没有插件，没有后台登录，没有
?id= 参数可注入。2026 年，内容站点被攻陷最常见的方式仍然是一个有漏洞的 CMS 插件——
而静态站点压根没有这一类 bug。更少的活动部件，更少的 CVE。我写过一篇不用 Docker
的自托管，理由一样：你不运行的东西，
就不会倒。
「没有服务器可供倒下」这一性质
这一点被低估了。动态应用有一份你得去防守的可用性：进程守护、内存泄漏、重启、 凌晨两点的告警电话。nginx 后面的静态站点就是一摞文件。nginx 活着，站点就活着。 就算构建机挂了，已经部署好的站点照常服务。把构建和对外服务解耦，是一种可靠性 属性，而不只是一个架构选择。
现代静态站点生成器工具箱
静态站点生成器这个市场已经收敛成三个诚实的答案，这对所有人都是好事。
- Astro——内容优先，islands 架构，默认零 JS，只有你要求的地方才加交互。 当你想要带类型的内容集合、组件化模板，并且有一条在不必重构的前提下加入几个交互 岛的道路时，它最好用。
- Hugo——单个 Go 二进制，构建快得离谱，没有运行时依赖。当构建耗时就是 约束，或者你想完全避开 Node 工具链时，它最好用。
- Eleventy（11ty）——极简、不带立场、不绑定模板语言。当你想只要有 HTML、 Markdown 加一点数据，而不想要任何强加于你的东西时，它最好用。
Astro vs Hugo（以及 Eleventy）一览
| Astro | Hugo | Eleventy | |
|---|---|---|---|
| 语言 / 运行时 | JS/TS (Node) | Go（单二进制） | JS (Node) |
| 构建速度（1 万页） | 中等 | 极快 | 快 |
| 默认输出的 JS | 无 | 无 | 无 |
| 组件 / islands | 一等公民 | 部分（shortcode） | 需插件 |
| 最合适的场景 | 内容 + 少量交互 | 超大站点、CI 要快 | 极简、无主张 |
| 学习曲线 | 低到中 | 低（但 Go 模板） | 低 |
我自己的规则：当规模下的构建耗时成为瓶颈时用 Hugo；当站点是内容但页面想用真正 的组件时用 Astro；当你想贴着纯 HTML 和数据走时用 Eleventy。三者产出完全 一致——一摞文件——所以它们之间迁移的成本主要在模板，而不在架构。
一个最小的静态构建，无聊到就是这个样子：
# 一个静态站点生成器完整的「部署」故事，大致如此：
npm ci
npm run build # 在构建期把每个页面渲染到 ./dist
rsync -a --delete ./dist/ /var/www/site/ # 近似原子地替换，由 nginx 服务这条流水线里没有应用服务器。这正是重点。
诚实的限制
我不会假装静态没有代价。下面这些是真的，也是人们从它身上弹开的原因。
- 没有 JavaScript 或边缘，就没有按用户的状态。 登录后的仪表盘、购物车、 个性化信息流——除非你加上客户端 JS 或边缘函数，否则页面无法随访客而变。 预渲染的意思就是所有人共用一份输出。
- 规模下的构建耗时。 一万页没问题；二十万页再加吃力的图片处理，就是一次跑很久 的构建，以及一个你必须打理的「提交到上线」延迟。增量构建能帮忙，但抹不掉这个问题。
- 评论、表单和搜索都得外挂。 静态评论意味着第三方（或你自己的 API），表单意味着 一个外部端点，搜索意味着预建索引（Pagefind、Lunr）或一个托管服务。每一块都不大， 但每一个都成了你要背的依赖。
- 内容预览和「立即发布」丢了那个按钮。 非技术编辑对此感受最深。一个 CMS 或基于 git 的编辑器（Decap、Sveltia）能补上差距，但那是你要额外搭的脚手架。
如果这些都不伤你的项目，静态便默认胜出。如果其中某一条是你的核心功能，那静态 就是用错了工具。
什么时候真的需要动态
静态是默认，不是宗教。当需求确实动态时，就该伸手去够服务器——SSR、真正的应用、 数据库：
- 需要鉴权的应用。 任何登录之后有按用户数据的东西：仪表盘、管理工具、SaaS。 鉴权就是状态，状态需要运行时。
- 实时交互。 聊天、协作、实时看板、多人游戏。WebSocket 和订阅从定义上就是 服务器。
- 重度个性化。 推荐、信息流、按访客在请求时决定的定价或内容。你可以在边缘 伪造它，但过了一个点，你只是在用多余的步骤搭一台服务器。
- 频繁变动的共享状态。 库存、预订，任何两个人此刻必须看到同一个数字的东西。
注意上面没有什么：博客、文档、营销站、作品集、大多数落地页。这些是内容站点， 而大多数内容站点并不需要服务器。
SSG vs SSR 是个错误的问题——该问「这个页面到底需要什么？」
SSG vs SSR 的争论常常被摆成一场宗教战争，而它本不该如此。正确的问题更小： 这个页面的 HTML 取决于谁在问，还是取决于什么时候问吗？
- 如果答案是否——对所有人都一样的内容——就预渲染它。那就是 SSG，是你能服务出去的 最便宜的东西。
- 如果答案是是——页面必须随用户或随秒变化——你就需要一个运行时。那就是 SSR 或 客户端应用，那也没问题。
大多数站点是混合的，而现代的答案就是把它们混起来：预渲染内容，只给那个需要状态的 小部件做水合。Astro 的 islands 正是为此而生。但只有在某个页面挣得了这份待遇时， 才去够这个混合方案。
选择满足需求的最简方案
我见过最多的错误，不是在静态和动态之间选错，而是为了服务一个每周才变一次的页面 去选一套分布式系统。为博客上 Kubernetes 不是炫技，而是你此后要运维的一份负债。
所以我的规则一点也不光鲜：选择满足需求的最简方案，而大多数内容站点并不需要 服务器。 从一个静态站点生成器开始。从 CDN 或一台小 nginx 上服务文件。只有当某个 功能真的需要一个 API 时才加上它。把每一台服务器都当成一句承诺——承诺你凌晨三点 还得让它活着。
静态之所以回来，因为它是能搞定最大一类站点的最小东西。这不是趋势，它只是正确答案， 而整个行业花了十五年、三代框架才重新想起来。