必须用多阶段构建+非root运行+显式健康端点三件套，否则上线后大概率触发配置泄漏、OOM被杀、健康检查失败、DNS解析超时四类问题；单阶段构建镜像超1GB且含完整SDK，应使用golang:1.21-alpine构建、alpine:3.18运行，启用CGO_ENABLED=0、-ldflags="-w -s"，创建非root用户并设独立/health端点。
直接用 go run main.go 或裸跑 ubuntu:22.04 镜像打包 Gin 应用，上线后大概率触发配置泄漏、OOM 被杀、健康检查失败、DNS 解析超时四类问题——这不是“部署成功”，而是埋了定时炸弹。
必须用多阶段构建，否则镜像体积和安全隐患都失控
单阶段构建会把 Go 编译器、go.mod、源码全塞进最终镜像，体积轻松破 1GB，且 root 权限运行、无安全隔离。
- 构建阶段用
golang:1.21-alpine，启用CGO_ENABLED=0确保静态链接（避免 musl DNS 问题） - 编译命令加
-ldflags="-w -s"剥离调试符号，二进制更小、启动更快 - 运行阶段切到
alpine:3.18，只装ca-certificates和tzdata，不装任何 dev 工具 - 显式创建非 root 用户：
RUN adduser -D -u 1001 appuser，再USER appuser
FROM golang:1.21-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o gin-app . FROM alpine:3.18 RUN apk --no-cache add ca-certificates tzdata RUN adduser -D -u 1001 appuser USER appuser WORKDIR /root COPY --from=builder /app/gin-app . EXPOSE 8080 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD wget --quiet --tries=1 --spider http://localhost:8080/health || exit 1 CMD ["./gin-app"]
DNS 解析失败不是 Alpine 的锅，是 net 包没走系统 resolver
现象是服务启动后连不上 Redis/MySQL，日志只报 dial tcp: lookup xxx: no such host。根本原因：Alpine 默认用 musl libc + 纯 Go DNS 解析器，遇到内网 search 域或 ndots 配置就卡住。
- 不要换回
ubuntu镜像——体积大、攻击面宽 - 也不要删
/etc/resolv.conf——Docker 默认挂载，删了反而更崩 - 正确做法：构建阶段启用 cgo 并装
gcc musl-dev，让net包调用系统getaddrinfo - 若仍不稳定，启动前可覆盖 nameserver：
RUN echo "nameserver 8.8.8.8" > /etc/resolv.conf
/health 端点必须独立，不能复用 /metrics 或 /debug
Kubernetes 的 livenessProbe 和 readinessProbe 要求端点轻量、无副作用、响应稳定。用 /metrics 当健康检查，Prometheus 抓取会触发锁竞争，CPU 毛刺明显。
- 在 Gin 路由里单独注册
GET /health，只返回200 OK，不查 DB、不打日志、不调外部服务 - 避免在该 handler 里调用
viper.Get或初始化全局变量——冷启动时可能 panic - Healthcheck 命令必须用
wget或curl，别用nc -zv——它不校验 HTTP 状态码
最易被忽略的点：很多人以为 “能 curl 通就代表健康”，但 Kubernetes 的 start-period 和 retries 参数一旦设错，服务还没真正 ready 就被反复重启；而 /health 若依赖数据库连接池初始化，又没做重试退避，就会陷入死循环。
