go环境变量配置需关注读取时机、优先级和fallback逻辑：os.getenv只读进程环境变量，不解析.env；godotenv.load()须在main开头调用；viper优先级为viper.set()>命令行>环境变量>配置文件>setdefault()，且环境变量名默认转大写加下划线。
Go 程序里环境变量不是“读了就行”，关键在读取时机、优先级和 fallback 逻辑——错一步，本地跑通、线上炸锅。
os.Getenv 为什么总返回空字符串
直接调用 os.Getenv("DB_HOST") 却拿不到值，大概率不是代码写错了，而是环境变量根本没被加载进来。
- 它只读操作系统当前进程的环境变量，不解析
.env文件，也不自动加载配置文件 - 如果用
go run main.go启动，shell 中未export DB_HOST=localhost，就一定为空 - 容器中（如 Docker）若没用
env_file或environment显式注入，os.Getenv也查不到 - 注意：空字符串
""和未定义是两种状态，os.Getenv对未定义和空值都返回""，无法区分
godotenv.Load() 必须在 main() 开头调用
很多人把 godotenv.Load() 放在某个初始化函数里，结果发现环境变量还是没生效——因为 os.Getenv 只能看到调用时刻已存在的变量。
- 必须在
main()函数最开始执行，早于任何其他依赖环境变量的逻辑（比如数据库连接、日志配置） - 默认读
.env，路径可传参：godotenv.Load(".env.production") - 若文件不存在，默认静默失败；加
godotenv.Overload()可覆盖已有变量，但要小心冲突 - 不支持嵌套注释或内联注释：
DB_PORT=5432 # comment会导致解析失败
Viper 的优先级规则决定配置行为
Viper 不是“读哪个就用哪个”，它有一套明确的覆盖链。搞不清这个，就会出现“明明改了 .env，却还是用 YAML 里的旧值”这类问题。
- 优先级从高到低：
viper.Set()> 命令行参数 > 环境变量 > 配置文件 >viper.SetDefault() - 环境变量名默认转大写+下划线，例如
viper.Get("server.port")会查SERVICE_PORT（不是SERVER_PORT），除非调用viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_")) -
viper.AutomaticEnv()必须显式开启，否则即使你设了APP_ENV=prod，viper.GetString("app.env")也拿不到 - 读取失败时不会 panic，
viper.ReadInConfig()返回 error，但后续viper.Get()仍可能返回 nil 或零值，需配合viper.IsSet()判断
生产环境别依赖 .env 文件
容器或 systemd 场景下硬塞 .env 文件，等于把敏感配置明文暴露在镜像或宿主机上。
- Kubernetes 中应使用
envFrom: secretRef或configMapRef注入，而不是挂载.env文件再用godotenv - systemd service 文件里用
EnvironmentFile=/etc/myapp/env是可行的，但该文件权限必须是600，且不能由应用自己读取 - 真正需要的是“运行时确定来源”：开发用
.env，测试用 ConfigMap，生产用 Secret —— Viper 的多源能力才体现价值 - 所有配置最终都要落到结构体字段上，建议用
viper.Unmarshal(&cfg)而非一堆viper.GetString()，避免漏判类型或拼写错误
最容易被忽略的点：环境变量名大小写、Viper 的 key 转换规则、以及 godotenv 加载时机——这三处出错，90% 的配置问题就定位到了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
