根本原因是CGO_ENABLED=1导致二进制动态链接glibc，而Alpine/scratch使用musl libc，ABI不兼容；必须设CGO_ENABLED=0实现静态链接，并在Dockerfile中全局生效。
Go模块依赖在Alpine或scratch镜像中构建失败，根本原因不是“依赖没下载”，而是CGO_ENABLED=1导致二进制动态链接glibc，而Alpine用musl libc——两者ABI不兼容，内核加载失败时直接报command not found或exec format error。必须从编译源头切断动态链接。
为什么go build在Alpine镜像里跑不通
默认情况下，Go启用CGO（即CGO_ENABLED=1），会尝试链接宿主机的C标准库（如Ubuntu的glibc）。即使你用golang:alpine作为builder镜像，只要没显式关掉CGO，生成的二进制仍可能依赖/lib64/ld-linux-x86-64.so.2——而Alpine只有/lib/ld-musl-x86_64.so.1，scratch则什么都没有。
- 典型错误现象：
Container command '/app/server' not found or does not exist（文件明明存在、权限正确） - 验证方法：
ldd ./server输出含not found，或file ./server显示dynamically linked - 陷阱：只换基础镜像（比如从ubuntu切到alpine）但不改编译参数，问题照旧
CGO_ENABLED=0必须加在构建阶段，且要全局生效
禁用CGO不是可选项，是硬性前提。它让Go放弃调用C代码路径（如net包的DNS解析、os/user等），转而使用纯Go实现——代价是某些功能行为略有差异（比如DNS查询走Go内置解析器而非系统getaddrinfo），但换来的是真正的静态链接。
- 构建命令必须带环境变量：
CGO_ENABLED=0 go build -ldflags="-s -w" -o server . - 在Dockerfile中，需在
RUN前用ENV CGO_ENABLED=0，或直接写进命令行（避免被后续ENV覆盖） - 如果项目用了
cgo特性（如// #include <sqlite3.h>），关CGO后会编译失败——此时应换纯Go替代方案（如mattn/go-sqlite3的sqlite3_bind_text等底层调用不可用，得用github.com/glebarez/sqlite）
多阶段构建时，builder镜像选golang:alpine就够了，别用golang:latest
builder镜像只需提供Go工具链和go mod download能力，不需要完整OS。用golang:alpine比golang:latest（基于debian）体积小、启动快，且天然匹配musl环境，减少隐式依赖风险。
立即学习“go语言免费学习笔记（深入）”；
- Dockerfile中第一阶段写
FROM golang:1.24-alpine AS builder即可，无需额外apk add编译工具 - 第二阶段优先用
FROM scratch：它不含shell、不含证书、不含任何二进制，只放你的静态二进制——最终镜像约7–9MB，且攻击面最小 - 若需
ca-certificates（比如HTTP客户端要校验证书），改用FROM gcr.io/distroless/static-debian11，它预装了根证书但无shell
go mod download失败？检查GOPROXY和GOPRIVATE是否生效
在builder阶段执行go mod download卡住或报错，常见于私有模块或国内网络环境。这不是镜像问题，而是Go模块代理配置失效。
- 确保
ENV GOPROXY=https://goproxy.cn,direct写在COPY go.mod go.sum .之前 - 私有仓库必须加
ENV GOPRIVATE=git.example.com/internal，否则Go会尝试去proxy查校验和，失败后fallback到vcs但可能权限不足 - 验证方式：在builder阶段
RUN go list -m all，看是否能列出所有模块；若卡在某个私有包，说明GOPRIVATE没生效或git凭证缺失
真正麻烦的从来不是“怎么写Dockerfile”，而是搞清哪一行ENV被覆盖、哪个go.mod里的replace在CI里被忽略、或者file命令显示“statically linked”却仍报exec format error——那八成是你交叉编译时GOARCH设错了，和CGO无关。
