边缘计算四：边缘渲染与传统 SSR 有啥不一样？

“我们项目用了 SSR。”

“我们项目部署到了边缘。”

“我们用了 Next.js + CDN。”

以上这些听起来都很“现代”，但你知道吗？

SSR 和边缘渲染（Edge Rendering）是两种完全不同的逻辑与架构思维。

它们长得像，背后却走的是不同赛道。今天我们就来掀开这层“看似一样”的面纱。

一、什么是传统 SSR？

传统 SSR（Server-Side Rendering）是指在Node.js 服务端通过 JavaScript 渲染完整 HTML 返回给客户端。

流程如下：

1. 用户访问页面

2. 浏览器发送请求到服务器

3. Node 执行 React 渲染

4. 返回完整 HTML 页面

5. 客户端加载 JS 进行 hydration（激活）

优点：

• 提升首屏速度（与 SPA 相比）

• 有利于 SEO

• 可结合动态内容（用户登录、个性化等）

缺点：

• 服务器压力大，所有渲染都要经过服务器

• 用户离服务器远 → 首屏慢

• 每次请求都需冷启动或执行大量计算

二、什么是边缘渲染（Edge Rendering）？

边缘渲染 = 渲染逻辑不再在“中央服务器”，而是在CDN 边缘节点执行。

流程如下：

1. 用户访问页面

2. 就近 CDN 节点拦截（如 Cloudflare、Vercel Edge）

3. 节点执行 JavaScript 渲染逻辑（如 React 组件）

4. 构造 HTML 返回，几乎无物理距离延迟

优点：

• 全球用户都能快速加载首屏

• 不依赖单个主服务的负载

• 延迟低，响应更快

• 可用于“中等复杂”的页面个性化

局限：

• 执行环境限制更大（例如没有完整 Node API）

• 复杂业务逻辑不宜全搬过去（如文件系统访问、数据库直连）

• 每次请求都“即时渲染”，需配合缓存策略

三、对比总结：传统 SSR vs 边缘渲染

对比项	传统 SSR	边缘渲染（Edge Rendering）
渲染位置	中心服务器	用户就近 CDN 边缘节点
响应延迟	随位置不同波动大	延迟低、全球一致体验
可扩展性	容易被流量冲击	边缘平台自动弹性扩容
编程环境	Node.js 全 API	限制多，平台沙箱环境
数据访问	适合连接数据库	需配合 API/BFF 请求数据

四、哪些场景适合边缘渲染？

• 需要轻度动态内容（如登录状态、地区推荐）

• 网站用户分布全球

• SEO 要求较高，不能全靠静态页面

• 希望加速首屏 + 减轻主服务负载

不适合的情况：

• 渲染逻辑复杂、依赖数据库、第三方依赖多

• 页面对缓存不敏感（每次都必须拉新数据）

五、如何在 Next.js 中启用 Edge 渲染？

export const runtime = 'edge';

export default function Page() {
  return <div>Hello Edge!</div>;
}

注意事项：

• 使用 fetch 获取外部数据 → 不能使用 axios（Node-only）

• 不支持 fs、path、process.env 等 Node API

• 使用平台如 Vercel、Cloudflare 自动部署到边缘节点

六、从“SSR”到“边缘 SSR”的架构转型要点

• 数据分发层：改为从 API 层取数据，而非直连数据库

• 页面切分策略：复杂页面 → SSR / SSG，轻量页面 → Edge SSR

• 缓存设计：合理设置 Cache-Control，搭配 revalidateTag 等机制

• 中间件策略：登录态、地域跳转、AB 实验 → 提前执行于边缘节点

总结一句话

边缘渲染 = 更靠近用户的 SSR，不是 SSR 的升级，而是架构维度的转型。

它不是适合所有页面，但在体验要求越来越高的今天，它已经是构建现代 Web 项目的重要能力之一。