Go build镜像带go和GOROOT是因未用静态链接且多阶段构建中运行阶段误用含Go的base镜像或COPY了/go目录；应构建阶段用golang镜像，运行阶段切scratch或distroless并仅COPY二进制。
Go build 时为什么镜像里还带着 go 和 $GOROOT
因为没用静态链接，也没在构建阶段剥离开发依赖。Docker 多阶段构建中，如果第二阶段 base 镜像用了 golang:alpine 或直接 debian，又没显式删掉 go 工具链，那二进制+编译器全塞进去了。
- 默认
go build会动态链接 libc（Linux 下）或依赖系统musl（Alpine），但只要不加-ldflags '-s -w'和CGO_ENABLED=0，就可能隐式带入 CGO 依赖和调试符号 - 多阶段构建的“构建阶段”用
golang:1.22没问题，但“运行阶段”必须切到scratch或alpine:latest这类不含 Go 的基础镜像 - 别在运行阶段 COPY 整个
/go目录——COPY --from=builder /go .是常见错误操作，/go里有 SDK、缓存、mod cache，体积轻松破百 MB
CGO_ENABLED=0 go build 能不能关掉所有动态依赖
能，但只对纯 Go 项目成立。一旦用了 cgo（比如调 net 包里的 DNS 解析、os/user、某些数据库驱动），关掉它就会编译失败或行为异常。
- 典型报错：
undefined: syscall.Stat_t或lookup xxx: no such host（DNS 失败） - 若必须用 cgo（如
sqlite3、pgx），就别硬开CGO_ENABLED=0，改用gcr.io/distroless/cc-debian12这类带最小 libc 的 distroless 镜像 - 检查是否真用了 cgo：运行
go list -json -deps . | jq 'select(.CgoFiles != null and (.CgoFiles | length) > 0)'
Dockerfile 中怎么写才真正最小化
核心是：构建阶段只留二进制，运行阶段只 COPY 二进制 + 必需配置文件，其他全砍。
Docker Hub
下载
Docker Hub (hub.docker.com)。此技能适用于所有 Docker Hub 操作，包括读取、创建、更新和删除数据。只要任务涉及 Docker Hub，就使用此技能。
- 构建命令推荐：
CGO_ENABLED=0 go build -a -ldflags '-s -w' -o /app/main .（-a强制重编所有依赖，避免残留引用） - 运行阶段优先选
FROM scratch，但得确认没用 cgo、没读/etc/ssl/certs、没调user.Lookup；否则退到FROM gcr.io/distroless/static-debian12 - 别漏掉非代码文件：配置、模板、证书——用
COPY --chown=root:root显式设权限，避免因 UID 不匹配导致启动失败
为什么 docker image ls -s 看着小，实际拉取却大很多
因为 Docker 镜像分层叠加，docker image ls 显示的是“本机已缓存层”的压缩后大小，而 docker pull 下载的是各层原始 blob，尤其 base 镜像（如 debian:slim）未共享时，重复下载开销明显。
立即学习“go语言免费学习笔记（深入）”；
- 验证方法：
docker inspect <image-id> | jq '.[0].RootFS.Layers'</image-id>查 layer 数量和 digest - 解决思路：统一 base 镜像 tag（别混用
alpine:3.19和alpine:latest），或用FROM --platform=linux/amd64锁定架构减少变体 - 容易被忽略的一点：Go mod cache 默认存在
/go/pkg/mod，如果构建阶段没清掉，且你用了COPY . .把整个目录带进去，cache 就悄悄混进镜像了
