Vercel 部署深度优化
把 Next.js 项目推上 Vercel 很简单，真正难的是把它部署成一个稳定服务，而不是“偶尔能打开的线上演示”。
团队常见的上线后问题基本集中在四类：
- 构建越来越慢。
- 环境变量和分支环境混乱。
- 边缘函数和 Node 运行时边界不清。
- 成本上涨但不知道是哪部分在烧钱。
1. Vercel 优化的核心不是“更多配置”，而是“更清楚的运行边界”
你至少要明确这几件事：
| 维度 | 需要回答的问题 |
|---|---|
| 构建 | 为什么这次构建比上次更慢？ |
| 运行时 | 这个路由适合 Edge 还是 Node？ |
| 缓存 | 数据和页面分别缓存多久？ |
| 环境 | Preview、Production 是否隔离？ |
| 成本 | 是构建费、函数费还是带宽费在涨？ |
只要这些边界没定义清楚，优化就会变成盲调。
2. 构建时间变慢，通常不是 Vercel 的锅，而是项目边界膨胀了
最常见的构建变慢原因包括：
- 不必要的大依赖进入服务端 bundle。
- 图片和内容处理在构建期做太多。
- monorepo 里没有按影响范围构建。
更稳的做法是：
- 把大而少变的内容移出构建主链。
- 精简 server-only 与 client-only 依赖。
- 在 monorepo 中明确 filter 和缓存策略。
3. Edge Runtime 很强，但不是所有逻辑都该上 Edge
Edge 更适合：
- 全球就近响应。
- 轻量鉴权与路由决策。
- 简单个性化输出。
不适合：
- 强依赖 Node API 的逻辑。
- 大量数据库驱动和复杂计算。
- 长时间执行任务。
错误做法是“为了快就全部上 Edge”，最后调试复杂度和兼容问题一起上升。
4. 一个常见失败案例：预发环境和生产共用配置，结果发布成功但功能异常
这类问题很高发：
- Preview 与 Production 用了同一套外部服务配置。
- 预发数据误写到生产库。
- 发布时页面能打开，但真实业务已被污染。
根因不是 Vercel 配置复杂，而是环境边界没有被当成产品边界管理。
修复方式通常是：
- 明确区分 preview/prod 环境变量。
- 外部服务按环境分实例或分 schema。
- 发布前检查关键环境变量来源。
5. 成本治理要拆成构建、函数和带宽三张账
很多团队只看到总账单，不知道哪里有问题。
更实用的拆法是：
- 构建成本：构建次数、构建时长、缓存命中率。
- 函数成本：调用次数、平均执行时长、冷启动情况。
- 带宽成本：图片、脚本、文件下载流量。
只有拆开看，你才知道是该优化 bundle，还是该优化函数调用频率。
6. 观测要覆盖“发布后是否真的变好”，而不是只看构建成功
至少要盯这几类信号：
- 发布后错误率。
- 关键页面 TTFB 和 LCP。
- 函数超时和重试。
- 环境变量缺失或配置异常。
“Deployment successful” 只是开始，不是验证结束。
7. 上线前 Checklist
- 已区分 Preview 与 Production 环境变量。
- 已确认哪些路由适合 Edge，哪些保留 Node。
- 构建链路中没有不必要的大依赖和重处理。
- 已监控函数耗时、错误率与超时。
- 已拆出构建、函数、带宽三类成本口径。
- 发布后有真实页面与关键流程回归检查。
- 已准备出错时的快速回滚路径。
- 关键外部服务的环境边界已验证。
FAQ
上 Vercel 后性能一定会变好吗？
不一定。平台提供了能力，但页面快不快，仍然取决于你的渲染策略、资源体积和缓存设计。
什么场景适合 Edge Runtime？
更适合轻逻辑、低延迟和全球访问场景，不适合重数据库逻辑和复杂 Node 依赖。
如何快速判断成本问题在哪？
先拆账单来源，再对照构建时长、函数调用量和资源流量，不要只看总额。
