在 Vercel 运行 Nuxt 应用：减少 Serverless 调用次数的缓存配置指南
makedream1 Mei 2026
0
Computing/SoftwareRelated Video
36:54▲ 社区分享会：在 Vercel 上使用 Nuxt
Vercel
Comments (0)
Log in to leave a comment
No posts yet
makedream36:54makedream36:54Vercel
Log in to leave a comment
No posts yet
Nuxt 的 Nitro 引擎看似能在任何地方完美运行，但一旦部署到 Vercel Edge Runtime，情况就大不相同了。原本在本地运行良好的 sharp 或 bcrypt 等库，在部署后立即抛出 500 错误，其原因在于 Vercel Edge 限制了对 Node.js 标准模块的访问。在点击部署按钮之前，我务必会先执行 npx vercel build。如果不预先模拟基于 Linux 的环境，极有可能在凌晨 3 点还在与运行时错误（Runtime Error）作斗争。
为了保障运行稳定，建议在 nuxt.config.ts 中将 preset 明确指定为普通的 vercel，而非 vercel-edge。并没有必要让所有的 API 都运行在 Edge 上。此外，环境变量也不要直接调用 process.env，而应通过 Nitro 的 useRuntimeConfig 进行标准化处理。这一细微的习惯能消除 80% 部署后产生的运行时错误。
Vercel 账单的主要“元凶”是 Serverless 函数的执行时间和调用次数。Nitro 3 提供的 routeRules 是从物理层面削减这些成本的最强工具。如果正确使用 stale-while-revalidate (SWR) 策略，即使 API 请求达到 1 万次，实际的函数执行可能仅需 1 次。这是一种既能给用户提供毫秒级快速响应，又能守住钱包的聪明做法。
以下是降低 40% 以上成本的具体配置方法：
nuxt.config.ts 的 routeRules 对象中指定需要缓存的路径。swr: 3600，开启 1 小时的后台更新模式。cache 选项内明确 maxAge 和 staleMaxAge，定义 CDN 持有缓存的时间。完成这些设置后，你会在 Vercel 控制面板中看到 Serverless 函数调用次数呈直线下降。
当服务器生成的 HTML 与客户端的 JavaScript 结合时产生的水合错误会使应用变得不稳定。Nuxt 4 为了解决这一问题，在调用 useAsyncData 时默认将 deep: false 作为缺省值。虽然放弃了不必要的对象追踪，但换来了内存节省，并能将服务器状态安全地传递给客户端。
请遵循以下三条规则来捕获数据不一致并减小 Payload 体积：
pick 选项，仅筛选出模板渲染所必需的键值。单这一项操作就能减少高达 50% 的 Payload 体积。useId()，确保服务器与客户端的标识符一致。<NuxtTime> 组件包裹，以便基于浏览器 Locale 进行处理。随着项目规模扩大，Vercel 构建容器提供的 8,192MB 内存有时也会捉襟见肘。准确地说，是因为 Node.js 默认的堆大小（Heap Size）设置得比可用内存小，导致垃圾回收（GC）频繁，最终导致构建停止。
为了提高构建速度并防止部署失败，请立即应用以下设置：
NODE_OPTIONS="--max-old-space-size=4096"。仅需解除堆内存限制，即可消除构建瓶颈。npx nuxt analyze，检查是否有沉重的服务器专用依赖混入了客户端 Bundle 中，并使用 #server 别名进行隔离。server/middleware/ 中的重负载逻辑，移动到特定路径的事件处理器（Event Handler）内部，以减小服务器 Bundle 的体积。完成这些环境配置后，CI/CD 流水的等待时间将会缩短，部署失败率也会显著降低。