📚 课程目录第4章构建环境搭建

构建环境搭建：开发、测试、预发布环境的配置与差异处理

聊到环境搭建，我见过太多团队在这上面栽跟头。开发本地跑得欢，测试环境也绿了，一到预发布就炸，生产上线更是心惊胆战。说白了，环境不一致就是罪魁祸首。

为什么要分三个环境？你想想看，如果在开发环境做全量回归，那还谈什么持续集成。如果把预发布和生产混用，改个配置就可能把线上搞崩。我个人的习惯是：环境隔离越彻底，后期痛苦越少。

  核心原则：每个环境追求“最小的差异，最大的隔离”。开发环境灵活，测试环境可靠，预发布环境仿真。

开发环境（Dev）—— 快是第一要义

开发环境要的是什么？快速启动、快速调试、快速验证。数据库能用 H2 就别用 MySQL，中间件能用嵌入式就别起独立服务。我早期做过一个项目，开发环境必须连远程的 Oracle，每次改表结构都得 DBA 审批，一天迭代三个版本都是奢望。

典型配置：

数据库：H2 或 Docker 本地 MySQL，初始化脚本自动执行
缓存：本地 Redis 或内存模拟（如 Redisson 的 LocalCache）
日志：DEBUG 级别，输出到控制台 + 本地文件
认证：跳过 OAuth，使用测试直接模拟用户
静态资源：本地打包，不依赖 CDN

# 开发环境 application-dev.yml
spring:
  datasource:
    url: jdbc:h2:mem:testdb
  redis:
    host: localhost
  security:
    oauth2:
      enabled: false
logging:
  level:
    com.yourcompany: DEBUG

避坑指南：开发环境的配置不要硬编码在代码里。我曾经见有人把 dev 数据库密码写在配置类里，结果 merge 到 master，测试环境直接用了 dev 的数据——测试全乱套。

测试环境（Test）—— 要稳，要可复现

测试环境是自动化的主战场。记住一点：用例可以跑不过，但不能因为环境配置导致“假失败”。我在项目中遇到过，测试环境因为开发同事临时改了 Redis 密码，导致整个回归套件全部超时——排查了半小时才发现是密码不一致。

配置要点：

数据隔离：每次构建前重建测试数据库，保证数据干净
模拟服务：第三方接口用 Mock 或 WireMock，避免依赖真实系统
资源限制：与生产不同，CPU/内存可以适当缩小，但不要压榨太狠
配置版本化：所有环境参数都存 Git，不要靠“口口相传”
启动脚本：统一用 Docker Compose 或 K8s 编排，避免“在我机器上能跑”

项目	开发环境	测试环境
数据库	H2 / 本地 MySQL（单机）	独立 MySQL 实例，自动建库建表
测试数据	开发人员手工造	自动化脚本填充，含边界值
第三方服务	可跳过或 Mock	WireMock + 契约测试
监控报警	可关闭	开启基础指标（失败率、响应时间）

特别注意：测试环境不能和生产共享数据库或消息队列。我曾经遇到过测试批量写入导致生产队列堵塞的惨剧，愣是恢复了一天。

预发布环境（Staging）—— 最后一道防线

预发布环境说白了就是“旗舰版测试区”。它要尽可能接近生产：相同的操作系统、相同的中间件版本、相同的部署拓扑。但注意，不是完全复制——成本不允许。

我建议预发布环境至少做到：

网络拓扑：和生产同 VPC 或同集群，但用独立的命名空间
配置参数：特性开关、限流阈值、缓存策略均与生产同步
数据：脱敏后的生产副本（或部分切流），保证数据量级和分布一致
灰度验证：预发布环境本身可以承载少量真实流量（如 canary 部署）

# 预发布环境 application-staging.yml
spring:
  datasource:
    url: jdbc:mysql://staging-db:3306/yourdb?useSSL=true
  redis:
    host: staging-redis-cluster
    password: ${STAGING_REDIS_PASSWORD}
feature:
  new-payment-flow: true   # 和生产同步开启
  legacy-api-version: v2   # 灰度比例通过配置中心下发

听我一句劝：预发布环境千万别和生产共用数据库实例。哪怕只读权限，也可能因为慢查询拖垮生产。我曾经见过一个团队，预发布的定时任务把生产订单表扫崩了——就因为配置中心的数据库连接指向了同一个集群。

差异处理策略：把不一致关进笼子

三个环境不可能完全一致，但我们必须把差异显式管理起来。我常用的三板斧：

环境变量驱动：敏感信息（密码、密钥）永远不落配置文件，通过 CI/CD 变量注入
构建时 Profile：Maven/Gradle 的多 Profile 机制，一个构建产物支持多环境
运行时配置中心：Nacos、Apollo、Spring Cloud Config，动态调整无需重启

  核心公式：

  环境差异 = 配置内容差异 + 基础设施差异 + 数据差异。

  我们能控制的只有配置内容差异，后两项必须通过自动化工具强制对齐。

举个例子，我们团队有一个 environment.properties 模板：

# environment.properties (模板)
app.name=your-system
app.version=${project.version}
db.url=__DB_URL__
db.username=__DB_USER__
db.password=__DB_PASS__
redis.host=__REDIS_HOST__
feature.flag.new-ui=__NEW_UI_ENABLED__

CI/CD 运行时会根据目标环境替换占位符。这种做法比每个环境维护一个完整配置文件更安全——你永远只维护一个模板和一个环境差异清单。

环境流转与检查清单

来看看这张图，它概括了从开发到生产的全流程，以及每个环节的关键控制点：

上图中，实线是代码/制品的正向流动，虚线代表差异处理策略反向约束所有环境。你想想看，如果预发布环境的配置和生产差了5个参数，那灰度验证还有什么意义？

我自己维护了一个环境差异矩阵，每次迭代发布前都会逐项检查：数据库版本、中间件版本、JVM参数、超时时间、日志级别、安全策略。建议你也养成这个习惯。

避坑清单（我踩过的坑）

开发环境用 HTTPS 但测试环境用 HTTP，导致代码中的重定向逻辑失效
预发布环境的 Redis 密码和生产一模一样——暴露了安全风险
测试环境跑全量回归时，因为磁盘不足导致数据库写入失败，误以为是代码 bug
环境间的配置文件名冲突：dev 和 staging 都读了 application.yml 中的相同配置，导致覆盖

最后说一句，环境搭建没有银弹。但做到“显式管理、自动化校验、最小差异”，大部分问题都能提前暴露。嗯，现在就去检查一下你们项目的环境配置吧。