多阶段构建应使用 golang:alpine 编译，避免 glibc 依赖；加 CGO_ENABLED=0 和 -ldflags "-s -w" 减小体积并去敏感信息；分层 COPY go.mod/go.sum 提升缓存复用；ENTRYPOINT 替代 CMD 确保信号处理与参数传递正确。
多阶段构建必须用 FROM golang:alpine 做编译，别用 debian 镜像
Go 编译产物是静态二进制，不需要运行时依赖 libc，用 golang:alpine 能显著减小镜像体积，同时避免 glibc 和 musl 兼容问题。如果在 debian 系基础镜像里编译，生成的二进制可能隐式链接 glibc，后续 COPY 到 alpine 运行会报 no such file or directory（实际是动态链接器缺失）。
实操建议：
- 第一阶段用
FROM golang:1.22-alpine，WORKDIR /app，COPY . .，再go build -o myapp ./cmd/myapp - 第二阶段用
FROM alpine:3.19，只COPY --from=0 /app/myapp /usr/local/bin/myapp - 显式加
CGO_ENABLED=0：在编译命令前设环境变量，避免意外调用 C 代码导致静态链接失败
go build 必须加 -ldflags "-s -w" 去除调试信息和符号表
默认编译出的二进制包含 DWARF 符号和调试段，体积可能翻倍，且暴露源码路径、函数名等敏感信息。生产镜像里没理由保留这些。
常见错误现象：镜像大小比预期大 5–10MB，docker history 显示某层异常臃肿。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 编译命令写成：
go build -ldflags "-s -w" -o myapp ./cmd/myapp - 若项目用了
go:embed或需要保留部分符号（极少见），可只加-s（剥离符号表），-w（去掉 DWARF）仍建议保留 - 验证是否生效：本地跑
file myapp应显示statically linked；strip --strip-all myapp再对比体积，差别应很小
Dockerfile 中不要 COPY . . 整个目录，要按需分层 COPY go.mod go.sum ./ 再 COPY *.go
Docker 构建缓存依赖文件内容哈希。把 go.mod 和 go.sum 单独 COPY 并提前 go mod download，能让依赖下载层长期复用，只要不改依赖就不会重拉一遍模块。
容易踩的坑：
- 先
COPY . .再go mod download：每次任何.go文件变动都会让go mod download层失效，白白浪费时间 - 漏掉
go.sum：go mod download可能失败或校验不通过，尤其 CI 环境严格校验时 - 用
COPY . .同时带入node_modules或vendor：污染构建上下文，拖慢构建速度，还可能触发误编译
推荐顺序：COPY go.mod go.sum ./ → RUN go mod download → COPY cmd/ internal/ pkg/ .（按实际目录结构）→ go build
容器启动命令必须用 ENTRYPOINT ["/usr/local/bin/myapp"]，别用 CMD
CMD 在被 docker run 后续参数覆盖时会整个替换，比如 docker run myimg --help 会执行 sh -c '--help'，直接失败。而 ENTRYPOINT 把二进制设为 PID 1，后续参数自动追加其后，符合 Go CLI 工具预期行为。
性能与兼容性影响：
- 用
ENTRYPOINT可以正确接收SIGTERM，支持优雅退出；用sh -c包一层会导致信号转发失败 - 某些编排系统（如 Kubernetes）依赖容器主进程是 PID 1 来管理生命周期，
sh作入口会干扰 readiness probe 判断 - 如果真需要 shell 功能（例如环境变量展开），改用
ENTRYPOINT ["/bin/sh", "-c", "/usr/local/bin/myapp $1", "--"]，但 Go 程序通常不需要
复杂点在于：很多人习惯写 CMD ["--port=8080"]，结果发现参数根本没传进去——这恰恰说明 ENTRYPOINT 没配对，或者配了但忘了把默认参数写进 ENTRYPOINT 数组里。
