SOLO-CREATE
部署托管

Workflow

如何用 Vercel 部署第一个 Web 产品

从环境变量、预览部署到正式域名的上线检查。

结论

Vercel 是 Next.js 产品的最快上线路径。

Vercel 部署示意图

为什么大多数 Next.js 项目会先选 Vercel

Vercel 的优势不只是“能部署”,而是它对 Next.js 的默认理解比较完整。对于独立开发者来说,这会直接减少很多不必要的配置时间。

它最有价值的地方有四个:

  1. 导入仓库就能得到预览部署。
  2. 环境变量配置比较直接。
  3. 每次提交都能生成新的预览链接。
  4. 绑定域名和回滚都比较顺手。

最小部署流程

1. 先保证本地构建成功

部署前先跑:

bash
npm run build

如果本地都过不了,先不要急着上线。优先解决依赖、环境变量和路由问题。

2. 导入仓库

在 Vercel 里选择项目仓库后,确认框架识别为 Next.js。大多数情况下,它会自动猜对构建命令和输出目录。

3. 配置环境变量

最常见的就是这些:

env
NEXT_PUBLIC_SITE_URL=https://your-domain.com
NEXT_PUBLIC_SUPABASE_URL=https://your-project-ref.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

如果你后面还接了邮件、支付或分析,也要一并加上。

4. 看预览部署

预览部署的意义不是“看能不能打开”,而是提前发现:

  1. 页面是否缺变量。
  2. API 路由是否报错。
  3. Server Component 是否引用了浏览器 API。

5. 绑定正式域名

正式域名上线后,必须同步检查:

  1. 域名是否已在 Vercel 中加入。
  2. Cloudflare DNS 是否指向正确。
  3. NEXT_PUBLIC_SITE_URL 是否已经切到正式域名。

常见错误

环境变量没同步

本地可跑,不代表线上可跑。很多故障都来自“本地 .env.local 有值,Vercel 没配”。

域名切换后还在用旧地址

如果你改了正式域名,Supabase、OAuth 和站点里的回调地址都要同步改。

预览部署和生产部署混用

预览环境只适合测试,不要拿它当正式环境基准。

一套比较稳的发布顺序

  1. 本地通过 build。
  2. 提交到 Git 仓库。
  3. 生成预览部署并检查。
  4. 配正式域名。
  5. 改生产环境变量。
  6. 再跑一次真实访问链路。

验证方式

上线后至少确认这些项:

  1. 首页是否能打开。
  2. 登录、表单和 API 是否正常。
  3. 域名是否是正式域名。
  4. sitemap 是否可访问。

参考