Dockerfile 中 go build 放太前会导致镜像缓存失效，因源码变更触发从 go mod download 起所有层重建；应先 COPY go.mod/go.sum 单独成层，并固定 go build -o 输出路径、禁用 CGO、合理设置 GOROOT/GOPATH。
为什么 Dockerfile 里 go build 放太前会让镜像缓存完全失效
Go 编译产物依赖源码、go.mod、go.sum 和 Go 版本，但很多人把 COPY . /app 放在 go build 前面，导致每次改一行代码，从 go mod download 开始所有层全失效。
-
COPY go.mod go.sum ./必须单独成层，且放在COPY . .之前——这样依赖没变时，go mod download层可复用 -
go build -o输出路径必须固定（比如/app/main），不能带时间戳或随机后缀，否则即使二进制内容一致，文件名变了也会破坏后续COPY或RUN的缓存 - 别在构建时用
go build -mod=readonly以外的模式，否则go.mod被意外修改会触发缓存跳过
多阶段构建中 GOROOT 和 GOPATH 环境变量怎么设才不拖慢构建
默认 golang:alpine 镜像里 GOPATH 是 /go，但如果你在 build 阶段显式 ENV GOPATH=/workspace，又没同步改 go mod download -g 的路径，就会重复下载依赖；更糟的是，某些 CI 环境下 GOROOT 指向非标准路径，导致 go tool compile 找不到 runtime 包。
- 构建阶段统一用官方
golang:1.22-alpine（或你锁定的版本），不重设GOROOT——它已预置正确 -
GOPATH只在需要自定义模块缓存位置时才设，且必须配合go env -w GOPATH=/xxx+COPY复用缓存目录，否则纯属增加复杂度 - 生产阶段用
scratch或alpine:latest时，完全不需要GOROOT/GOPATH——静态编译的二进制不依赖它们
go build -ldflags 里的 -s -w 真的能减小镜像体积吗
能，但只对最终二进制有效，和镜像层数无关。很多人以为加了就“自动瘦身”，结果发现镜像大小没变——因为没删掉构建阶段的中间文件，或者用了 CGO_ENABLED=1 导致链接了 libc。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go build -ldflags="-s -w"可去掉调试符号和 DWARF 信息，通常减 30%–50% 体积，但前提是CGO_ENABLED=0 - 如果必须开 CGO（比如用了
cgo调系统库），-s -w效果有限，此时应优先考虑用upx（需额外安装）或切换到distroless基础镜像 - 别忘了在多阶段构建最后
COPY --from=builder /app/main /后，删掉 builder 阶段的整个工作目录——有些 Dockerfile 忘写rm -rf /app，残留源码和go.mod白占几十 MB
本地开发时 docker build 为什么比 CI 里还慢
本地 docker build 默认不共享构建缓存，尤其用 Docker Desktop 时，每轮构建都像全新开始；而 GitHub Actions 或 GitLab CI 通常配置了 cache-from + cache-to，能复用远程 registry 的层。
立即学习“go语言免费学习笔记（深入）”；
- 本地跑
docker buildx build --cache-from type=local,src=./cache --cache-to type=local,dest=./cache才能真正复用 - CI 中若用
docker/build-push-action，务必配cache-from指向同一 registry 的type=registry缓存，否则各 job 之间互不可见 - 避免在
.dockerignore里漏掉node_modules/、vendor/或 IDE 文件夹——它们被 COPY 进构建上下文后，哪怕没用到，也会让缓存哈希值改变
最常被忽略的点：go.work 文件的存在会让 go mod download 行为和单模块项目不同，但 Docker 构建时默认不识别它——得显式 COPY go.work ./ 并确保它在 go.mod 之前被 COPY，否则缓存照样断掉。
