Fluid Compute 解决了什么问题
- 年正式 GA 的 Vercel Fluid Compute，是将原本分为「Serverless Functions」与「Edge Functions」的运行时整合为一体的新一代执行基础设施。传统 serverless「1 个请求 = 1 个容器」的空闲计费负担沉重，而 Edge Functions 则受制于 50MB 的代码体积上限与 Node.js 兼容性约束。Fluid Compute 采用单一实例并发处理多个请求的「多租户并发」模型，将 I/O 等待时间排除在计费之外。由此，「保持数据库连接的同时获得接近边缘的低延迟」这一原本相互矛盾的特性得以同时实现。
截至 2026 年 4 月，next.config.ts 中的 `runtime` 选项已有 `"nodejs"` / `"edge"` / `"fluid"` 三种选择。Next.js 16 默认为 `"fluid"`，`/app` 目录下的路由除非明确写出 `export const runtime = "edge"`，否则均运行在 Fluid 上。Edge Functions 的使用场景已收窄至 WebSocket 终端或极低延迟 API，原本「Edge 还是 Lambda」的选型讨论已转变为「Fluid 是否足够，还是需要 Edge」。
Next.js 16 的 RSC 边缘渲染
Next.js 16 使得 React Server Components（RSC）的流式输出可以在 PoP（接入点）生成。具体而言，以 Suspense 边界为单位异步 flush HTML 与 RSC payload，将 TTFB 缩短至约 40ms。关键在于数据获取的位置。RSC 可以编写在服务器端完成的 fetch，但应避免直接连接源 DB，转而通过 Vercel Data Cache（原 Request Memoization）或 Hyperdrive / PlanetScale Boost 等边缘缓存层，这已成为铁律。
运行在 Edge Runtime 上的 RSC 存在约束：无法使用 Node.js 的 fs / net / child_process，加密操作需通过 Web Crypto API 进行。2025 年末新增的 edge-compatible adapter 使 Prisma 6 和 Drizzle ORM 可以直接运行，但 Sequelize 和 TypeORM 仍建议使用 Fluid。「RSC 走 Edge、DB 写入走 Fluid」的职责分工已成为 2026 年的标准方案。
```typescript // app/products/[id]/page.tsx export const runtime = "edge"; export const revalidate = 60; export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) { const { id } = await params; const product = await fetch(`${process.env.EDGE_API}/products/${id}`, { next: { revalidate: 60, tags: [`product-${id}`] }, }).then((r) => r.json()); return ( <> <ProductHeader product={product} /> <Suspense fallback={<ReviewsSkeleton />}> <ProductReviews id={id} /> </Suspense> </> ); } ```
Streaming SSR 与 Partial Prerendering（PPR）
PPR 是 Next.js 14 引入的实验性功能，15 版本稳定化，16 版本默认启用，以构建时与运行时的混合方式交付「静态框架 + 动态填充」内容。将构建时生成的 HTML 骨架立即从 PoP 返回，同时将用户专属部分（购物车图标、推荐商品）保留为 Suspense 边界，从服务器后续 flush。由此可在维持 CDN 命中率的同时实现个性化。
实现上的陷阱是「一旦引用了 `cookies()` 或 `headers()`，整个树就会变为动态」。在布局中随意调用 `headers()` 会导致 PPR 的静态框架无法生成，每次退化为完整 SSR。应在 `next build` 的输出日志中定期审计「Static (prerendered)」与「Dynamic (on-demand)」的比例，并通过 CI 检测静态比例是否下降。
Edge Config 与 CDN 支撑的功能开关
Edge Config 是 Vercel 提供的「读取优化 JSON 存储」，可在 Edge Runtime 中以 1ms 以下的延迟读取。不使用 LaunchDarkly 或 Statsig 等 SaaS，而是通过 Edge Config + Vercel Flags SDK 构建内部功能开关基础设施，已成为 2026 年的现实选择。写入通过管理 API 在数秒内传播至所有区域，读取则内嵌于运行时的 Isolate 中，不产生网络 RTT。
Flags SDK 以统一 API 处理 A/B 测试与功能开关评估，并在 RSC 和客户端组件之间保持 identity 一致。具体而言，在 middleware 中将用户 ID 固定到 cookie，在 RSC 中评估 `flag("new-checkout").bucket(userId)`，并将结果作为 searchParams 传递给子组件。由此，「首次访问时在服务器端决定的 variant 在后续页面跳转中保持不变」这一类 SPA 体验得以在边缘完整实现。
```typescript import { flag } from "@vercel/flags/next"; import { get } from "@vercel/edge-config"; export const newCheckout = flag<boolean>({ key: "new-checkout", async decide({ entities }) { const config = await get<{ rollout: number }>("new-checkout"); const userId = entities?.user?.id ?? "anon"; return hash(userId) % 100 < (config?.rollout ?? 0); }, }); ```
Edge Config 的大小上限已扩展至每个 store 512KB、每个项目 10 个 store（2025 年末）。在实际使用中，主要用于存储更新频率为秒级至分钟级即可的配置值，如「功能开关定义」「价格表」「按地区划分的敏感词」等。对于用户资料等高频更新数据，应分别使用 KV 或 Redis。
可观测性与 Sourcemap
Fluid Compute 标准支持 OpenTelemetry 自动注入，只需导入 `@vercel/otel` 包，trace 数据即可流入 Datadog / Honeycomb / Grafana Cloud。在 RSC 中调用 `fetch` 时，span 会自动切分；Web Vitals（LCP / INP / CLS）则作为 RUM 通过独立流采集。自 2026 年起，Vercel Observability Plus 支持安全上传生产环境 sourcemap，以 TypeScript 行号解析堆栈追踪。
错误预算的运维方面，可通过 Vercel Monitoring 的查询语言（VQL）定义 SLO，并将 burn rate 告警推送至 Slack / PagerDuty，这已成为标准做法。将 Edge Functions 的 p99 延迟、Fluid 的并发调用数、Data Cache 命中率并排展示在同一仪表盘上，可以提前发现 PPR 静态比例下降或缓存未命中增加的问题。边缘竞争的关键不仅在于「快」，更在于「稳定的快」。