Go应用应通过运行时环境变量（如ENV）动态控制配置加载，优先使用viper按环境读取配置文件、注入敏感字段，并区分开发与生产日志、调试行为及构建策略。
用 GODEBUG 或自定义环境变量控制配置加载
Go 本身没有内置的“环境模式”概念，靠的是开发者约定和启动时传入的环境变量。最常见做法是读取 ENV 或 GO_ENV 变量，再据此加载不同配置文件或启用不同行为。
别依赖编译期常量（比如 //go:build dev），因为构建产物无法动态切换环境；运行时判断才真正灵活。
-
ENV=dev go run main.go启动开发服务 -
ENV=prod go run main.go模拟生产启动 - 代码中统一用
os.Getenv("ENV")获取，建议 fallback 到"dev" - 避免硬编码字符串，定义常量如
const EnvDev = "dev"和const EnvProd = "prod"
配置文件按环境分离：config.dev.yaml vs config.prod.yaml
把数据库地址、日志级别、第三方 API 密钥等敏感/变动项抽离到配置文件，比散落在代码里更安全也更易维护。
注意不要把 config.prod.yaml 提交到 Git——加进 .gitignore，改用模板文件 config.prod.yaml.example 提示字段结构。
立即学习“go语言免费学习笔记（深入）”；
- 推荐用
spf13/viper加载：viper.SetConfigName("config." + env) viper.AddConfigPath(".") viper.ReadInConfig() -
开发环境可启用
viper.WatchConfig()热重载，但生产环境必须禁用 - 密码类字段（如
db.password）优先从环境变量注入：viper.AutomaticEnv()+viper.SetEnvPrefix("APP")
日志与调试行为按环境开关
开发时需要详细日志和 panic 堆栈，生产环境要收敛输出、避免泄露路径或变量名，还要对接日志采集系统。
关键不是“多打日志”，而是“打对日志”：开发环境用 log.Printf 快速验证；生产环境必须用结构化日志库（如 uber-go/zap），并关闭 caller 跟踪（zap.AddCaller() 在 prod 下关掉）。
- 开发环境默认开启
debug模式：HTTP 服务开pprof、SQL 日志打印完整语句 - 生产环境强制设置
GIN_MODE=release（如果用 Gin），否则会暴露堆栈到响应体 - 用
runtime/debug.Stack()捕获 panic 时，只在 dev 中打印全栈，prod 中只记录错误类型+时间戳
构建与部署阶段的环境校验
CI/CD 流水线里最容易出错的是：本地测试用 dev 配置跑通了，上线却忘了替换环境变量，结果连错数据库。
在 main() 开头加一层最小可行性检查，失败直接 os.Exit(1)，比让服务起来后报错更早暴露问题。
- 检查必填环境变量是否存在：
os.Getenv("DB_HOST") == ""→ 报错退出 - 生产环境禁止使用
sqlite或内存数据库：if env == EnvProd && cfg.DB.Driver == "sqlite" { log.Fatal("prod not allow sqlite") } - Docker 镜像构建时用多阶段：dev 阶段装
delve调试器，prod 阶段只保留二进制，不带任何调试工具
环境隔离真正的难点不在写多少 if-else，而在于所有团队成员对 “什么该进 Git、什么不该进、谁负责维护 prod 配置” 有共识。一个没被文档化的 .env 文件，可能比十个 bug 更难排查。
