---
title: Vibe Coding 做出的 Next.js 应用，如何用函数服务和 DCDN 做全球加速
canonical: "https://xiaofeng.dev/en/writing/vibe-coding-nextjs-vefaas-dcdn/"
pubDate: 2026-08-09
author: 唐小锋 Xiaofeng TANG
description: 从纯静态、前端直连 Supabase、Next.js 服务端三种形态出发，梳理函数服务、运行时版本、实例并发、DCDN 缓存与动态请求回源的部署判断。
tags: [Next.js, Serverless, DCDN, Deployment]
---

最近想分享一个比较实用的话题：Vibe Coding 做出来的 Next.js 应用应该怎么部署，以及怎么给它做全球加速。

这类应用通常有三种形态：

1. **纯静态应用**：只有前端页面，不需要数据库，也没有服务端逻辑。
2. **前端 → Supabase（SDK / REST）**：浏览器通过 Supabase 的客户端 SDK 或 REST 接口读写数据，由 RLS 负责数据权限。
3. **前端 → Next.js 服务端 → Supabase / 外部服务**：Next.js 服务端可以通过 API、SSR、Server Component 或 Server Action，承载更复杂的权限与业务逻辑。

三者的部署方式并不一样。纯静态应用可以直接放到 CDN 或边缘节点；如果只是简单的数据读写，可以让浏览器直连 Supabase；如果应用需要隐藏服务端密钥、执行复杂业务逻辑，或者要在服务端生成页面，就需要让请求经过 Next.js 服务端。

![Next.js 三种部署架构](/writing/wechat-tech-assets/vibe-coding-nextjs-vefaas-dcdn/nextjs-three-deployment-architecture.svg)

这里的“经过 Next.js 服务端”不等于一定存在一个传统 API。SSR 或 Server Component 可以在服务器直接读取 Supabase 后生成页面；Route Handler 或 Server Action 则更常用于浏览器操作触发的读写。它们经常组合使用，但解决的是不同问题。

第三种形态还有一个特别需要注意的点：服务端要尽量靠近数据库。

既然 Next.js 服务端承担了 API、SSR 或 Server Action 的工作，它就会频繁访问数据库和其他外部服务。不能为了全球访问把服务端部署在海外，但数据库还在大陆，尤其是一次请求中存在多次服务端与数据库之间的来回调用时，跨区域延迟会不断叠加，最后用户感受到的反而是更慢。

所以，选择服务端部署区域时，应该先看数据库在哪里，再看用户主要在哪里。DCDN 可以加速用户到边缘节点这一段，但不能消除服务端与数据库之间的远距离调用。

## 一、前端直连 Supabase 时要注意什么？

浏览器里的代码和用户是同一侧的，用户可以看到前端发出的请求。因此，浏览器直连 Supabase 时，不能把安全寄托在“用户看不到接口”上。

不过，浏览器直连 Supabase 并不等于天然不安全。Supabase 的 anon key 本来就可以放在前端，真正负责数据隔离的是数据库的 RLS 策略和用户权限。新增、修改、删除等操作也可以通过 RLS 安全完成，但规则必须配置正确。

如果还需要隐藏 service-role key、调用第三方私密 API、执行复杂业务规则，或者不希望把数据处理过程暴露在浏览器中，就应该由 Next.js 的服务端逻辑承接请求，在服务端完成鉴权、权限判断和数据库操作。

## 二、用函数服务运行 Next.js

我最近体验的是火山引擎的函数服务。它的思路是：把应用代码交给云端，由云端在容器中运行，并提供一个可以公开访问的域名。

在这种部署方式中，Next.js 的前端页面和服务端逻辑可以由同一套应用承载。你还可以为函数设置实例策略：

1. **动态实例**：请求到来时再启动实例，成本较低，但可能遇到冷启动。
2. **预留实例**：提前启动固定数量的实例，响应更快，但会持续占用资源。

我原本以为预留实例一定更贵，后来发现并不完全如此。因为资源提前锁定后，调度成本更低，在访问量较大的场景下，预留实例反而可能更划算。

如果只是开发环境，流量很少，可以使用动态实例；如果访问量比较稳定，或者比较在意首个请求的响应速度，可以考虑预留实例。

另外，不管是动态实例还是预留实例，每个实例都有自己的并发配置。平台给出的默认并发值可能是 100，但不要直接照搬这个默认值。因为默认实例的内存和 CPU 通常并不高，Next.js 的 SSR 或 API 在高并发下会让多个请求争抢同一个实例的资源，容易出现排队、超时或错误。

这种情况下，单实例并发宁可先设得低一些，再结合 CPU、内存、响应时间和错误率做压测，逐步调高。实例数量和单实例并发是两个不同的参数，都需要根据实际负载调整。

## 三、先确认平台支持的 Node.js 版本

不同服务商对 Next.js 的运行环境要求并不一样，不能只因为本地项目能跑，就直接把它部署到任意平台。

以火山引擎为例，当前官方部署文档要求本地准备 Node.js 20.x，并选择 Native Node.js 20.x 运行时。更高版本不要轻易使用，至少要先确认平台当前的运行时支持范围，以及 Next.js 和依赖是否兼容。

如果使用 veFaaS CLI 部署，官方流程是：CLI 在项目目录中探测框架、构建命令、产物路径和启动命令，然后进入依赖安装和构建流程，再把构建结果部署到云端。也就是说，针对这条 CLI 部署路径，构建主要发生在本地，云端负责接收并运行部署产物，并不是把完整源码交给云端再临时构建。

因此，部署前最好让本地 Node.js 版本和平台运行时保持一致。我更推荐配合 veFaaS CLI 和对应的 Skill 使用：CLI 负责真实执行，Skill 负责提示运行时、构建配置和常见排障路径。

## 四、为什么还要在函数服务前面加一层 DCDN？

函数服务解决的是“代码在哪里运行”，但它本身不等于全球加速。用户的请求仍可能需要跨较远的网络访问函数实例。

一种做法是在函数服务前面接入 DCDN，把它作为统一的访问入口。这样可以让静态资源尽量在边缘节点命中，同时把动态请求转发回函数服务。

但仅仅把 DCDN 挂上去还不够，关键是要配置缓存和条件路由。

### 静态资源：尽量缓存

Next.js 生成的静态资源通常可以缓存较长时间，例如 `_next` 路径下的资源。这些文件一般带有版本化或哈希信息，内容变化后 URL 也会变化，适合交给 CDN 缓存。

### 动态接口：默认不要缓存

登录状态、用户信息和数据库查询结果都可能是动态内容，尤其是 `/api/` 下的接口，通常不应该直接套用静态缓存规则。

可以通过条件路由区分静态资源和动态请求：静态资源走缓存，API 和其他动态页面回源到函数服务。具体规则要结合自己的路由结构验证，不能只凭路径名称盲目配置。

## 五、DCDN 里几个值得检查的配置

### HTTP/2

HTTP/2 可以帮助同一个连接并发处理多个请求，对动态请求和包含多个资源的页面比较有帮助。

### Gzip

Gzip 可以压缩 HTML、CSS、JavaScript 等文本资源，通常收益明显，性能损耗也较小，一般建议开启。

### HTTPS

HTTPS 是生产环境的基本配置。除了保护传输内容，现代浏览器的许多能力也依赖安全连接。

## 六、DCDN 的加速范围

DCDN 通常有大陆、海外和全球三种加速范围。具体怎么选，取决于用户分布，而不是简单跟着函数服务所在区域走。如果缺少可以国内备案的域名，就选海外加速即可。

## 结论：函数服务 + DCDN 适合什么场景？

如果你的 Next.js 应用需要服务端执行（例如 SSR、Route Handler 或 Server Action），或者需要让服务端安全地连接数据库，那么“函数服务 + DCDN”是一种相对直观的方案：

- 函数服务负责运行 Next.js 和服务端逻辑；
- DCDN 负责静态资源缓存和网络加速；
- 条件路由负责区分静态请求和动态请求；
- 实例策略负责在响应速度与成本之间做取舍。

站点部署好之后，我还推荐用 Chrome DevTools 的性能分析工具跑一遍，看看首屏加载、静态资源、网络请求和脚本执行方面还有哪些值得优化的地方。部署完成不等于性能优化结束，实际访问数据和浏览器分析结果，才是下一轮调整的依据。