build tags 不是用来做配置切换的，它只让文件在编译时彻底消失，而非运行时控制行为；如数据库地址、日志级别等必须由 viper + 环境变量在运行时决定。
build tags 不是用来做配置切换的
直接说结论：//go:build prod 这类标签**不能也不该**用来控制“加载哪个数据库地址”或“日志级别设为 debug 还是 info”。它只负责让某些文件在编译时彻底消失，不是运行时配置开关。
常见错误是写一个 config_prod.go 和 config_dev.go，都定义 func NewConfig() *Config，然后靠 go build -tags=prod 选一个。问题在于：一旦编译完成，二进制就锁死了所有环境逻辑 —— 你没法用同一个二进制在 staging 环境里跑，也没法在容器里通过环境变量临时切到 debug 模式。
更危险的是测试盲区：本地 go run -tags=dev 能过，但 CI 打的 -tags=prod 二进制可能因某处 TLS 字段没校验而启动失败，错误被拖到部署时才暴露。
viper.SetConfigName + ENV 是运行时切换的核心
真正该由环境决定的行为（比如连哪个 DB、是否上报 metrics），必须在运行时解析，而不是编译期剔除。viper 的 SetConfigName 配合 os.Getenv("ENV") 是最轻量也最可控的方式。
- 约定配置文件名格式为
config.dev.yaml、config.prod.yaml，公共字段可抽到config.base.yaml - 启动前必须调用
viper.SetConfigType("yaml")，否则扩展名缺失会报Unsupported Config Type "" - 不要多次调用
ReadInConfig()—— viper 会 merge，不是替换，容易污染配置 - 共用基础配置时，先
viper.MergeConfigFile("./configs/config.base.yaml")，再ReadInConfig()，顺序不能反
build tags 的正确使用场景
build tags 唯一适合的地方，是那些**编译期就必须排除、否则根本无法通过检查的代码**，比如平台专属实现、调试工具、cgo 依赖。
-
dlv_debug.go顶部写//go:build dev，里面 importgithub.com/go-delve/delve/cmd/dlv—— 生产构建时这个文件不参与编译，二进制里没有 dlv 任何符号 -
db_sqlite_linux.go写//go:build linux,cgo，引用mattn/go-sqlite3；db_sqlite_darwin.go写//go:build darwin，用纯 Go 的modernc.org/sqlite - 绝不能在一个文件里混写
if runtime.GOOS == "linux"和import "golang.org/x/sys/windows"—— 后者会让 macOS 编译直接失败
敏感字段必须从环境变量读，YAML 里不留密钥
配置文件里出现 password: "my-secret" 是高危操作。即便用了多环境 YAML，只要提交到 Git，密钥就已泄露。
正确做法：
- YAML 中留空或删掉敏感字段：
db:password: "" - 启动前注入环境变量：
DB_PASSWORD=xxx go run main.go - 配合
viper.AutomaticEnv()和viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，让viper.GetString("db.password")自动映射到DB_PASSWORD - 永远不要手动调用
os.Getenv("DB_PASSWORD")—— 这绕过了 viper 的优先级链（flag > env > file > default），失去兜底能力
最易被忽略的一点：viper 不会自动把 server.port 映射到 SERVER_PORT，除非你显式调用 SetEnvKeyReplacer。没这行，环境变量就等于白设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
