在我这好好的，上线就挂

每个开发都听过这句话：「我本地跑得好好的啊。」然后一上生产就出问题。翻来覆去查，最后往往不是代码逻辑错了，而是本地和生产的配置、环境根本不是一回事。

这类问题反复出现，根子通常在于配置和代码搅在一起、几套环境各管各的。把这件事理顺，能挡掉一大批线上事故。

环境不一致带来的 bug，最难查也最没必要——它本可以在写代码时就被规则挡掉。
本文核心知识点
  • 配置与代码分离同一份代码，不同环境配不同值。
  • 环境变量运行时注入，不写死在代码里。
  • 多环境开发、测试、生产尽量一致。
  • 配置中心集中管理、可审计变更。
  • 敏感配置密钥不进代码库、不进日志。
配置管理示意：蓝色渐变背景中央一个发光的中央配置文档卡片（空白横线占位条），从它向下分叉出三条发光管道分支连向三个并排的发光显示器环境方框，管道上有流动光点，扁平科技插画
一份中心配置向下分发到多套环境，而不是每个环境各配各的。

配置和代码，本该分开

同一份业务代码，在开发环境连测试库、在生产连正式库，这是再正常不过的事。既然环境之间必然不同，就该把「会随环境变的东西」和「各处都一样的代码」彻底分开。

属于代码属于配置
业务逻辑、算法数据库地址、端口
通用流程外部服务地址
不随环境变的常量开关、阈值、账号密钥

分开之后，同一份构建产物就能在不同环境间搬，不必每环境重新打包。

多环境到底差在哪

开发、测试、生产三套环境，差异主要落在几类东西上。把这些差异列清楚，才知道要隔离什么。

# 环境差异清单
- 依赖：数据库、缓存、外部服务的地址与版本
- 配置：开关、超时、限流阈值
- 数据：测试库是模拟数据，生产是真实数据
- 权限：谁能改、谁能看
# 目标不是让三套环境完全一样，而是把差异收敛到配置这一层。

代码在三套环境里应该完全一致，变化只通过配置体现。

配置从哪里读：环境变量与配置中心

配置怎么进程序？最简单的是环境变量，稍复杂就上配置中心。两者都要遵守一个原则：配置在运行时注入，而不是写死在代码或打包进镜像。

方式适用
环境变量少量、简单的配置，本地起步
配置文件按环境区分配置较多、需要分文件管理
配置中心多服务、多环境、需要动态更新与审计

无论哪种，都要保证改配置有记录、可追溯，而不是谁在生产机器上手改一把。