企业官网建设流程全解析

dev → test → staging → gray → prod

环境 = 同一套代码，在不同运行条件下的不同实例

目的：

1. 保护线上用户
2. 降低开发和发布风险
3. 让问题尽量提前暴露

本地环境 dev

开发者电脑上的运行环境

通过 npm / yarn 等打开开发服务器

用于 写代码、调试，可以debugger，打印控制台、打断点

在构建方面：不压缩、不混淆

测试环境 test

由于本地环境的差异大（Node版本、依赖），只有在自己电脑能跑

所以得有一个过渡-测试环境：模拟线上环境，但不对真实用户开放的环境

部署在服务器上，使用独立域名，接近线上的配置

例如

text.example.com

进行

• 前后端联调
• 功能测试
• 回归测试
• QA测试
• UAT 产品验收

VITE_API_BASE=https://test-api.example.com

if (import.meta.env.MODE === 'test') { enableDebugPanel(); }

预发布环境 staging

上线前最后一次、最接近真实线上环境的验证环境

一般是内部人员的真实数据（test是QA和研发，现在是其他例如产品等）

域名、环境等等都和 prod 一样

灰度 gray

新功能、新版本并不会一次性全量上线，而是只对一部分用户或环境先生效，观察效果稳定后再逐步扩大范围，最终全量发布

小范围试水 → 验证安全 → 再全面放开

• 黑：旧版本（完全没变）
• 白：新版本（全部用户都用）
• 灰：介于两者之间

作用

• 降低发布风险
• 验证真实用户行为：本地/测试环境都不是真实用户
• 支持快速回滚：只需要关闭灰度开关或把比例调回到0

如何实现

1. 按「用户」灰度

常见方式：

• 按 userId 哈希取模
• 按账号白名单
• 按新用户 / 老用户

**userId** % 100 < 5 → 5% 用户走新逻辑

1. 按「流量」灰度（网关/Nginx）

• 10% 请求 → 新服务
• 90% 请求 → 旧服务

split_clients $request_id $version { 10% new; * old; }

1. 功能开关（Feature Flag）

是否开启由：

• 后台配置
• AB平台
• 配置中心（如 Apollo / Nacos）

if (featureFlags.newPayFlow) { renderNewPay() } else { renderOldPay() }

线上环境 prod

真实用户正在使用的环境

• 用户访问的网站
• APP请求的接口
• 真正产生业务数据

错误不能暴露给用户

在构建阶段会进行压缩、混淆

日志非常精简

// 线上禁止 console.log if (import.meta.env.PROD) { console.log = () => {}; }

VITE_API_BASE=https://api.example.com

不能随便进行调试、发布

徐岙发布流程 + 回滚机制

发布流程

本地环境 ↓ 测试环境（CI 自动部署） ↓ 回归测试 / 产品验收 ↓ 线上环境（灰度 / 全量）

1. 本地 pnpm dev
2. 提 PR → 自动部署到 test
3. QA 验证
4. 合并 main → CI 部署 prod（production 生产环境，用户正在真实使用的环境）

找出本地和线上的差异点

1. 环境变量不同

.env.development 和 .env.production

如 API_BASE_URL

可以用console.log(import.meta.env)/console.log(process.env)查看

1. 打包产物和本地运行逻辑不同

线上问题可能出现在

• 某个函数被错误地 tree-shake 掉了
• CDN 缓存未更新、版本不一致

解决：本地执行一次真实打包

npm run build npx serve dist

1. 环境差异：浏览器版本

使用错误出现的环境尝试复现

Babel polyfill 补齐

1. 网络

查看开发者工具的网络

对比 CORS 的响应头查看是否是跨域问题

对比一下 Cookie

1. 后端的线上逻辑与本地不一致