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 提示字段结构。
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") }
delve 调试器,prod 阶段只保留二进制,不带任何调试工具
环境隔离真正的难点不在写多少 if-else,而在于所有团队成员对 “什么该进 Git、什么不该进、谁负责维护 prod 配置” 有共识。一个没被文档化的 .env 文件,可能比十个 bug 更难排查。