边缘计算一：现代前端架构演进图谱 —— 从 SPA 到边缘渲染
过去十年，前端项目架构经历了从简单 HTML 文件到复杂框架的飞跃，但很多开发者忽略了**“渲染位置”与“资源交付方式”**对体验与性能的根本性影响。
从最初的浏览器渲染，到现在“在离用户最近的地方动态返回 HTML”，架构正在悄悄改变。
这篇文章我们用一张思维图，梳理：
-
前端架构渲染方式演进的五个阶段
-
每种方式的核心逻辑、优缺点
-
当前趋势：边缘渲染（Edge Rendering）为何成了“显学”
一、前端架构五阶段演进图
静态 HTML → SPA → SSR → SSG → ISR → Edge SSR
我们按时间和复杂度拆解：
| 渲染方式 | 特征 | 代表框架 | 部署平台 |
|---|---|---|---|
| 静态 HTML | 页面全写死 | 无 | 任意静态空间 |
| SPA（客户端渲染） | JS 驱动 DOM | React, Vue | 任意 CDN |
| SSR（服务端渲染） | Node 渲染 HTML | Next.js, Nuxt | Node 服务器 |
| SSG（静态生成） | 构建时产出 HTML | Gatsby, Next.js | CDN |
| ISR（增量静态渲染） | 按需构建、可回源 | Next.js ISR | Vercel / Netlify |
| Edge SSR | 离用户最近处实时渲染 | Next.js App Router | Cloudflare, Vercel Edge |
二、SPA：从“快”到“慢”的误解
最早的 React/Vue SPA 项目“快得飞起”，但后来大家发现：
-
首屏加载慢（JS 巨大）
-
SEO 效果差（HTML 是空壳）
-
数据都等 JS 跑完后才加载
原因是：所有渲染都在浏览器端完成，HTML 是个“壳子”。
三、SSR 与 SSG：性能与 SEO 的回归
为了解决 SPA 的问题，我们开始：
-
SSR：在服务器上生成完整 HTML → 提升首屏 + SEO
-
SSG：构建阶段生成 HTML → 快得像静态页，但不能频繁变动内容
但：
-
SSR 受限于服务器性能，用户远了就慢
-
SSG 内容一旦多，需要频繁重新构建
四、ISR：让静态页“活”起来
ISR（Incremental Static Regeneration）是个妙招：
-
页面首次访问时构建
-
后续访问使用缓存
-
设定过期时间或 tag 控制更新
优势是：无需每次部署全量构建，也保留 CDN 加速的性能
五、Edge SSR：渲染靠近用户，真正意义上的“前端后端化”
为什么需要 Edge SSR？
传统 SSR 服务器 → 可能在东京
中国用户访问 → 经历 300ms 网络时延
Edge SSR → 在香港、北京、上海的边缘节点直接执行渲染逻辑
提升的是：全局用户的首屏体验和动态内容交付能力
如何实现？
-
利用平台如 Vercel Edge Functions、Cloudflare Workers
-
使用 Next.js App Router + middleware + edge config
这就意味着你的 React 应用可以在 CDN 的边上完成动态 HTML 渲染，而不必等中央服务响应。
六、总结
现代前端开发者不只是“写页面的人”，而是“体验调度师”。
在你下次回答“这个项目我们用什么架构”的时候，试着思考：
-
渲染在哪里？
-
数据在哪里？
-
用户在哪里？