让 AI 生成应用具备上线条件的检查清单

AI 写完应用，离上线还差一轮部署检查：环境变量有没有漏，服务能否被平台访问，启动命令是否正确，迁移会不会随每次启动重复执行。原文提供的价值，是把这些问题整理成了一段可以交给 AI 的检查指令。

但先说明一个缺口：标题承诺比较 Railway、Netlify、Vercel、Cloudflare、Render 和 Fly.io，并标注 Oct 2026 价格，提供的正文却没有平台对比、价格或测试结果。我们能解读的是部署准备清单，不能据此判断哪家平台更便宜、更适合你。

先让 AI 检查部署条件，再让它改代码

原文指令的第一句就限定了任务：为指定平台准备部署，不改变功能。最后又要求先展示 diff，再应用修改。

这两句很关键。部署修复容易蔓延成业务重构，而作者希望把改动限制在运行条件上，让开发者可以逐项审查。

检查首先覆盖环境变量：列出应用读取的全部变量，创建使用占位值的 .env.example，并确认 .env 已加入 .gitignore。前者告诉部署者需要配置什么，后者避免把实际配置误提交到仓库。

下面这段可以直接作为部署前检查的起点：

Prepare this app for deployment to [platform]. Do not change features.

List every environment variable the app reads. Create .env.example with placeholder values, confirm .env is in .gitignore.

Make the server listen on process.env.PORT and bind to 0.0.0.0, not localhost.

Confirm build/start commands are correct and the start command doesn't run a dev server.

Add a GET /health endpoint that returns 200 without touching external services.

Make migrations a separate step, not something that runs on every boot.

Pin the runtime version (engines field, .nvmrc, or .python-version). Show me the diff before applying.

重点看最后一句：AI 应先给出修改差异，开发者检查后再应用。[platform] 也需要替换成实际部署目标，原文没有替你完成平台适配。

能在本机启动，还不等于能被平台访问

原文要求服务监听 process.env.PORT，并绑定 0.0.0.0，而非 localhost。这里解决的是两个不同问题：端口从部署环境读取，监听地址允许服务接受运行环境外部转入的连接。

构建和启动也要分开检查。构建命令负责生成可运行产物，启动命令负责运行应用；原文明确要求启动时不能运行开发服务器。

运行时版本则通过 engines、.nvmrc 或 .python-version 固定。它们属于不同的版本声明方式，具体采用哪一种，还要看项目和平台是否识别。正文没有提供对应平台的配置示例。

这份清单关心的是应用能否按预期运行，而不仅是构建能否通过。

健康检查和数据库迁移为什么要单独处理

作者要求增加 GET /health，返回 200，且不访问外部服务。这样的接口可以回答一个范围有限的问题：应用进程能否响应 HTTP 请求。

它不能证明数据库、第三方 API 或完整业务链路正常。正文也没有说明是否需要另一套依赖检查，因此不能把这个接口当成全链路验收。

数据库迁移则被要求拆成独立步骤，不能每次启动都执行。把迁移绑在启动阶段，会让服务启动同时承担数据库结构变更；拆开后，两个动作更容易分别检查和安排。不过，原文没有给出迁移命令、执行时机或失败恢复方案。

我的判断

这是一份有用的部署检查提示词，但不是标题所说的平台选型文章。没有价格表、资源规格、计费条件和实测数据，就无法支持六个平台之间的推荐。

清单本身也有适用前提。process.env.PORT 和绑定地址的要求，主要面向自行启动 HTTP 服务的应用；纯静态前端以及由平台管理请求入口的函数，不能机械套用。健康检查应检查到哪一层，同样取决于平台如何使用它。

作者没有展示实际部署记录或修改前后的对照结果，所以这些属于操作建议，不能写成经过验证的部署成功方案。我会把它作为代码审查的起点，再结合目标平台的要求补齐配置。

能拿来做什么

• 给 AI 生成的 Node 服务做一次部署审查，要求它列出环境变量、构建与启动命令、端口配置和运行时版本，并先提交 diff。
• 检查 .env.example 是否覆盖应用实际读取的变量，同时确认 .env 已被 Git 忽略，减少上线时临时猜配置的情况。
• 对需要数据库迁移的项目，把迁移从启动命令中拆出来，明确由哪个部署步骤负责执行。
• 给常驻 HTTP 服务添加原文要求的 GET /health，同时把数据库和第三方服务的可用性留给另外的检查流程。