🧱 Jamstack

一句话定性

Jamstack 把架构反过来了:先把页面预构建成静态文件扔到 CDN(快、便宜、安全),动态能力交给客户端 JS 调 API 去补。 它是 CDN与静态托管能力的”架构化”——一套以”静态优先”为信条的方法论。但信条太纯粹,反而逼着动态能力以 Serverless与FaaS 和 Edge边缘运行时的形态回归。

一、它是什么 & 出现的时代

Jamstack(早期写作 JAMstack)由 Netlify 在约 2015 年提出并大力布道。名字是三个核心要素的首字母:

JavaScript:运行在客户端的 JS,负责所有动态交互。
API:所有服务端能力(数据、支付、搜索…)抽象成可复用的 HTTP API,通过 JS 调用(可以是自建的,也可以是第三方 SaaS)。
Markup:预先构建好的标记/HTML,在构建时生成,部署到 CDN。

它属于 2018-2023 工程化时代的方法论产物,与 SSG(见渲染模式演进史)、静态托管平台、Git 工作流共同成熟。

Jamstack 不是某个框架,而是一种"解耦"哲学

它的核心主张是:把”前端展示”与”后端逻辑”彻底解耦。前端是预构建的静态产物(部署即终态),后端缩小成一组 API。两者各自独立演进、独立部署。这与传统”前后端耦合在一个服务器进程里现拼页面”的模式根本对立。

二、为什么会出现(解决上一代什么痛点)

它要终结的,是**“动态服务器渲染一切”**这种传统架构(PHP/Rails/传统 SSR)的弊病:

传统"服务器现拼页面"架构的痛点

慢:每个请求都要现连数据库、现拼 HTML,TTFB 高,还无法被 CDN 缓存(因为每次结果可能不同)。

不安全:Web 服务器 + 数据库长期暴露在公网,攻击面巨大(SQL 注入、服务器被入侵、插件漏洞——WordPress 的血泪史)。

难扩展:流量一涨就要加服务器、调数据库连接池、做负载均衡,运维沉重。

运维重:要管服务器、打补丁、防宕机。

Jamstack 的反向思考(Inversion)很彻底:如果页面在构建时就生成好、永远是静态文件,那么——它本身就没有运行时服务器可被攻击,可以被 CDN 无限缓存,流量再大也只是多分发几份文件。 把”运行时计算”提前到”构建时”,一举消解了上面四个痛点。

三、核心机制 & 为什么流行

工作流

开发者 git push
   │
   ▼
平台(Netlify/Vercel)拉代码 → 跑构建(SSG)→ 产出静态 HTML/JS/CSS
   │
   ▼
产物自动分发到全球 CDN(见 [[CDN与静态托管]])
   │
用户访问 ──► CDN 边缘直出静态页(毫秒级)
   │
页面里的 JS ──► 调用 API(自建 Serverless / 第三方 SaaS)──► 补足动态数据

为什么火:四个硬优势

维度	Jamstack 为什么强
性能	预构建 + CDN 边缘直出,TTFB 极低,无运行时渲染等待
安全	没有常驻 Web 服务器和数据库直连,攻击面骤减
可扩展	静态文件分发天然无限横向扩展,流量洪峰=多发几份文件
成本/运维	无服务器要管,CDN 分发极廉价,部署即终态

Netlify 与 Vercel 的崛起

Jamstack 的爆发与两家平台深度绑定:

Netlify(创造了 Jamstack 这个词):把”连 Git 仓库 → 自动构建 → 全球 CDN 分发 + 原子部署 + 即时回滚”做成开箱体验,还提供 Netlify Functions(底层是 Serverless与FaaS)来补 API 能力。

Vercel(前身 ZEIT / Now):围绕 Next.js 把这套体验做到极致,成为前端部署的事实标杆之一。

这两家平台把 CDN与静态托管、构建、Serverless API 缝合成”一次 push 全搞定”的工作流,让前端工程师第一次能独立完成”全栈级部署”而不碰运维。

四、带来的新问题 / 副作用

"纯静态"信条遇到"高度动态"现实

高度动态内容难处理:个性化首页、登录后视图、实时库存/价格、用户生成内容(UGC)——这些东西无法在构建时预生成,纯静态做不了。

构建时间随内容爆炸:一个十万页的电商,每次内容变更理论上要重新构建十万页,构建以小时计(SSG 的老毛病,见渲染模式演进史)。

“全靠客户端 JS 调 API”又把 SPA 的病带回来了:首屏要等 JS 跑起来调 API 才有数据,白屏、SEO、瀑布流请求(waterfall)又冒头。

内容新鲜度滞后:改个东西要等下一次构建+部署才生效。

核心矛盾浮现:Jamstack 用”把一切提前到构建时”换来了快和安全,但这恰恰让它无力应对”必须在请求时才能决定”的动态/个性化内容。

五、为什么会衰落 / 现状

不是衰落,而是"动态能力的回归"把它重新定义了

Jamstack 的纯静态信条太理想化。现实倒逼出一连串”让动态回来”的补丁,而这些补丁恰恰构成了今天的前沿:

ISR(增量静态再生,见渲染模式演进史):静态为主 + 按需后台再生单页,解决”全量重建”和”新鲜度”问题。

SSR 的回归:高度动态页面干脆回到请求时渲染——但这就需要服务器或函数。

Serverless与FaaS:用按需函数提供 API 和 SSR 能力,补上 Jamstack 缺的”运行时计算”。

Edge边缘运行时:把那点动态计算下沉到 CDN 边缘节点,做到”动态内容也能像静态一样快”。

所以业界后来更爱用宽泛的词——“现代 Web 架构 / 全栈框架”——来描述这种”静态打底 + 动态按需补足”的混合形态。Jamstack 没有消失,它进化成了混合渲染,纯静态只是其中一档。

纯 Jamstack(全静态 + 客户端调 API)
   │ 高度动态/个性化做不了,首屏又退回 SPA 的病
   ▼
静态打底 + 按需动态(ISR / SSR / Serverless / Edge 混合)

六、对后续技术的影响(因果链)

传统"服务器现拼页面"(慢 / 不安全 / 难扩展 / 运维重)
   │ 反向思考:把运行时计算提前到构建时(Inversion)
   ▼
Jamstack(预构建静态 + CDN 分发 + 客户端 JS 调 API)   ◄── Netlify @ ~2015
   │ Netlify / Vercel 把"push 即全球部署"做成工作流
   │
   ├──► 性能/安全/扩展/低运维 ── 一举拿下
   │
   └──► 但"纯静态"应付不了高度动态 / 个性化 / 海量页面
            │
            ├──► ISR / SSR 回归(见 [[渲染模式演进史]])
            ├──► [[Serverless与FaaS]](按需函数补 API 与 SSR)
            └──► [[Edge边缘运行时]](动态计算下沉到边缘,贴近用户)
                     │
                     ▼
              "静态打底 + 动态按需"的混合架构成为今天的常态

历史地位

Jamstack 是部署演进史上一次彻底的”反向操作”:它不去优化服务器,而是干脆取消运行时服务器,把渲染提前、把后端拆成 API、把分发交给 CDN与静态托管。这套思路换来了性能、安全、可扩展和零运维的巨大红利,也催熟了 Netlify / Vercel 这样的现代部署平台。但它的纯粹主义撞上了”动态内容”的硬墙——而正是为了翻越这堵墙,前端把 Serverless与FaaS 和 Edge边缘运行时请了回来。Jamstack 既是一座高峰,也是通往”边缘动态”的台阶。

前端技术演化史

探索

Jamstack

🧱 Jamstack

一、它是什么 & 出现的时代

二、为什么会出现(解决上一代什么痛点)

三、核心机制 & 为什么流行

工作流

为什么火:四个硬优势

四、带来的新问题 / 副作用

五、为什么会衰落 / 现状

六、对后续技术的影响(因果链)

关系图谱

目录

反向链接