名词解释教学工作区 · 课程 0017 · 形态单概念 · 约 6 分钟 · 前置:0016 · 静态部署与其它部署 · 相关:0013 · 前端 / 后端 / 接口 · 2026-10-01

SSG:页面在发布之前就印好了

你能做到:面对一个页面,能说清它是什么时候做出来的 —— 发布之前(SSG)、每次请求时(SSR),还是浏览器里(CSR); 也能指出 SSG 与「把文件发出去」这一步各自管哪一段。

1 | 定义

SSG,全称 Static Site Generation(静态站点生成): 在构建时 build time 把内容与模板 template拼成一页一页的 HTML 文件,访客到来时交出去的是早就写好的文件,而不是当场算出来的结果;产物是一堆纯静态文件, 可以整包放到 CDN 上。像提前把整本书印好:读者来的时候只是取走一本,不是当场现写。代价也像印刷 —— 要改内容,得重新排一次版、再印一批,不能拿笔在已经发出去的书上改。

2 | 它解决什么麻烦

内容型站点(博客、文档、产品介绍页)有个共同点:内容很久才变一次,访客却天天来。现拼的做法,是把同一份内容为每一个人重算一遍。

① 算的是同一份东西。一篇文章发布之后就固定了,可每来一个访客都要再查一遍数据、再套一遍模板; 人一多,重复的活就成倍。
② 现拼要留一个进程一直守着。请求到来时才拼页面,占着服务进程与数据连接,高峰就得加机器; 而加的那台,可能只是在重复算同一份内容。
③ 全交给浏览器拼,首屏就得等。内容要等脚本下载、执行之后才出现;分享出去的链接, 对方常常只看到一个空壳,搜索引擎的爬虫来了也挑不出正文,收录跟着吃亏。
④ 多出来的一层要人维护。常驻进程要打补丁、看资源、防打挂;而「发文件」这件事, 几乎没有可维护的东西。

四条指向同一个做法:能提前做完的活,就在发布之前做完,访客到的时候只剩取件。

3 | 它怎么解决

内容 source Markdown 文件,或 headless CMS 里的条目 -> 模板 template 决定一页长什么样 -> 生成器 generator 在构建时跑的那一步 -> 产物 artifact 一页一个 .html,加样式、脚本、图片 -> 静态托管只把现成的文件发出去 -> 访客

① 内容与模板分开写。作者只写 Markdown,或在 headless CMS(只有内容后台和接口(API)、不带前台的建站系统)里填条目;页面长什么样由模板决定, 改版式不用碰正文。
② 生成发生在构建时,只跑一次。生成器(如 VitePress、Hugo、Astro、Eleventy)读完所有内容, 一页套一次模板,写成一个 HTML 文件;内容可以来自仓库里的文件,也可以在构建时现调接口取下来。
③ 产物是纯文件。样式、脚本、图片跟着页面落在同一个目录里,没有任何需要常驻运行的进程。
④ 交付交给静态托管或 CDN。上传一次,之后访客就近取件,服务器不做任何计算 —— 这一层只负责发文件,不管文件是怎么来的。
⑤ 页面里的交互,等脚本加载完再接上。这一步叫水合 hydration: 浏览器先把已经写死的内容画出来,再把事件接上去,按钮与表单才活过来。
⑥ 不想每次全量重印,就增量再生成。 ISR(Incremental Static Regeneration,增量静态再生成)让生成器只重建有变化的那几页, 其余沿用上一次的产物。

4 | 用它的代价

① 改一个字也要重新构建再发布。内容不在「后台点一下就生效」的路上:改完要跑一遍构建、把新产物传上去,访客那边还可能压着一份旧的。急改线上文案的时候,这条路比别人慢。
② 内容一多,构建时间就上来了。页面数量上去以后,一次全量生成可能几十分钟; 构建时间成了新的瓶颈,要靠增量再生成,或者把站点拆成几块分开建。
③ 个性化与实时数据做不了。构建那一刻不知道「你是谁」,也不该把每秒都在变的数据写死成文件; 想让页面因登录用户而不同,只能在页面加载之后用脚本再向接口取一次。
④ 构建这一步得有地方跑。生成器要先在一台机器上装好、能执行:有的自带运行环境, 就是一个可执行文件(如 Hugo),有的要先装一套 Node.js 运行环境(如 VitePress)。产物一旦生成,托管那一侧就再没有这个要求了。
⑤ 搜索、评论这类功能要另起一处。页面本身是写死的文件:全文搜索要么在构建时把索引一起生成,要么由页面上的脚本去问一个外部服务;评论区同理。

5 | 真实使用场景

场景一:把一批 Markdown 变成整站文件。

hugo new site my-docs   # 建一个站,内容目录里放的就是 Markdown
hugo                    # 构建:内容 + 模板 → 生成整站
# 产物落在 public/:public/index.html、public/guide/install/index.html …
# 换用 VitePress / Astro 时,命令是 vitepress build / astro build,道理一样

改完一篇 Markdown,再跑一遍构建、把新产物传上去,访客看到的就是新页面; 站点有多少页,产物里就有多少个对应的 .html 文件。

场景二:把产物交给托管平台。

# 把仓库连到 Cloudflare Pages / Netlify / GitHub Pages:
#   平台在远端跑一遍同样的构建,再把产物发到就近的节点
# 也可以本地 hugo 完,再把 public/ 整个传上去

两种做法的产物完全一样,差别只在构建跑在哪台机器上:本地跑是「先建好再发」, 平台跑是「推上去之后它替你建」——多半就挂在 CI/CD 上:推代码触发它构建,产物直接发到节点。

场景三:站里只有少数几页经常更新。

产品介绍页一年改两次,价格页每周改一次。让生成器只重建价格那几页(ISR / 增量再生成), 其余页面沿用上一次的产物;既不用每次全量重印,页面也不必退回「每次请求现拼」。

6 | 和相近的东西怎么分

先问一句:页面是在什么时候拼出来的?发布之前是 SSG,每个请求时是 SSR,浏览器里是 CSR。再问一句:这句话说的是生成,还是交付?

名词	它是什么	和 SSG 什么关系
静态托管	只负责把现成的文件发给访客,自己不生成页面	配套的一层:SSG 管生成,它管交付(0016 那一课讲的就是它)
预渲染(prerender)	更宽的说法:任何「提前把页面生成成 HTML」的做法	SSG 是它的一种;它的范围更大,可以只提前生成一部分页面,其余仍现拼
SSR(服务端渲染)	每个请求到来时,在服务器上把页面拼好再返回	换的是时机:SSG 发布前拼一次,它每来一个请求就拼一次,所以总能反映最新数据
CSR(客户端渲染)	先发一个空壳,内容由浏览器里的脚本拼出来	拼的动作挪进了浏览器;HTML 文件里没有正文,首屏与分享预览都要吃亏
ISR(增量静态再生成)	先把生成好的页面发出去,再在后台定期重建其中一部分	给 SSG 打的补丁:治的是「改一点就要全站重建」
headless CMS	只有内容后台和接口、不带前台的建站系统	一个内容来源:构建时把它的条目取下来,再交给生成器出页面
CDN	在许多地方放缓存,让访客就近取到文件	只是把交付送得更近;它不生成页面,也不知道页面是怎么来的

一句话分工:SSG 决定「什么时候生成」,静态托管决定「从哪里发出去」,SSR 与 CSR 是另外两种生成时机。

7 | 常见误解

① 「用 SSG 就是手写 HTML。」错在把产物当过程:页面是生成器用模板批量拼出来的, 内容与版式分开;真手写的话,改一个导航就要动所有页面。
② 「静态页面就没有交互。」错在把「内容是提前生成的」当成「页面不会动」:脚本照常加载, 水合之后按钮、表单、下拉都能用,只是这些交互不发生在服务器上。
③ 「SSG 站不能有评论和搜索。」错在把「页面是死的」推到整站:这两样要的是一个能存数据的地方, 页面上挂一个外部服务、或者自己起一个小接口就能有,只是它们不属于构建这一步。
④ 「SSG 就是静态部署。」错在把时机当成交付方式:前者说页面何时生成,后者说文件怎么交出去; 两者常常一起用,但可以分开谈 —— 现拼出来的页面同样能被缓存下来快速发出去。

8 | 练习

三题自测,每题只有一个正确选项;选完立刻看到解释。

1. SSG 这个名字,说的是页面在哪一步被拼出来?

对。SSG 的关键就在于把生成提到了发布之前:访客到来时只剩取件,服务器不做计算。

2. 把生成好的文件交给访客,是下面哪一步?

对。静态托管只管交付;文件是谁生成的、什么时候生成的,它不关心。

3. 一篇文章改了错别字,一个 SSG 站要做什么,访客才能看到?

对。内容变了,产物就得重做一份;这正是「提前生成」要付的那笔账,也是增量再生成想替你减轻的部分。