Go服务容器化部署核心在于编译方式（CGO_ENABLED=0+GOOS=linux）、基础镜像选择（alpine/scratch/distroless）和健康探针设计（liveness/readiness分离、/health不查DB），三者缺一不可。
Go 框架（如 Gin、Echo、Fiber）部署的核心不是“选哪个框架”，而是如何让框架跑在容器里既轻又稳——关键在于编译方式、基础镜像选择和健康探针设计。
CGO_ENABLED=0 和 GOOS=linux 必须显式设置
很多 Go 服务本地能跑，一进容器就 panic 或报 exec format error，根本原因是没关 CGO 或没指定目标系统。Gin/Echo 这类框架本身不依赖 cgo，但默认构建会链接 libc，而 alpine 镜像用的是 musl libc。
-
CGO_ENABLED=0强制生成纯静态二进制，避免运行时依赖系统 libc -
GOOS=linux确保跨平台构建（比如你在 macOS 上写代码，镜像要跑在 Linux 容器里） - 漏掉任一参数，
go build可能产出动态链接的可执行文件，进scratch或alpine就直接失败
多阶段 Dockerfile 中 builder 阶段不能省 go mod download
常见错误是把 go.mod 和源码一起 COPY 再 go build，导致每次构建都重新下载依赖，浪费时间还破坏层缓存。正确做法是分两步 COPY。
- 先
COPY go.mod go.sum ./，再RUN go mod download—— 这步会缓存，后续改代码不影响这层 - 再
COPY . .，然后go build—— 只有代码变才触发重编译 - 如果项目用了私有模块（比如企业内网 GOPROXY），记得在 builder 阶段
RUN go env -w GOPROXY=...
HEALTHCHECK 指令必须配超时和重试，且 /health 不该查 DB
用 HEALTHCHECK --interval=10s --timeout=3s --start-period=30s --retries=3 CMD curl -f http://localhost:8080/health || exit 1 是基础配置，但更关键的是 /health 实现本身。
立即学习“go语言免费学习笔记（深入）”；
- 别在
/health里执行db.Ping()—— DB 延迟抖动会直接触发容器重启 - 只检查服务监听状态 + 内存/CPU 基础指标（如用
runtime.ReadMemStats） - 如果真要验 DB，单独加个
/readyz，并配readinessProbe，和livenessProbe分开
alpine 镜像里缺 ca-certificates 就连不上 HTTPS 外部服务
用 alpine:latest 当运行镜像时，http.Client 默认会校验证书，但 Alpine 默认不带 CA 证书包 —— 表现为调第三方 API 时返回 x509: certificate signed by unknown authority。
- 必须加
RUN apk --no-cache add ca-certificates - 或者换
FROM debian:slim，它自带证书，但镜像体积翻倍（~50MB vs ~6MB） - 如果用
scratch，得手动COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
最易被忽略的其实是 .dockerignore：没它，go build 可能意外把 vendor/、node_modules/ 或 testdata/ 打进镜像，不仅增大体积，还可能引入安全风险。
