os.Getenv读不到环境变量是因为加载时机错误：必须在main()开头、Gin实例创建前完成godotenv.Load()或系统环境设置，否则返回空字符串，导致硬编码端口或panic。
os.Getenv 读不到环境变量？加载时机错了
不是 Gin 本身有问题，而是 os.Getenv 调用太晚了。Gin 的 r.Run() 启动前，所有配置（包括端口、数据库地址等）必须已就绪；如果环境变量在容器启动后才注入，或 .env 文件没提前加载，os.Getenv("PORT") 就返回空字符串，导致硬编码端口或 panic。
常见现象：r.Run(":8080") 硬编码端口、database_url 为空导致 panic。
-
godotenv.Load(".env")必须放在main()最开头，且路径要对（默认从当前工作目录找） - 若使用 Docker，确保
ENV指令写在CMD之前，或通过docker run -e PORT=8081显式传入 - Kubernetes 中，
envFrom: configMapRef或secretRef必须在容器启动前完成挂载，否则进程读不到
用 viper 读取环境变量并覆盖配置文件值
Viper 支持自动绑定环境变量到结构体字段，比手写 os.Getenv 更安全、可维护性更强。它默认不开启自动绑定，需显式调用 viper.AutomaticEnv() 并设置前缀。
典型用法：
v := viper.New()
v.SetConfigName("config")
v.SetConfigType("yaml")
v.AddConfigPath("configs/")
v.AutomaticEnv() // 启用环境变量读取
v.SetEnvPrefix("APP") // 所有环境变量加 APP_ 前缀，如 APP_PORT
v.BindEnv("server.port", "PORT") // 显式绑定字段到特定变量名
v.ReadInConfig()
- 环境变量名会自动转为大写 + 下划线，如结构体字段
Server.Port对应APP_SERVER_PORT -
v.BindEnv("server.port", "PORT")可绕过前缀，直接映射到裸变量名PORT - 优先级：环境变量 > 配置文件 > 默认值（viper 默认行为）
Gin 启动时如何安全读取 PORT 并 fallback
不要直接 os.Getenv("PORT") 后拼接字符串传给 r.Run()，容易因空值 panic。应做类型转换和 fallback 处理。
推荐写法：
port := os.Getenv("PORT")
if port == "" {
port = "8080"
}
r.Run(":" + port)
- 避免写
r.Run(":" + os.Getenv("PORT"))—— 若PORT为空，实际调用的是r.Run(":")，Go net/http 会 panic - 更健壮的做法是用
strconv.Atoi校验端口号是否为合法整数（0–65535），非法则 fallback 或 exit - 若用 viper，建议统一走
v.GetInt("server.port")，它自带默认值和类型安全
Docker/K8s 中环境变量注入的常见坑
本地 .env 能用，但部署后环境变量消失，90% 是镜像构建或运行时注入阶段出了问题。
- Dockerfile 中
ENV是构建期生效，无法覆盖运行时docker run -e传入的值；应优先依赖运行时注入 - Alpine 镜像中，
sh不支持export VAR=value的写法，要用ash -c 'export VAR=value; exec "$@"'包裹启动命令 - K8s 的
envFrom如果引用了不存在的 ConfigMap，Pod 会卡在 Pending 状态，不会报错但变量为空 —— 查kubectl describe pod看 Events - CI/CD 流水线里，Secret 变量默认不打印也不透出，确认是否真被注入进构建环境（如 GitHub Actions 的
secrets需显式env:传递）
最易被忽略的一点：环境变量名大小写敏感，PORT 和 port 是两个变量，而 Windows 默认不区分，Linux/macOS 区分 —— 本地开发没问题，一上服务器就失效。
