结论是：Gin不参与打包部署，决定多环境行为的是viper配置加载逻辑+CGO_ENABLED=0 GOOS=linux编译参数+Docker多阶段构建三者缺一不可；硬编码配置、init()加载或镜像内留YAML文件均属高危操作。
直接说结论：Gin 本身不参与打包部署，真正决定多环境行为的是 viper 配置加载逻辑 + CGO_ENABLED=0 GOOS=linux go build 编译参数 + Docker 多阶段构建，三者缺一不可。硬编码配置、用 init() 加载、或在镜像里留 YAML 文件，上线后基本等于埋雷。
怎么让 gin-app 启动时自动读对 config.prod.yaml 而不是 config.dev.yaml
关键不在 Gin，而在你调 viper.ReadInConfig() 前怎么设名和路径。常见错误是写死 viper.SetConfigName("config.dev") 或只加一个 viper.AddConfigPath("./config")。
- 统一用
os.Getenv("ENV")控制配置名：viper.SetConfigName("config." + env)，启动时传ENV=prod go run main.go - 路径要加全：
viper.AddConfigPath("/etc/myapp/")、viper.AddConfigPath("./config")、viper.AddConfigPath(".")，避免因工作目录不同导致找不到文件 - 必须关掉
init()—— 单元测试里没法重设ENV，一跑就 panic - 开发时用
viper.SetConfigType("yaml")，生产环境建议跳过文件，直接走viper.AutomaticEnv()+viper.SetEnvPrefix("APP")，靠 K8s ConfigMap 注入APP_DATABASE_URL这类变量
为什么 go build 出来的二进制在 Alpine 容器里跑不起来
典型报错：standard_init_linux.go:228: exec user process caused: no such file or directory。这不是路径问题，是动态链接库缺失 —— 默认 go build 生成的二进制依赖 glibc，而 Alpine 用的是 musl libc。
- 编译时必须加
CGO_ENABLED=0：禁用 CGO，生成纯静态二进制 - 显式指定目标系统：
GOOS=linux GOARCH=amd64（或arm64，看集群架构） - Dockerfile 里别用
FROM golang直接运行，要用多阶段：构建阶段用golang:1.21-alpine，运行阶段切到alpine:latest或scratch - 如果非要用 CGO（比如连 Oracle），就得换基础镜像为
debian:slim或ubuntu:22.04，体积翻 3 倍起
Deployment 里 livenessProbe 失败但服务明明在跑
现象：K8s 不断重启 Pod，kubectl logs 看日志一切正常，curl localhost:8080/health 也返回 200。问题往往出在 Gin 的启动模式和 probe 路径处理上。
立即学习“go语言免费学习笔记（深入）”；
-
router.Run(":8080")是阻塞调用，probe 请求发来时，server 可能还没完全 bind 成功 —— 必须设initialDelaySeconds: 15，不能信 “秒级启动” 的宣传 - 健康接口别用
c.Status(http.StatusOK)就完事，要真检查依赖：if err := db.Ping(); err != nil { c.AbortWithStatus(http.StatusServiceUnavailable) } - 确保路由没被中间件拦截：/health 路由要注册在最外层，别套在
router.Group("/api")里，否则路径变成/api/health，probe 就 404 - Gin 默认不启用
gin.ReleaseMode，开发模式下会打印大量调试信息，可能干扰 probe 解析 —— 生产镜像启动前务必加gin.SetMode(gin.ReleaseMode)
最易忽略的一点：viper 配置字段校验必须在 router.Run() 之前做。比如 database.url 为空，服务照样能 bind 端口、响应 /health，但第一个 API 请求进来时才 panic —— 此时 livenessProbe 已经通过，K8s 认为它“活得好好的”，直到流量打进来才雪崩。
