🚀 部署与托管演进史

一句话定性

“怎么把前端送到用户面前?”——这条线索有一个贯穿始终的主旋律:算力的位置一路向用户靠近。 从中心化服务器(代码跑在远方机房)→ CDN(静态产物缓存到边缘)→ Jamstack(预构建静态 + API)→ Serverless(按需函数)→ Edge(代码跑在离用户最近的节点)。延迟与个性化这对老对手,在算力的步步逼近中被逐步和解。

〇、一张图看懂整条主线

 算力离用户:  远(中心机房) ◄────────────────────────────────► 近(用户身边)

 自建服务器/FTP  ●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━●  代码在远方机房现渲染、现拼页
        │ 痛点:延迟由距离决定、单点瓶颈、运维沉重
        ▼
 CDN          ●━━━━━━━━━━━━━━━━━━━━━━━━━●  静态产物缓存到全球边缘,就近分发
        │ 痛点:只会缓存"对所有人一样"的静态,不会算 → 个性化/动态无解
        ▼
 Jamstack     ●━━━━━━━━━━━━━━━●  预构建静态扔 CDN + 客户端 JS 调 API
        │ 痛点:纯静态应付不了高度动态/个性化,API 还得有人提供
        ▼
 Serverless   ●━━━━━━━━●  按需函数补足动态:写后端却不碰服务器
        │ 痛点:cold start + 供应商锁定 + 跑在固定区域(离远方用户仍远)
        ▼
 Edge         ●━━━●  函数跑进最近的边缘节点,毫秒冷启动
                    (动态内容也能像静态一样快 —— 算力逼到"最后一跳")

看懂这张图的关键

这不是”换了几种部署工具”,而是同一个矛盾被反复施压、节节后退:用户要”既快又个性化”,而”快=离用户近+少计算”,“个性化=必须现场计算”。每一代技术都在这条战线上把算力往用户那头挪一点——直到 Edge 把”会算的函数”直接放进离用户最近的节点,矛盾才被基本化解。

与渲染模式深度纠缠

部署/托管和渲染模式演进史是一枚硬币的两面:

SSR 需要服务器(现渲染)→ 离不开运行时计算 → 推动 Serverless / Edge。

SSG 产物是纯静态→ 天生适合 CDN → 是 Jamstack 的技术基础。

Edge SSR / RSC 是”边缘 × 服务端组件”的新组合,是当前前沿。

一句话:“在哪渲染”决定了”能托管在哪、离用户多近”。 读这篇请务必对照渲染模式演进史。

一、自建服务器 / FTP —— 起点:代码跑在远方机房

最早的部署就是字面意义的”上传”——把文件 FTP / rsync 到一台自己买/租的服务器,Web 服务器(Apache/Nginx + PHP/JSP)在请求来时现拼页面返回。对应 2005-2013 Ajax时代及更早。

怎么工作:一台(组)中心化服务器,既托管文件又执行渲染逻辑,所有用户的请求都打向它。
副作用 / 催生下一代:
Warning
1. 延迟由距离决定:用户离机房越远越慢,光速是上限,优化代码也救不了。
2. 单点瓶颈:流量高峰直接打垮源站;扩容靠手工加机器。
3. 运维沉重:打补丁、防宕机、保活,全是与业务无关的负担。
“既然延迟由距离决定,那就把内容搬近用户”——这个第一性原理直接催生了 CDN。

二、CDN —— 第一步靠近:静态产物缓存到边缘

CDN(内容分发网络) 把已经生成好的静态资源缓存到全球边缘节点,用户就近取货。详见 CDN与静态托管。

怎么工作:不改变”在哪渲染”,只优化”分发”——把静态 JS/CSS/HTML 复制到离用户最近的节点。
为什么成标配:2013-2018 SPA时代的 SPA 产物、SSG 的预渲染页面全是静态文件,天然适合往 CDN 上一扔。静态托管平台(GitHub Pages → Netlify)让”部署”从运维活变成开发工作流。
副作用 / 催生下一代:

不会执行逻辑。一旦内容要因人而异(登录态、个性化、地区定价),它就无能为力。这道"静态 vs 个性化"的墙,贯穿后面整段历史,直到 Edge 才被推倒。

CDN 只会缓存”对所有人都一样”的静态内容,

三、Jamstack —— 架构化的”静态优先”

Jamstack(Netlify 约 2015 提出)把架构反过来:预构建静态(Markup)扔 CDN + 客户端 JavaScript 调 API。详见 Jamstack。

怎么工作:构建时把页面渲染成静态 HTML(SSG),部署到 CDN;动态能力交给客户端 JS 去调 API 补足。
为什么火:性能(CDN 直出)、安全(无常驻服务器可攻击)、可扩展(静态无限分发)、低运维。**Netlify / Vercel(前身 ZEIT/Now)**把”push 即全球部署”做成开箱工作流。
副作用 / 催生下一代:

高度动态 / 个性化 / 海量页面;"全靠客户端调 API"又把 SPA 的首屏白屏、SEO、瀑布流请求带了回来。而那个"A(API)"总得有人提供。这逼出了两条回归之路:ISR/SSR 的回归(见渲染模式演进史),和 Serverless 来提供 API。

纯静态应付不了

四、Serverless / FaaS —— 用按需函数补足动态

Serverless / FaaS(AWS Lambda 2014 开创)把”运行时计算”从常驻服务器,变成按需触发、用完即走、按用量计费的函数。详见 Serverless与FaaS。

怎么工作:开发者只写函数,平台负责何时跑、跑几个、何时回收。没请求时缩到零(零成本),来请求才拉起,流量大就自动并发。
为什么前端拥抱:全栈前端想写后端却不想管服务器——Serverless 让他们 git push 就上线一个 API。它正好补上 Jamstack 缺的”A”;元框架的 API Routes / Server Actions / SSR(见渲染模式演进史)底层都跑在它上面,与 Node.js 生态深度结合。
副作用 / 催生下一代:
Warning
1. cold start(冷启动):闲置后第一个请求要等实例拉起,几十毫秒到数秒——对 SSR 首屏很伤。
2. 供应商锁定 + 本地调试难。
3. 跑在固定区域:函数仍在某个数据中心,给地球另一端的用户做 SSR,网络往返还是远。
“能不能更快冷启动、还跑在离用户最近的节点?”——这把算力推向了 Edge。

五、Edge —— 算力逼到”最后一跳”

Edge 边缘运行时(Cloudflare Workers 2017、Vercel Edge、Deno Deploy)让代码跑在全球边缘节点,用 V8 isolate 做到毫秒级冷启动。详见 Edge边缘运行时。

怎么工作:把”会算的函数”塞进离用户最近的 CDN 节点;V8 isolate 让启动开销几乎为零。
为什么是当前前沿:
Success
- Edge Middleware:请求落地前就近鉴权、路由、灰度。
- Edge SSR:服务端渲染下沉到边缘,首屏又快又能个性化。
- 个性化 + 低延迟兼得:第一次同时满足”动态”和”快”——让动态内容也能像静态一样快,推倒了 CDN 那道”静态 vs 个性化”的墙。
受限:运行时是 Web 标准子集而非完整 Node.js(没有 fs 等),资源上限严,“算力近了、数据还在中心”是新矛盾。

Deno / Bun "以 Web 标准 API 为一等公民"的设计远见——运行时向 Web 标准收敛,与部署向边缘收敛,是同一股潮流的两面。 Edge 与 React RSC 的结合(渲染下沉到组件 × 执行下沉到边缘)是近年最热的前沿。

Edge 的”Web 标准子集”运行时,恰好印证了

六、托管平台的角色:把这条主线”缝合”成工作流

上面是技术原语,而开发者真正接触的是平台——它们把 CDN、构建、Serverless、Edge 缝成”一次 push 全搞定”:

平台	把哪几层缝在了一起	角色
Netlify	静态托管 + CDN + Functions(Serverless)	创造 Jamstack 一词,把”连 Git→构建→全球分发”做成标准
Vercel(原 ZEIT/Now)	CDN + Serverless + Edge + 元框架(Next.js)	围绕 Next.js 把渲染/部署体验做到事实标杆
Cloudflare	CDN + Workers(Edge)+ 边缘存储	Edge 运行时的开创者,算力最贴近用户的一极
AWS Lambda	区域型 Serverless/FaaS	FaaS 品类的开创者,重计算与完整 Node 的地盘

关键洞察

这些平台的竞争力,本质是”替开发者隐藏了算力位置的复杂度”:你只管写代码、git push,平台决定哪段走 CDN 静态、哪段走 Serverless、哪段下沉到 Edge。部署演进的终局,和渲染模式演进史一样,不是”谁取代谁”,而是”全都要,按路由/按组件自由分档”。

七、全景因果链

 自建服务器 / FTP(代码在远方机房现渲染)
   │ 延迟由距离决定 + 单点瓶颈 + 运维重
   ▼
 CDN(静态产物缓存到边缘,就近分发)              ◄── [[CDN与静态托管]] @ [[2013-2018 SPA时代]]
   │ 只会缓存"对所有人一样"的静态,不会算
   ▼
 Jamstack(预构建静态 + 客户端调 API)            ◄── [[Jamstack]] Netlify ~2015
   │ 纯静态应付不了动态/个性化;API 总得有人提供
   ▼
 Serverless / FaaS(按需函数补动态,零运维)       ◄── [[Serverless与FaaS]] AWS Lambda 2014
   │ cold start + 锁定 + 跑在固定区域(离远方用户仍远)
   ▼
 Edge(函数跑进最近的边缘节点,毫秒冷启动)         ◄── [[Edge边缘运行时]] Cloudflare Workers 2017
   │ 个性化 + 低延迟兼得 ──► 动态内容也能像静态一样快
   ▼
 与渲染模式(Edge SSR / RSC)、运行时([[Deno]]/[[Bun]] 的 Web 标准设计)合流
   ──► 全栈 + 边缘成为未来主方向之一([[未来5到10年前端发展方向]])

📊 主线因果图

这张图聚焦:每一代因为上一代的什么痛点而出现,以及它与渲染/运行时如何纠缠

flowchart TD
    origin["自建服务器 / FTP<br/>(远方机房现渲染)"]
    cdn["CDN<br/>(静态产物缓存到边缘)"]
    jam["Jamstack<br/>(预构建静态 + 客户端调 API)"]
    sls["Serverless / FaaS<br/>(按需函数, 零运维)"]
    edge["Edge 边缘运行时<br/>(函数跑进最近节点, 毫秒冷启动)"]

    render["渲染模式<br/>(SSR 需服务器 / SSG 适合 CDN)"]
    rsc["Edge SSR + RSC<br/>(渲染下沉到组件 × 执行下沉到边缘)"]
    rt["Deno / Bun<br/>(Web 标准 API 设计)"]

    origin -->|"延迟由距离决定 + 单点 + 运维重"| cdn
    cdn -->|"只缓存静态, 不会算 → 个性化无解"| jam
    jam -->|"纯静态应付不了动态; API 得有人提供"| sls
    sls -->|"cold start + 锁定 + 跑在固定区域"| edge

    render -.->|"SSG 产物纯静态, 天然适合"| cdn
    render -.->|"SSR 要现渲染, 需运行时计算"| sls
    edge -->|"个性化 + 低延迟兼得"| rsc
    render -.->|"RSC 组件级服务端渲染"| rsc
    rt -.->|"运行时向 Web 标准收敛, 正契合 Edge"| edge

    edge -.->|"全栈 + 边缘 = 未来主方向之一"| future["未来方向"]

    classDef next fill:#eceff1,stroke:#607d8b,stroke-dasharray:4 3;
    class future,rsc next;

历史地位

部署与托管演进史,是一条比渲染模式演进史更”物理”的主线:它讲的不是 HTML 在哪生成,而是算力本身在地理上离用户多近。从远方机房到 CDN 边缘缓存,再到边缘函数,每一代都把计算往用户那头挪一截,只为化解那个永恒矛盾——用户既要”快”(离我近、别让我等),又要”个性化”(内容得为我现算)。CDN 用缓存换来了快却丢了个性化,Serverless 用按需函数找回了动态却带来了冷启动和距离,而 Edge 把”会算的函数”放进最近的节点,第一次让”动态内容也能像静态一样快”。理解这条主线,就理解了为什么今天的前端可以”既不碰服务器、又能全球毫秒级地伺候每一个用户”——而它与渲染、与运行时的合流,正指向未来5到10年前端发展方向里”全栈 + 边缘”的未来。

前端技术演化史

探索

部署与托管演进史

🚀 部署与托管演进史

〇、一张图看懂整条主线

一、自建服务器 / FTP —— 起点:代码跑在远方机房

二、CDN —— 第一步靠近:静态产物缓存到边缘

三、Jamstack —— 架构化的”静态优先”

四、Serverless / FaaS —— 用按需函数补足动态

五、Edge —— 算力逼到”最后一跳”

六、托管平台的角色:把这条主线”缝合”成工作流

七、全景因果链

📊 主线因果图

关系图谱

目录

反向链接