Go微服务镜像体积大的主因是构建流程未隔离，关键需先COPY go.mod/go.sum再go mod download以利用层缓存，必须设CGO_ENABLED=0、-ldflags="-s -w"生成静态二进制，并仅COPY编译产物至scratch或alpine镜像。
Go 微服务镜像体积大，多半是因为 go mod download 和源码一起被打包进了最终镜像。真正精简的关键不是“删什么”，而是“只复制编译产物，且让依赖下载和构建过程可缓存、不污染运行时”。
为什么 go mod download 必须放在 COPY 源码之前
Docker 构建层缓存机制依赖指令顺序。如果先 COPY . . 再 go mod download，每次改一行代码都会让前面所有层失效，导致依赖重新下载——不仅慢，还可能把 dev-only 的间接依赖（比如 test-only 的 mock 库）意外带入构建上下文。
-
COPY go.mod go.sum ./必须单独成层，且紧接在WORKDIR之后 -
go mod download执行后，Docker 会缓存这一层；只要go.mod不变，后续构建跳过下载 - 再
COPY . .时，即使源码大改，也不会影响依赖层，编译阶段仍能复用已下载的 module cache
CGO_ENABLED=0 不是可选项，是必须项
默认开启 CGO 会让 Go 编译器链接 libc 等动态库，导致最终二进制无法在 scratch 或最小化 alpine 中运行——你会看到 standard_init_linux.go:228: exec user process caused: no such file or directory 这类错误，本质是找不到 /lib/ld-musl-x86_64.so.1 或 glibc。
- 务必在构建阶段显式设置
CGO_ENABLED=0 - 同时指定
GOOS=linux，避免本地 macOS/Windows 构建时混入平台特定符号 - 加上
-ldflags="-s -w"：去掉调试符号和 DWARF 信息，二进制通常能缩小 30%～50%
从 builder 阶段只 COPY 二进制，别碰其他文件
很多人在第二阶段写 COPY --from=builder /app/ .，结果把整个 /app 目录（含 go.mod、vendor/、测试文件等）全复制过去，白费了多阶段设计的初衷。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 精确指定路径：
COPY --from=builder /app/main . - 如果服务需要配置文件（如
config.yaml），应在COPY后单独挂载或通过 ConfigMap 注入，绝不打包进镜像 - 用
alpine:latest时记得RUN apk --no-cache add ca-certificates；用scratch则需提前把证书从 builder 阶段复制过来（COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/）
忽略 .git 和测试文件，从源头减小构建上下文
docker build 默认把当前目录所有文件发送给 daemon。一个含 .git、node_modules、测试截图的项目，上下文可能超百 MB，拖慢构建、增加缓存失效风险。
- 在项目根目录创建
.dockerignore，至少包含：.git、.gitignore、README.md、tests/、mocks/、*.go.swp - 避免在
Dockerfile中用COPY . .前未清理无关文件——这会导致go mod download缓存被破坏（因为go.sum校验包含整个上下文哈希） - 如果用了
go.work，也要加进.dockerignore，否则可能触发 workspace 模式误判
最易被忽略的一点：go mod download 缓存是否生效，取决于 go.mod 和 go.sum 是否真的没变——而某些 CI 工具会在 commit 时自动重写 go.sum 时间戳字段，导致缓存永远失效。上线前最好手动验证构建日志里有没有 “CACHED” 字样。
