边缘计算部署（Edge Runtime）

传统服务器部署有一个根本问题：服务器在一个地方，用户在全世界。上海的服务器响应北京用户只需 20ms，响应纽约用户却要 200ms。边缘计算的核心思想是把计算逻辑推到离用户最近的节点上执行——全球 300+ 个边缘节点，每个用户都享受本地延迟。本章深入 Nuxt4 的边缘部署方案，讲清楚 Edge Runtime 的能力边界和工程实践。

1. 边缘计算的本质

1.1 从 CDN 到 Edge Compute

CDN（Content Delivery Network）已经解决了静态资源的全球分发——JS、CSS、图片从最近的节点返回。但动态内容（SSR 页面、API 响应）仍然需要回源到中心服务器。

Edge Compute 把 CDN 升级为"可执行代码的 CDN"——不仅缓存静态文件，还能在边缘节点上运行服务端逻辑：

传统架构：
用户（纽约）→ CDN（纽约，返回静态资源）→ 服务器（上海，处理 SSR/API）→ 返回

边缘架构：
用户（纽约）→ Edge Node（纽约，执行 SSR + API 逻辑）→ 返回

1.2 V8 Isolate vs 容器

边缘计算的底层运行时有两种模型：

Cloudflare Workers 使用 V8 Isolate——每个请求在独立的 V8 隔离环境中执行，不是完整的操作系统进程。这带来了极低的冷启动（< 5ms）和高密度部署（一台机器可以运行数万个 Worker），但代价是不支持完整的 Node.js API。

1.3 Edge Runtime 的限制

这意味着：不是所有 Nuxt 应用都能跑在边缘。如果你的 server routes 依赖文件系统、原生 Node.js 模块或直连数据库，就无法直接部署到 Edge。

2. Cloudflare Workers/Pages 部署

2.1 配置

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    preset: 'cloudflare-pages',
  },
})

cloudflare-pages preset 会：

• 将 SSR 逻辑编译为 Workers 兼容的代码
• 自动处理 Node.js API 的 polyfill（Buffer、process 等基础 API）
• 静态资源通过 Pages 的 CDN 分发
• 动态请求路由到 Workers 执行

2.2 Cloudflare 生态集成

Cloudflare 的边缘方案不是孤立的——它有一整套边缘基础设施：

2.3 NuxtHub

NuxtHub 是 Nuxt 团队出品的 Cloudflare 集成方案，提供了开箱即用的边缘数据库、存储和缓存：

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@nuxthub/core'],
  hub: {
    database: true,  // D1
    kv: true,        // KV
    blob: true,      // R2
  },
})

// server/api/videos.get.ts
export default defineEventHandler(async () => {
  const db = hubDatabase()
  return await db.prepare('SELECT * FROM videos LIMIT 10').all()
})

NuxtHub 的价值在于开发/生产环境统一——本地开发时模拟 D1/KV/R2，部署到 Cloudflare 后无缝切换到真实服务。

3. Vercel Edge Functions

3.1 配置

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    preset: 'vercel-edge',
  },
})

Vercel Edge Functions 基于与 Cloudflare Workers 类似的 V8 Isolate 模型，但有一些差异：

3.2 混合部署

Vercel 支持同一项目混合使用 Serverless Functions 和 Edge Functions：

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/api/auth/**': { edge: true },     // 认证 API 跑在 Edge（低延迟）
    '/api/upload/**': { edge: false },  // 上传 API 跑在 Serverless（需要完整 Node.js）
  },
})

这让你可以把对延迟敏感的逻辑（认证、重定向、个性化）放在边缘，把需要完整 Node.js 的逻辑（文件处理、数据库操作）放在 Serverless。

4. 边缘部署的兼容性挑战

4.1 Node.js 兼容性检查

部署到边缘前，需要检查所有 server 端依赖是否兼容 Edge Runtime：

# 检查依赖是否使用了 Node.js 原生模块
npx unjs-compatibility-check

常见的不兼容依赖：

• bcrypt / argon2：使用原生 C++ 绑定 → 替换为 bcryptjs（纯 JS）或 Web Crypto
• sharp：图片处理依赖原生模块 → 使用 Cloudflare Images 或外部服务
• pg / mysql2：TCP 数据库直连 → 使用 HTTP API（Neon、PlanetScale）或 D1

4.2 条件导入

如果某些代码只在特定环境下需要，可以用条件导入避免在 Edge 中加载不兼容的模块：

// server/utils/hash.ts
export async function hashPassword(password: string) {
  if (import.meta.dev || process.env.NITRO_PRESET === 'node-server') {
    const { hash } = await import('argon2')
    return hash(password)
  }
  // Edge 环境使用 Web Crypto
  const encoder = new TextEncoder()
  const data = encoder.encode(password)
  const hashBuffer = await crypto.subtle.digest('SHA-256', data)
  return btoa(String.fromCharCode(...new Uint8Array(hashBuffer)))
}

4.3 外部服务替代

5. 边缘部署的性能特征

5.1 延迟分析

传统 SSR（服务器在美东）：
  用户（东京）→ 美东服务器 = ~180ms RTT

Edge SSR（Cloudflare Workers）：
  用户（东京）→ 东京边缘节点 = ~5ms RTT

对于全球用户来说，Edge 的 TTFB（Time to First Byte）通常在 20-50ms，而传统 SSR 可能在 100-300ms。

5.2 什么时候边缘更快

• SSR 渲染：页面渲染逻辑不依赖中心数据库时
• API 网关：认证、重定向、A/B 测试、地理位置路由
• 缓存逻辑：边缘缓存 + stale-while-revalidate
• 静态内容个性化：根据用户地理位置/语言返回不同内容

5.3 什么时候边缘不合适

• 数据库密集操作：每次请求都要查数据库，而数据库在中心机房——边缘节点到数据库的延迟反而更高
• 大量计算：CPU 密集型任务受 Edge 的 CPU 时间限制
• 文件处理：上传、转码、图片处理需要完整的 Node.js 环境

6. 全球加速架构

6.1 混合架构

最佳实践是边缘 + 中心混合部署：

用户请求
    ↓
Edge Node（全球 300+ 节点）
    ├── 静态资源 → 直接返回（CDN）
    ├── SSR 页面 → 边缘渲染 + 缓存
    ├── 轻量 API → 边缘执行（认证、重定向）
    └── 重量 API → 回源到中心服务器（数据库操作、文件处理）

6.2 边缘缓存策略

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { isr: 3600 },                    // 首页 ISR 缓存 1 小时
    '/video/:id': { swr: 600 },            // 视频页 SWR 缓存 10 分钟
    '/api/public/**': { cache: { maxAge: 300 } }, // 公共 API 缓存 5 分钟
    '/dashboard/**': { ssr: false },        // 后台不走边缘 SSR
  },
})

swr（Stale-While-Revalidate）是边缘缓存的最佳策略：立即返回缓存内容，后台异步刷新。用户感知到的延迟极低，内容最终一致。

本章小结

• 边缘计算 = 在离用户最近的节点执行代码，从 180ms 降到 5ms RTT
• V8 Isolate：冷启动 < 5ms，但不支持完整 Node.js API（无 fs、无原生模块、无 TCP 直连）
• Cloudflare Workers/Pages：300+ 节点，D1/KV/R2 边缘基础设施，NuxtHub 开箱即用
• Vercel Edge：可与 Serverless 混合部署，延迟敏感逻辑走 Edge，重操作走 Serverless
• 兼容性：bcrypt → bcryptjs，PostgreSQL 直连 → Neon HTTP，文件系统 → R2
• 最佳架构：Edge + 中心混合——静态资源和轻量逻辑走边缘，数据库密集操作回源中心