直接用golang:latest打包的镜像不能上生产，因其体积大、含调试符号、root权限运行、未分离配置，易引发启动失败、安全风险及环境不一致问题。
直接用 golang:latest 打包出来的镜像不能上生产——体积大、带调试符号、root 权限运行、没做配置分离，上线后大概率出问题。
多阶段构建必须写成两段，不能省略 builder 阶段
很多人抄个单阶段 Dockerfile 就跑，结果镜像 1.2GB，启动慢，还报 exec user process caused: no such file or directory。根本原因是 Go 二进制在 alpine 上缺 libc 兼容层。
- 构建阶段必须用完整
golang镜像（比如golang:1.21-alpine），保证go mod download和go build环境一致 - 运行阶段用
alpine:3.18或distroless，但别用scratch——Gin 默认依赖 DNS 解析，scratch没有/etc/resolv.conf，会卡在net/http初始化 -
CGO_ENABLED=0必须加，否则编译出的二进制会动态链接 glibc，和 alpine 的 musl 不兼容
go build 参数不加 -ldflags="-w -s" 就等于留后门
默认编译的二进制带调试符号和 DWARF 信息，体积翻倍，还可能泄露路径、函数名甚至部分源码逻辑。线上被扫描到就是安全风险。
-
-w去掉 DWARF 调试段 -
-s去掉符号表 - 加上
GOOS=linux显式指定目标系统，避免本地 macOS/Windows 编译出错 - 完整命令示例：
CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o gin-app .
configs 目录不能 COPY 到镜像里，更不能硬编码进二进制
开发时把 config.yaml 放进 COPY . . 看似方便，但会导致：配置随镜像固化、不同环境要 rebuild、敏感信息（如数据库密码）打包进镜像层——这三件事任何一件都违反生产安全基线。
- 运行阶段只
COPY --from=builder二进制，不要COPY . . - configs 单独挂载：用
docker run -v /path/to/configs:/app/configs或 K8s ConfigMap - 代码里读配置必须支持环境变量覆盖，比如用
viper.AutomaticEnv()+viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_")) - 如果非得打包配置，至少放在单独 layer：
COPY configs ./configs，且确保该 layer 不含 secrets
非 root 用户运行不是可选项，是强制项
用 USER root 或默认用户跑 Gin 容器，等于把整个服务暴露给任意容器逃逸漏洞。K8s PodSecurityPolicy 或 OpenShift SCC 会直接拒绝调度。
- alpine 里用
adduser -D -u 1001 appuser创建无家目录、无 shell 的低权限用户 - 切换前先
chown -R appuser /root或对应工作目录 - 检查最终镜像是否真以非 root 运行：
docker image inspect myapp:latest | jq '.[0].Config.User'，输出应为"1001"或"appuser" - 注意：如果 Gin 启用了 HTTPS 并监听 443 端口，得改用 8443 或在 ingress 层卸载 TLS，Linux 下非 root 无法 bind 1–1023 端口
最常被跳过的其实是健康检查探针配置——livenessProbe 和 readinessProbe 如果只写 httpGet 而没设 initialDelaySeconds，Gin 应用冷启动慢，K8s 会反复 kill restart，看起来像服务永远起不来。
