多平台部署策略

Next.js 可以部署到几乎任何地方——Vercel 一键部署、Docker 容器化、AWS 全家桶、Cloudflare 边缘网络，甚至树莓派上跑 Node.js。但不同的部署目标意味着不同的功能支持、性能特征和运维成本。选错了平台，要么为用不到的功能付费，要么在关键功能上踩坑。本章从技术原理出发，深入对比每个平台的能力边界和最佳实践。

1. Next.js 的输出模式

1.1 理解 output 配置

在讨论部署之前，必须先理解 Next.js 的三种输出模式——它决定了你能部署到哪些平台：

1.2 每种模式的功能限制

关键决策：如果你的应用使用了 Server Components（几乎所有 App Router 应用都是），就不能用 export 模式。大部分生产应用应该选择 standalone 模式。

1.3 standalone 模式详解

standalone 模式是 Docker 部署的基础——它把 Next.js 应用打包成一个独立的 Node.js 程序，不需要 node_modules：

.next/standalone/
├── server.js          ← 入口文件（直接 node server.js 即可运行）
├── node_modules/      ← 只包含运行时必需的依赖（极小）
├── .next/             ← 编译后的应用代码
└── package.json

产物大小通常只有 50-100MB（完整 node_modules 可能 500MB+），非常适合容器化。

2. Vercel 部署

2.1 为什么 Vercel 是 Next.js 的最佳部署目标

Vercel 是 Next.js 的创造者，两者的集成深度是任何其他平台无法比拟的：

2.2 Vercel 的计费模型

成本陷阱：

• 带宽超出后按 $0.15/GB 计费（比 CDN 贵）
• Serverless 函数执行时间按量计费
• Image Optimization 按处理次数计费
• 小团队可能在 $20/人/月 上快速累计

2.3 Vercel 的局限性

2.4 适用场景

✅ 推荐使用 Vercel：个人项目、小团队 SaaS、面向全球用户、快速迭代

❌ 不推荐使用 Vercel：面向中国大陆用户、对成本极度敏感、需要 WebSocket/长连接、合规要求数据不出境

3. Docker 容器化部署

3.1 为什么需要 Docker

Docker 给你完全的控制权——你决定运行时版本、环境变量、资源分配、网络配置，不受任何平台限制。

3.2 多阶段 Dockerfile

生产级 Next.js Dockerfile 使用多阶段构建，最小化镜像大小：

# 阶段 1：安装依赖
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile
 
# 阶段 2：构建应用
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN corepack enable && pnpm build
 
# 阶段 3：生产镜像（只包含必要文件）
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]

镜像大小对比：

3.3 Docker 优化要点

3.4 Docker 部署目标

4. AWS 部署

4.1 AWS 上的 Next.js 部署方案

AWS 提供了多种方式部署 Next.js，从全托管到完全自管：

4.2 AWS Amplify：AWS 版的 Vercel

AWS Amplify 是 AWS 对标 Vercel 的产品，提供类似的开发者体验：

优势：如果团队已经在 AWS 生态中（RDS、S3、SQS 等），Amplify 可以与这些服务无缝集成，且数据不需要跨云传输。

劣势：Next.js 新功能的支持通常比 Vercel 晚 1-3 个月。

4.3 ECS + Fargate 架构

这是企业级 Next.js 在 AWS 上的标准架构：

用户请求
    ↓
Route 53（DNS）
    ↓
CloudFront（CDN + 缓存静态资源）
    ↓
Application Load Balancer（负载均衡）
    ↓
ECS Fargate（Docker 容器集群）
├── Task 1: Next.js container
├── Task 2: Next.js container
└── Task 3: Next.js container
    ↓
RDS（数据库）/ ElastiCache（Redis）/ S3（文件存储）

优点：

• 完全控制容器资源（CPU、内存）
• 自动扩缩容（根据 CPU/请求量）
• 与 AWS 服务深度集成
• VPC 网络隔离，安全合规

缺点：

• 配置复杂（ALB、Target Group、Task Definition、Service…）
• 初始设置耗时 1-2 天
• 需要 DevOps 知识

5. Cloudflare 部署

5.1 Cloudflare Pages

Cloudflare Pages 是 Cloudflare 的静态站 + Serverless 部署平台。对 Next.js 的支持通过 @cloudflare/next-on-pages 适配器实现。

5.2 OpenNext：通用的 Next.js 适配器

OpenNext 是一个开源项目，目标是让 Next.js 可以部署到任何 Serverless 平台（不只是 Vercel）：

OpenNext 的核心思路：将 Next.js 的 Serverless 函数、中间件、ISR 等功能拆解，映射到目标平台对应的能力上。

5.3 Cloudflare 的独特优势

6. 自托管方案

6.1 VPS + PM2

最传统的部署方式——在 VPS 上运行 Node.js 进程：

VPS (Ubuntu)
├── Nginx（反向代理 + 静态资源 + HTTPS）
├── PM2（进程管理 + 自动重启 + 日志）
└── Next.js（Node.js 应用）

6.2 Coolify：自托管的 Vercel

Coolify 是一个开源的自托管 PaaS，提供类似 Vercel 的体验：

• Git 推送自动部署
• Docker 容器化
• 免费 SSL（Let's Encrypt）
• 数据库管理（Postgres、Redis、MongoDB）
• 可以部署到任何 VPS

适合：想要 Vercel 体验但不想付费 / 数据不想离开自己服务器的场景。

7. 平台对比决策矩阵

7.1 功能对比

7.2 成本对比（月度估算）

注意：Vercel 在高流量时成本增长更快（带宽按量计费），而固定资源的方案（VPS、ECS）成本更可预测。

7.3 选型决策树

快速上线 + 小团队？ → Vercel
面向中国大陆？ → Docker + 国内云（阿里云/腾讯云）
已有 AWS？ → AWS Amplify 或 ECS
成本敏感 + 全球用户？ → Cloudflare Pages 或 Fly.io
需要 WebSocket？ → Docker（ECS/Fly.io）
合规要求？ → Docker + 私有云 / MinIO
学习 DevOps？ → VPS + Docker

8. 部署最佳实践

8.1 环境变量管理

8.2 健康检查

所有部署方案都应该配置健康检查端点：

• 容器编排需要它来判断容器是否健康
• 负载均衡需要它来决定是否转发流量
• 监控系统需要它来发送告警

8.3 蓝绿部署 vs 滚动更新

Vercel 默认使用即时原子部署（类似蓝绿）——新版本构建完成后瞬间切换，旧版本保留用于回滚。

本章小结

• output 模式：大部分应用用 standalone，纯静态站用 export，Vercel 用默认模式
• Vercel：Next.js 最佳部署目标，零配置但有锁定风险和成本限制
• Docker：完全控制，多阶段构建后镜像仅 ~100MB，适合企业和自托管
• AWS：小项目用 Amplify，企业用 ECS + Fargate，已有 AWS 生态的首选
• Cloudflare：免费带宽 + 全球边缘网络，但 Next.js 支持有限（需要适配器）
• 自托管：VPS + PM2 最便宜，Coolify 提供类 Vercel 体验
• 选型核心：面向全球用 Vercel/Cloudflare，面向中国用 Docker + 国内云，成本敏感用 VPS