Codex 部署 Vercel 前检查什么

Codex 帮你改完代码后，部署到 Vercel 不是最后一步，而是另一轮检查的开始。新手最容易犯的错，是本地看起来能跑就直接发布，结果线上构建失败、环境变量缺失、页面空白或客户不知道怎么验收。

这篇仍是草稿。发布前需要人工核对 Vercel 官方文档、当前项目脚本、部署截图和真实回滚流程。

适合谁

适合已经用 Codex 修改过前端项目，并准备把练习项目或客户测试项目部署到 Vercel 的新手。你需要会看 git diff，会运行本地构建命令，知道部署前要先确认环境变量和分支。

也适合准备接“帮我部署到 Vercel”这类小单的人。部署本身可能很快，但部署前的检查、客户授权和验收边界必须说清楚。

不适合谁

不适合一上来就处理客户生产站、商业域名、支付回调、登录系统、数据库迁移或组织级 Vercel 账号的人。这些场景牵涉权限、费用、隐私和回滚责任，新手不应该独立操作。

如果客户只给一句“deploy it”，但没有提供仓库、构建命令、环境变量说明、目标分支和验收标准，不适合直接报价或开工。

部署前先检查什么

先从本地项目开始，不要直接依赖平台提示。重点看这些项目：

1. package.json 里是否有明确的 build 脚本。
2. 本地 npm run build 是否通过。
3. 是否新增环境变量，变量名是否已记录，值是否不该提交到仓库。
4. 是否有图片、字体、静态文件路径大小写问题。
5. 是否改动路由、sitemap、robots、canonical 或 SEO 相关逻辑。
6. 是否有 API、数据库、鉴权、支付或第三方服务依赖。
7. 是否能通过预览链接验收，而不是直接替换生产站。

这些检查看起来琐碎，但能把很多线上问题挡在发布前。

具体步骤

1. 用 git status 和 git diff 确认本次部署包含哪些改动。
2. 运行项目已有检查，例如 lint、测试、类型检查和构建。
3. 列出所有环境变量，只记录变量名和用途，不记录敏感值。
4. 确认目标分支、预览环境和生产环境的区别。
5. 如果是客户项目，让客户在平台内完成必要授权，不要把账号密码发给你。
6. 先生成预览部署，让客户按页面、表单、移动端和核心流程验收。
7. 记录部署 URL、提交 SHA、检查命令和已知限制。
8. 生产发布前准备回滚方案，至少知道上一版部署在哪里。

可以复制的部署检查表

Vercel 部署前检查

项目仓库：
目标分支：
本次提交：
构建命令：
本地构建结果：
新增环境变量名称：
预览链接：
需要客户确认的页面：
需要客户侧授权的事项：
回滚方式：
未验证风险：

本地常用检查命令：

git status
git diff
npm run lint
npm run build

如果项目还有测试脚本，也要先运行。没有测试脚本时，要写清楚“未覆盖自动化测试”，不要把构建通过说成全流程通过。

做项目时怎么定范围

部署单可以分成三段：第一段是部署前诊断，确认项目能不能构建；第二段是预览部署，给客户一个可验收链接；第三段才是生产发布或域名配置。

新手更适合先做前两段。生产发布、域名、团队账号、计费设置和敏感环境变量，应该让客户在自己的账号里完成或明确授权后再处理。

风险提醒

不要提交 .env、token、私钥、客户数据或本地缓存。不要在没有客户确认的情况下改生产域名。不要把预览环境当成生产环境，也不要把生产发布当成一个普通按钮。

如果部署牵涉数据库迁移、支付回调、登录权限、组织账号、费用账单或客户域名 DNS，需要人工复核，并把客户侧授权事项列入明日待办。

明日待办

• 人工核对 Vercel 官方部署、环境变量和回滚说明。
• 准备一张预览部署验收截图，确保不含客户信息。
• 写一份客户侧授权清单：仓库、Vercel 项目、环境变量、域名。
• 检查是否需要把生产发布拆成单独服务范围。

可以继续看的内容

• Codex 工具页
• 项目报价助手
• 模板下载

免责声明

本文仅供学习和部署前检查参考，不构成官方文档、法律建议或职业承诺。涉及客户账号、域名、环境变量、账单和生产环境时，需要明确授权与人工复核。

CTA：部署前可以先用 报错解释器 整理构建日志，再用 Proposal 生成器 写出预览部署和生产发布的边界。