生产环境运行时镜像优先选golang:slim或scratch+静态编译；需显式设cgo_enabled=0和goos=linux，避免libc不兼容、架构错误及https证书失败等问题。
Go 程序该用 FROM golang:alpine 还是 FROM golang:slim？
编译阶段用 golang:alpine 没问题，但运行时镜像别直接用它——libc 不兼容会导致 net/http、os/user 等包静默失败或 panic。生产环境优先选 golang:slim（基于 Debian），或者更彻底：用 FROM scratch 或 FROM alpine:latest 配静态编译二进制。
-
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o myapp .是关键，否则即使用了scratch也会因动态链接失败 -
golang:slim体积比alpine大约多 30–50MB，但省去静态编译调试成本，适合快速迭代 - 若必须用
alpine运行时，记得装ca-certificates，否则 HTTPS 请求会报x509: certificate signed by unknown authority
如何避免 Docker 构建时反复下载 Go module？
Go 的 go mod download 在每层 RUN 中都会重来，不复用缓存——根本原因是 go.mod 和 go.sum 没在 COPY 前单独拎出来，导致后续所有层缓存失效。
- 先
COPY go.mod go.sum ./，再RUN go mod download，最后才COPY . . - 确保
go.mod文件没被.dockerignore忽略，否则go mod download会报no Go files in directory - 如果项目含 replace 或 indirect 依赖，
go.sum必须完整提交，否则构建可能拉错版本
ENTRYPOINT 和 CMD 怎么配才不会让进程变成 PID 1 的子进程？
用 sh -c "myapp" 启动，会让 myapp 成为 shell 的子进程，导致 SIGTERM 无法传给主程序，容器无法优雅退出。
- 始终用 exec 形式：
ENTRYPOINT ["/app/myapp"]，不要写成ENTRYPOINT ["sh", "-c", "/app/myapp"] - 如果需要传参，用
CMD ["--port=8080"]配合上面的ENTRYPOINT，Docker 会把 CMD 数组追加到 ENTRYPOINT 数组末尾 - 检查最终进程树：
docker run --rm -it your-image ps aux，确认myapp是 PID 1
本地开发和 CI 构建结果不一致？可能是 GOOS/GOARCH 没对齐
Mac 上默认 GOOS=darwin，Linux 容器里要的是 linux；ARM Mac 编译出的二进制在 x86_64 容器里直接报 exec format error。
- 构建时显式指定：
GOOS=linux GOARCH=amd64 go build -o myapp . - CI 中建议统一加
GO111MODULE=on和GOPROXY=https://proxy.golang.org,direct，避免私有模块解析失败 - 交叉编译后用
file myapp验证目标平台，输出应含ELF 64-bit LSB executable, x86-64或对应架构
最常被跳过的其实是 CGO_ENABLED=0 和 GOOS=linux 这两个环境变量——它们不出错时不提醒，一出就是容器起不来或连不上网，得翻日志逐行看 syscall 返回值。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
