学习目标
- 理解配置在工程中的真实角色
- 区分配置文件与环境变量的职责边界
- 掌握多环境配置的常见治理方式
- 避免“配置地狱”的工程陷阱
一、为什么配置管理是工程问题
很多系统故障并不是代码 bug，而是：
- 配置错误
- 配置不一致
- 配置无法回溯
工程认知：
代码解决“怎么做”，配置决定“怎么跑”。
二、什么是配置，什么不是配置
配置是：
- 可变的运行参数
- 环境相关的信息
- 不应写死在代码中的值
配置不是：
- 业务规则
- 流程控制逻辑
- 复杂条件判断
工程结论：配置只能“调参”，不能“写逻辑”。
三、配置文件 vs 环境变量
配置文件适合：
- 结构化配置（DB、缓存、服务地址）
- 本地开发与调试
- 复杂配置组合
环境变量适合：
- 环境区分（dev / test / prod）
- 敏感信息（token / password）
- 容器与云环境
工程共识：配置文件 + 环境变量 组合使用。
四、常见配置加载方式
最基础方式：
type Config struct {
Port int
DB string
}从文件加载：
- JSON / YAML / TOML
从环境变量覆盖：
- 优先级高于文件
工程建议：配置加载逻辑集中管理，避免散落。
五、多环境配置治理
常见环境：
- dev（开发）
- test / staging（测试）
- prod（生产）
常见模式：
- 单一配置文件 + 环境变量覆盖
- 多配置文件（config.dev.yaml / config.prod.yaml）
工程建议：
- 避免复制粘贴大量配置
- 只让“差异”体现在环境层
六、配置校验的重要性
配置加载成功 ≠ 配置正确。
必须做的事情：
- 必填项校验
- 取值范围校验
- 启动阶段 fail fast
工程结论：配置错误，宁可启动失败，也不要带病运行。
七、配置热更新的工程边界
并不是所有配置都适合热更新。
适合热更新：
- 限流参数
- 开关类配置
不适合热更新：
- 数据库连接信息
- 核心依赖地址
工程认知：热更新增加复杂度，必须权衡收益。
八、配置与代码的解耦
反模式：
- 代码里直接读取环境变量
- 配置散落在各个 package
推荐模式：
- 启动阶段统一加载配置
- 以结构体形式传递
工程结论：业务代码不应该“知道配置从哪来”。
九、配置管理的常见坑
- 配置项无限增长
- 缺少默认值与说明
- 生产环境手工改配置
工程结论：配置混乱，是系统失控的前兆。
十、配置管理总结
- 配置是系统的一部分
- 配置必须可管理、可回溯
- 配置错误要尽早暴露
一句话总结：
稳定系统，先从稳定配置开始。
预告：Day 30｜Go 工程实践总览与进阶路线
下一天将系统总结：
- 30 天学习内容回顾
- 从“会写 Go”到“写好 Go”
- 真实工程中的进阶方向
- 个人 Go 技术成长路线建议