最近，几乎每当提到“氛围编码”，
与AI代理交互后，网络服务代码就会迅速生成。

但有一件事情是不会改变的。

  • 如何划分服务器

  • 部署到哪里

  • 如何回滚和管理

这仍然是人的责任。
AI可以很好地写出“代码”，但无法代替处理“运营阶段的事故”。

在本文中，我将特别强调阶段性（staging）环境的重要性，并整理出在阶段性环境中必需检查的内容。

dev-staging-prod 链接图像

1. AI可以代替写代码，但部署仍然留给人

Commandbox 광고

当你对AI代理说：

“帮我用Next.js做一个简单的TODO网页应用”
“把这个API连接到PostgreSQL”

代码很快就会出来。
但AI不会首先告诉你这样的事情。

“现在我们不直接放到开发服务器，而是放到阶段性服务器上，
检查与生产环境相同的数据库/缓存/环境变量配置。”

因为如果提出问题和指令的人没有那方面的经验，
AI也不会朝那个方向去思考。

结果很多初学开发者：

  1. 只在开发服务器上看到代码能正常运行

  2. 然后直接上传到生产服务器

  3. 因数据库/缓存/环境变量/域名配置问题而崩溃 💣

之后才意识到“啊……阶段性测试就是这样的”。

2. 直接从开发环境到生产环境是危险的

“代码打包成Docker镜像，不就可以随处运行了吗？”
从表面上看是对的，但在实际运营中以下情况完全不同。

  • 连接哪个数据库

    • 开发环境：dev-db，生产环境：prod-db

    • 连接字符串、安全设置、帐户权限、数据量都不同

  • 缓存/消息队列

    • Redis、RabbitMQ、Kafka等，每个环境的地址、认证、容量不同

  • 环境变量

    • NODE_ENV、API_BASE_URL、PAYMENT_PROVIDER_KEY …

    • 在开发环境是空值或假数据，而在生产环境使用实际密钥

  • 外部集成

    • 支付、短信、电子邮件、SSO、外部API等

    • 开发环境是沙盒，生产环境是真实环境

尽管Docker镜像相同，但“环境”并不相同。
即使完成了Web应用，
也不能过分强调部署和运营是完全不同的领域。

因此，直接从开发环境上传到生产环境，
跟“功能测试在本地完成，马上进行真正用户的beta测试”并没有什么区别。

3. 为什么阶段性测试是必需的？

Commandbox 광고

阶段性测试（staging）简而言之为：

“与生产环境尽可能相似的排练舞台”

。

  • 与生产环境相同版本的应用程序

  • 与生产环境几乎相同的基础设施配置

  • 仅使用测试用数据・域名・账户

如果没有阶段性测试：

  • 在开发环境中正常运行的代码在生产环境中崩溃

  • 找到原因时，发现大部分是“环境差异”造成的

  • 每次都要进行紧急修复→立即重新部署到生产环境→又出现其他问题…

这样的恶性循环不断重复。

相反，良好的阶段性测试可以：

  • “此变更在实际运营环境中将如何呈现”
    可以提前目测

  • 基础设施设置、安全设置、数据迁移等，
    可以实际演练

  • 质量保证、计划、设计师、业务负责人等大家
    都可以提前检查运营前的界面和功能

特别是对于初学者：

  • 需要培养的是看整个运营环境而非仅仅是我的代码的眼光，

  • 这样的训练正是在阶段性环境完成的。

4. 在阶段性环境中必须检查的内容

那么在阶段性环境中需要关注什么呢？
逐项整理如下。

4.1 环境变量和配置值

  • DATABASE_URL

  • REDIS_URL / CACHE_URL

  • API_BASE_URL

  • SECRET_KEY、JWT_SECRET_KEY

  • 外部API密钥，webhook URL等

需要文档化“开发与生产配置的不同之处”，并检查阶段性环境是否遵循与生产相同的模式。

检查要点

  • 阶段性环境的env文件或者设置
    与生产环境结构是否相同

  • 敏感信息是否妥善隐藏在环境变量/密钥管理工具中

  • 设置值是否没有硬编码

4.2 数据库与数据迁移

  • 迁移脚本（prisma migrate、django migrate、migration.sql等）是否能够
    在与生产环境相似的数据结构中正常运行

  • 是否因索引、唯一约束、外键约束等原因产生错误

  • 假数据是否会对实际界面与流程造成问题

检查要点

  • 阶段性数据库是否有适量的测试数据
    （仅在空数据库进行测试意义不大。）

  • 在阶段性环境中练习回滚策略也很重要。

4.3 认证·权限·会话

  • 登录/注册流程

  • OAuth/SSO（Google, Kakao等）集成

  • 根据权限（角色）不同的界面·API行为

检查要点

  • 在阶段性环境中是否能够与实际运营相同的方式登录
    （是否存在临时的开发专用登录绕过逻辑）

  • 不同权限账号（管理员、普通用户等）
    的菜单/按钮/动作是否正常运作

4.4 外部集成：支付、短信、电子邮件、通知等

  • 支付（网关）→沙盒/测试模式

  • 短信/카카오通知 → 测试通道

  • 电子邮件发送 → 测试电子邮件，确保不发送给实际客户

检查要点

  • 在阶段性环境中是否使用真实的外部集成路径
    （但必须是测试账户，而不是实际客户）

  • 确认错误情况（支付失败、超时等）处理是否也正常

4.5 前端 + 后端集成操作

本地虽然前端和后端分别运行良好，
但在阶段性环境（使用实际域名/反向代理/SSL）时，可能会出现新的问题。

  • CORS设置

  • HTTPS/HTTP混合使用

  • Cookie域/安全设置

  • 反向代理（Nginx、Traefik等）的路径路由问题

检查要点

  • 基于阶段性URL，检查所有页面是否正常运行
    （确保没有隐藏的本地专用URL）

  • 在浏览器开发者工具的网络选项卡中，确认
    是否没有CORS, 301/302, 4xx/5xx错误

4.6 性能和资源使用量

在初期看似没有性能问题，
但在阶段性环境中进行稍微的负载测试时，可以提早发现问题。

  • API响应时间

  • 数据库查询次数，是否存在N+1查询

  • 缓存未命中时的性能

  • 内存/CPU使用情况

不一定需要复杂的负载测试工具。

  • 在阶段性环境中模拟多个用户角色进行几次使用，

  • 同时检查日志，查看是否有运行缓慢的部分，这样也可以是
    有意义的“迷你负载测试”。

5. 如何配置阶段性环境，应该从何开始？

一开始不必完美。
对于小型服务，可以这样开始。

5.1 最小配置示例

  • 开发环境

    • 本地开发环境（Docker Compose、本地数据库等）

  • 阶段性环境

    • 部署到与生产相同的云/平台

    • 域名：staging.example.com

    • 独立的数据库/缓存/存储

  • 生产环境

    • 实际客户使用的运营环境

部署管道也很简单：

  1. 合并到main → 自动部署到阶段性环境

  2. 在阶段性环境中进行质量检查/自我检查

  3. 推送特定标签（v1.0.0）→ 部署到生产环境

只要做到这一点：

  • 就能彻底阻止“从开发环境直接部署到生产环境”

  • 始终能够养成经过阶段性环境的习惯。

6. 初学者越要“过度”使用阶段性测试

大多数初学开发者往往忽视阶段性测试。

  • “在开发环境中运行得很好，没问题...”

  • “不知道在阶段性环境中该查看什么...”

但实际上，能力差异更多体现在如何稳定地处理运营和部署上，
而非代码质量。

  • 功能正常运行固然重要，

  • 服务不间断运行更为重要。

阶段性测试既是连接二者的安全装置，也是
开发者学习“服务运营视角”的最佳练习场。

在未来建设新的网络服务时，请试着这样做。

  1. 从设计开始，同时考虑生产与阶段性环境

  2. 还要确保部署自动化遵循阶段性→生产顺序

  3. 重要功能必须在阶段性环境中
    “如真实运营般”进行多次测试再上传至生产

在AI能够代替编写代码的时代，
设计和负责部署及运营的能力将成为更大的差异化。
阶段性测试是培养这种能力的最现实工具。