预发布环境与回滚
有两个习惯，把一次能优雅恢复的上线，和一次变成午夜恐慌的上线区分开来：在变更触达真实用户之前先在安全的地方测试它，以及能够即刻撤销一次糟糕的部署。
一个预发布（staging）环境只不过是你应用的第二份副本——同样的代码、独立的 、独立的（或一次性的）数据库——一个让你在生产之前先试一试的地方。大多数托管平台让这几乎免费：每一个 都自动获得它专属的预览 URL，于是你可以在合并之前点过一遍一个变更，并把它分享给某个人。对那些你没法轻易逆转的东西——比如一次数据库迁移——尤其要用它。
把这三个环境想象成一架变更要往上爬的梯子，而回滚就是那根能把生产环境直接落回上一个好梯级的绳子：
开发 ──▶ 预发 / 预览 ──▶ 生产
(笔记本) (PR预览URL) (真实用户)
试 点击体验 上线
随便试 分享 · 验证 ┌──────────────┐
│ deploy #42 │ ◀── 当前 (已坏)
├──────────────┤
回滚│ deploy #41 │ ◀── 最后正常版
│ ├──────────────┤
└──▶│ deploy #40 │
└──────────────┘
一条命令 / 一次点击 = 即时撤销
一次回滚是你对整个应用的撤销按钮。因为这些平台保留着此前的每一次部署，回到上一个好版本通常就是一条命令或一次面板点击：
# Cloudflare Pages: 重新部署一个已知良好的构建
wrangler pages deployment list
wrangler pages deployment rollback <DEPLOYMENT_ID>
# Vercel: 把一次之前的部署重新提升为生产环境
vercel rollback <DEPLOYMENT_URL>
在你需要它之前就知道这条命令，而不是在故障当中才去找。vibe coding 速度的全部意义在于发布很便宜——但只有当撤销发布同样便宜时，便宜的发布才让人感觉安全。