预发布环境（staging environment）是系统生产环境（production）的副本，用于在改动上线前先行验证。新功能、缺陷修复、内容和配置改动先部署到这里，让团队和企业在接近真实的条件下查看效果。有问题能提前发现，不必等客户遇到。
开发环境、预发布环境和生产环境
很多软件项目至少有三套环境。各团队叫法不一，但分工大致相同：
- 开发环境：开发人员编写和调试改动的地方，可以是个人电脑或共享的开发服务器，经常变动，功能也未必完整。
- 预发布环境：单独搭建、尽量贴近生产环境的副本，准备发布的改动先在这里验证再上线。
- 生产环境：客户和员工实际使用的系统，涉及真实数据、真实支付和真实消息。
预发布环境用来做什么
- UAT 和签收：业务用户可以用测试账户在这里进行用户验收测试，不影响正式记录。
- 回归测试：每次发布前，团队通过人工或自动化脚本确认原有功能依然正常，详见回归测试说明。
- 支付和系统集成验证：支付网关和不少第三方服务提供测试或沙箱（sandbox）模式，接入后即可走通预约、付款等完整流程，不会产生真实扣款。
- 内容预览：编辑可以在发布前检查新页面、版式或推广内容。
好用的预发布环境需要满足哪些条件
- 配置接近生产环境：在可行范围内使用相同的软件版本、配置和主要组件。两者差别越大，测试通过的参考价值就越低。
- 数据和凭据相互隔离：使用独立的数据库、账户、密码和 API 密钥，即使操作失误，也不会改动生产数据。
- 使用测试支付和沙箱密钥：支付、邮件和短信接口都指向测试或沙箱账户，而不是正式账户。
- 不对外公开：通过登录或 IP 白名单等方式限制访问，并设置搜索引擎不予收录。
- 部署流程与生产环境一致：两个环境采用同样的部署方式，确保验证过的版本就是上线的版本。
常见疏漏
- 与生产环境逐渐不一致：一边的配置、软件版本或数据结构改了，另一边没有同步，结果测试通过，上线后却出问题。
- 随意复制真实客户数据：把生产数据库复制过来，可能让更多人员和系统接触到个人信息，应尽量使用样本或匿名化数据。
- 邮件、短信或支付真的发了出去：如果仍连着正式服务，一次测试就可能给真实客户发消息或产生真实扣款。每个对外接口都要检查。
- 忘了禁止搜索引擎收录：预发布网站一旦被收录，就可能出现在搜索结果中，展示测试内容和重复页面。
以下示例仅用于说明：一家诊所的预约网站要增加在线定金功能。开发方先把改动部署到预发布环境，并接入支付服务商的沙箱。前台员工完成测试预约，用测试银行卡信息付款，并确认邮件只发到内部测试地址。验收通过后，同一版本才部署到使用正式支付配置的生产环境。
应该向开发方确认什么
小企业不必自己管理预发布环境，但值得向开发方问清楚：
- 系统有没有预发布环境？谁可以访问？
- 它和生产环境有多接近？如何保持同步？
- 它使用什么数据？会不会复制真实客户数据？
- 其中的支付、邮件和短信是否接入测试或沙箱服务？
- 它是否限制了公开访问，并禁止搜索引擎收录？
- 每次发布是否都先在这里验证？报价或支持服务是否包含这项工作？
上线后，网站监测负责关注生产系统的运行状况，软件支持 SLA 则可能写明改动如何测试和发布。如需了解服务范围，可以查看 technine.io 的网站与 Web 应用开发服务，其中包括 UAT 及上线验证。
常见问题
小网站需要预发布环境吗？
取决于网站改动的频率和用途。简单的信息类网站可能只需要内容预览；带有预约、支付、登录或系统集成功能的网站，通常更需要预发布环境，因为这些功能出错会直接影响客户。
预发布环境和测试环境是一回事吗？
不一定。有些团队混用这两个名称；也有团队另设供开发和 QA 使用的测试环境，再用贴近生产环境的预发布环境做最后验证和 UAT。可以向开发方了解每套环境的用途。
可以把生产数据复制到预发布环境做测试吗？
有时确实需要接近真实的数据，但复制真实客户记录会带来隐私和安全责任。应优先使用样本或匿名化数据，并限制可访问的人员；如果涉及个人信息，请向顾问确认相关责任。