必须显式设置cgo_enabled=0和goos=linux，否则因libc不兼容或目标平台错乱导致启动失败、https证书错误或exec格式错误；golang:slim基于debian，libc兼容性好，比alpine更稳定，适合多数生产场景。
CGO_ENABLED=0 和 GOOS=linux 是必须显式设置的，否则镜像在容器里大概率启动失败或 HTTPS 请求报 x509: certificate signed by unknown authority。
为什么用 golang:slim 而不是 golang:alpine 做运行时镜像
因为 golang:alpine 用的是 musl libc，而 Go 默认编译出的二进制依赖 glibc；哪怕你本地 go build 成功，一进 Alpine 容器就可能 panic 或静默失败（比如 net/http DNS 解析卡住、os/user 报错）。golang:slim 基于 Debian，libc 兼容性好，省去静态编译调试成本，适合大多数生产场景。
- 若坚持用 Alpine 运行时，必须配
CGO_ENABLED=0+-ldflags '-extldflags "-static"'，且RUN apk add --no-cache ca-certificates，否则 HTTPS 直接失败 -
golang:slim镜像体积比 Alpine 大 30–50MB，但换来的是稳定性和调试效率——别为省几 MB 拖慢上线节奏 - scratch 镜像更小更安全，但只接受完全静态链接的二进制：
ldd myapp必须输出not a dynamic executable
go mod download 层缓存失效的根因和解法
常见现象：每次 docker build 都重下一遍 module，构建变慢、CI 浪费带宽。根本原因是 go.mod 和 go.sum 没有单独 COPY，导致后续所有层缓存失效。
- 必须把
COPY go.mod go.sum ./放在COPY . .之前，且确保它们没被.dockerignore忽略（否则go mod download报no Go files in directory） - 如果项目含
replace或indirect依赖，go.sum必须完整提交，否则go mod download可能拉错版本 -
GO111MODULE=on和GOPROXY=https://proxy.golang.org,direct应在构建阶段显式设，尤其 CI 中避免私有模块解析失败
ENTRYPOINT 写成 ["/app/myapp"] 而不是 sh -c "/app/myapp"
用 sh -c 启动会让 myapp 成为 shell 子进程，PID 不是 1，导致 SIGTERM 无法传给主程序，容器 docker stop 超时、强制 kill，无法优雅退出。
- 始终用 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
本地 macOS/Windows 构建后进 Linux 容器报 exec format error
这是最常被跳过的点：Mac 上默认 GOOS=darwin，ARM Mac 编译出的二进制在 x86_64 容器里直接不可执行。交叉编译必须显式指定目标平台。
- 构建命令里加
GOOS=linux GOARCH=amd64（或arm64），例如：GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o myapp . - 用
file myapp验证输出是否含ELF 64-bit LSB executable, x86-64（或对应架构） - CI 环境建议统一加
GO111MODULE=on和GOPROXY，避免环境差异引发构建不一致
CGO_ENABLED=0 和 GOOS=linux 这两个环境变量——它们不写，其他都白搭。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
