Vercel 对 Edge 运行时的卖点是：V8 isolate 离用户最近、冷启动几十毫秒。这以前确实稳胜 Node serverless——但到 2026 年有两件事变了。第一，2025 年年中 Vercel 把整套体系改名重构了：「Edge Functions」和「Edge Middleware」已弃用，分别被 Vercel Functions（可选 Edge 运行时）和 Vercel Routing Middleware 取代。第二，Fluid compute 现在会把 Node 实例保持在热状态，老那套「Node 冷启动 300-1500ms」的说法基本站不住了。对内容站来说，这把账重新算下来，结论更偏向「静态 + 一层薄薄的中间件」。本文讲清 Edge 运行时现在到底在哪还值，以及哪里得不偿失。
一句话结论（TL;DR）
- 纯内容页 静态还是赢：CDN 直出的预生成页 TTFB 大约 20-40ms，零函数成本。下面任何方案都比不过它。
- Edge 运行时只在「必须跑在缓存之前」的活上才对：地区分流、语言跳转、A/B 分桶、读鉴权 cookie。这正是 Routing Middleware 干的事。
- 自从 Fluid compute 上线（2025 年 4 月起新项目默认开），Vercel 称 99.37% 的请求零冷启动。那套「为了躲 Node 冷启动而上 Edge」的老理由基本没了。
- 盯紧真实限制（2026 年 6 月）：Edge 运行时 bundle Pro 2 MB / Enterprise 4 MB，请求 + 响应体 4.5 MB，Routing Middleware 预算约 50ms 平均 CPU。
2025-2026 到底改了什么
如果你看的是旧教程，名字会跟控制台对不上。按 2025 年 6 月那次平台更新：
- Edge Functions → Vercel Functions（Edge 运行时）。 还是那个 V8 isolate 运行时，但现在只是统一 Functions 产品里的一个运行时选项，跑在缓存之后。
- Edge Middleware → Vercel Routing Middleware。 一个一等公民原语，用 Fluid compute 跑在缓存之前，默认仍走 Edge 运行时，预算约 50ms 平均 CPU。
- Fluid compute 新项目默认开。不再是每个请求一个 micro-VM，而是多个并发调用共享实例，Pro/Enterprise 还会至少留一个实例常热（「scale to one」）。这就是把冷启动压到不到百分之一的原因。
实际影响是：选「Edge 还是 Node」不再主要看冷启动延迟，而是看这段活在请求生命周期的哪个位置（缓存前还是缓存后）、以及你需要什么 API（只用 Web 标准，还是要完整 Node）。
先判断：你到底需不需要函数
- 每次页面加载都打函数，而这活确实没法预生成。
- 在服务页面之前就要做地理定位、A/B 测试或鉴权——不是之后。
- 这活很小（Pro 上 2 MB Edge bundle 以内）、纯 JS、不需要文件系统或原生模块。
- 你看到的 TTFB 尖刺是函数引起的，而不是 CDN 本就能解决的网络距离。
如果以上都不成立，那你要的是静态。内容站绝大多数文章页都是静态的。
快速结论
如果活是「重写、跳转、按地区分流、设 cookie、读 header」——Edge 运行时上的 Routing Middleware 对。如果是「渲染页面、生成 OG 图、用胖 ORM 查数据库」——Node Vercel Function 更稳，而 Fluid compute 让它的冷启动很少咬人。纯内容，静态胜过两者。
Edge 运行时真正能赢的场景
三个「跑在缓存前、用 Edge 运行时」明显比 Node 函数强的内容站模式：
- 中间件里的按地区语言跳转。 根据
Accept-Language或国家码把/跳到/en/或/zh/。它跑在缓存之前，开销大概 20ms：
// middleware.ts —— Vercel Routing Middleware
import { NextResponse, NextRequest } from 'next/server';
export const config = { matcher: ['/'] };
export function middleware(req: NextRequest) {
const country = req.geo?.country ?? 'US';
const lang = country === 'CN' || country === 'TW' ? 'zh' : 'en';
return NextResponse.redirect(new URL(`/${lang}/`, req.url));
}- 带 cookie 持久化的 A/B 测试。 首次访问分桶、写 cookie、之后保持稳定。分桶决策必须在缓存之前，中间件正合适：
// middleware.ts —— 分桶并重写到变体
import { NextResponse, NextRequest } from 'next/server';
export const config = { matcher: ['/pricing'] };
export function middleware(req: NextRequest) {
const existing = req.cookies.get('ab-pricing')?.value;
const bucket = existing ?? (Math.random() < 0.5 ? 'a' : 'b');
const url = req.nextUrl.clone();
url.pathname = `/pricing-${bucket}`;
const res = NextResponse.rewrite(url);
if (!existing) {
res.cookies.set('ab-pricing', bucket, { maxAge: 60 * 60 * 24 * 30 });
}
return res;
}- 鉴权预览。 在边缘读 session cookie，把草稿重写到 preview 分支，没权限的直接拦下，不用回 Node origin。注意控制在约 50ms CPU 预算内——验 JWT 没问题，查数据库不行。
值得记一下的真实延迟数字（2026 年 6 月）
Vercel 的粗略预算，从 iad1（us-east-1）、热缓存测：
| 路径 | TTFB（热） | 冷的情况 |
|---|---|---|
| CDN 上的静态页 | 20-40ms | 无（没有函数） |
| Routing Middleware（Edge 运行时） | 缓存前再加 20-50ms | 某冷区域首次命中约 80-150ms |
| Node Vercel Function（Fluid、热） | 80-200ms | 罕见——不到 1% 的请求 |
| Node Vercel Function（真冷启动） | —— | 300-1000ms，Pro/Enterprise 的 scale-to-one 基本消掉 |
两点要记住。第一，中间件在每个匹配到的请求上都跑、且在缓存之前，所以在那些本可 CDN 直出的路由上它是额外开销——只匹配真正需要的路径。第二，Fluid compute 保持实例常热后，老那套 Node 最坏冷启动在付费档已经是边角情况，这就抽掉了历史上「上 Edge」的一大半理由。
该用 Node 函数的场景
- OG 图生成，用
@vercel/og加自定义字体。它能跑在 Edge 运行时上，但一旦你要从文件系统加载资源、或 bundle 蹭过 2 MB Edge 上限，Node 更干净。 - 要打 Prisma、Drizzle 或任何没正式支持 Edge 的 ORM 的 API 路由。 大部分仍想要 Node 运行时；有了 Fluid compute，过去把它们逼上边缘的冷启动惩罚基本没了。
- 任何用原生依赖的：
sharp、puppeteer、node-canvas。这些在 Edge 运行时上根本跑不起来——只能 Node。
两者都不对、静态才赢的场景
- 按已知节奏更新内容的文章页。 build 时预生成，更新走 ISR 或 on-demand revalidation，函数完全省掉。
- sitemap 和 robots。 build 时生成，CDN 直出，零函数调用。
- 数据量在约 200 KB 以内的搜索 / 过滤 UI。 跟着页面一起发出去，前端直接过滤。
对一个典型的双语内容站，这几乎覆盖了绝大多数路由。唯一长期存在的函数，通常就是一层做语言路由的中间件。
容易踩的坑
- 「为了个性化」把文章页放到函数后面。 CDN 缓存全废，每次请求都多一份延迟。改成前端个性化，或者用一层薄中间件做重写。
- 在 Edge route 里 import 了 Node-only 模块，部署时才发现。本地 dev 也把 Edge 运行时设上，让错误早点暴露。
- 忘了即便 304 中间件也会跑。 Routing Middleware 在缓存之前执行，所以匹配到的请求不管要不要重发响应体，都计用量。
- 在边缘读集中式数据库。 函数快，但从各地区回数据库的 round trip 一点不快。要么用全球复制存储（Upstash、PlanetScale 那类 edge driver），要么把数据预生成。
- 还按老的 1 MB 中间件上限算。 Edge 运行时 bundle 上限现在是 Pro 2 MB、Enterprise 4 MB（2026 年 6 月）。字体把你顶过去了，就把 OG 那块挪到 Node 函数。
成本提醒
在 Pro 档（2026 年 6 月每席位每月 $20），Vercel 按 活跃 CPU 时间和已分配内存时间 计费，不是按墙钟时间——等 I/O（数据库、AI 调用）不算活跃 CPU。包含额度对内容站够用，但高流量路由上的中间件每次命中都烧 Edge Request，所以 matcher 要框紧。Hobby 档免费但仅限非商业，所以要变现的内容站得上 Pro。
FAQ
- Vercel 真把 Edge Functions 弃用了？：弃的是名字。按 2025 年年中的平台更新，「Edge Functions」和「Edge Middleware」已弃用，分别被 Vercel Functions（可跑 Edge 运行时）和 Vercel Routing Middleware 取代。Edge 运行时本身还活着，中间件默认就用它。
- 有了 Fluid compute，还需要靠 Edge 运行时躲冷启动吗？：通常不用。Vercel 称 Fluid compute 下约 99.37% 的请求零冷启动，所以躲冷启动已经不是上边缘的主要理由。选它是为了跑在缓存之前（地区、A/B、鉴权），不是为了纯延迟。
- 现在 Edge 运行时 bundle 上限是多少？：2026 年 6 月，Pro 2 MB、Enterprise 4 MB，包含代码、库以及字体等打包进去的资源。Node 函数最多 250 MB（未压缩）。
- Edge 运行时上能用哪些 API？：Web 标准 API（fetch、Request、Response、crypto.subtle、streams）。没有
fs、没有原生模块、Buffer也受限。要完整 Node 覆盖就用 Node Vercel Function。 - Astro 支持 Edge 运行时吗？：
@astrojs/verceladapter 有 edge 选项，但大多数 Astro 内容站是静态的，根本用不上。先发静态，只在真需要缓存前路由时才加一层中间件。 - 迁到边缘会让 Lighthouse 分数变高吗？：仅当你的 TTFB 卡在函数冷启动上——而这恰恰被 Fluid compute 基本消掉了。配好缓存头的静态页 Lighthouse 上已经赢了。