go build 不能直接用 go mod vendor 是因为默认仍走模块模式、不读 vendor/ 目录，必须显式加 -mod=vendor 参数；否则即使有 vendor/ 也会联网拉取依赖，docker 构建易失败或缓存污染。
Go build 时为什么不能直接用 go mod vendor？
因为 go mod vendor 只是把依赖复制进本地 vendor/ 目录，并不会改变构建行为——默认仍走模块模式，GO111MODULE=on 下它压根不读 vendor/。真正让编译器用 vendor 的，是加 -mod=vendor 参数。
- 没加
-mod=vendor：即使有vendor/，go build仍会联网拉取模块（或读$GOPATH/pkg/mod），Docker 构建时容易失败或污染缓存 - 加了但没清理：旧 vendor 内容残留可能引入不一致依赖，建议每次构建前
rm -rf vendor && go mod vendor - 交叉编译注意：
CGO_ENABLED=0必须和-mod=vendor配合，否则某些含 cgo 的包（如net）在 alpine 上会静默 fallback 到系统解析逻辑，导致 DNS 失败
Docker 多阶段构建中 COPY go.mod/go.sum 为什么要分两步？
这是为了最大化利用 Docker 构建缓存。只要 go.mod 或 go.sum 没变，后续依赖下载步骤就完全复用缓存层，哪怕源码天天改也不影响。
- 错误写法：
COPY . .后再RUN go mod download→ 每次代码变更都会使缓存失效，重下所有依赖 - 正确顺序：先
COPY go.mod go.sum ./，再RUN go mod download，最后COPY . .→ 仅当依赖声明变化时才触发下载 - 注意路径：如果
go.mod不在构建上下文根目录（比如在cmd/myapp/），就得COPY cmd/myapp/go.mod ./，否则go mod download找不到模块根
alpine 镜像里 go build 出来的二进制为什么运行时报 “no such file or directory”？
不是文件真丢了，而是动态链接器缺失。默认 go build 生成的是动态链接可执行文件，依赖 /lib64/ld-linux-x86-64.so.2 这类 glibc 路径——而 Alpine 用的是 musl libc，路径和 ABI 都不兼容。
- 解决方案只有两个：要么换
golang:alpine基础镜像并确保全程CGO_ENABLED=0，要么用scratch镜像 + 静态二进制 -
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o myapp .中的-a强制重编所有依赖（包括标准库），避免漏掉某个含 cgo 的包 - 验证是否静态：
file myapp输出含statically linked；ldd myapp应提示not a dynamic executable
为什么最终镜像用 FROM scratch 而不是 FROM alpine？
因为绝大多数 Go 程序根本不需要 shell、包管理器、证书库这些——scratch 是空镜像，体积接近 0，且攻击面最小。alpine 虽小（~5MB），但多了 apk、busybox、ca-certificates 等，纯属冗余。
立即学习“go语言免费学习笔记（深入）”；
- 前提条件：二进制必须是静态链接（
CGO_ENABLED=0）、不依赖外部配置文件（如/etc/ssl/certs）、不调用exec外部命令 - 证书问题：若程序要 HTTPS 请求，得把证书打包进去，比如
COPY /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/，否则 TLS 握手失败 - 调试困难：scratch 里没有
sh、ls、strace，出问题只能靠日志或提前注入 busybox（不推荐生产）
最易被忽略的一点：有些 Go 包（如 os/user、net 在某些场景下）会尝试读取 /etc/passwd 或 /etc/nsswitch.conf，虽然不报错，但可能引发非预期行为。上线前务必在 scratch 环境跑通端到端流程，别只测构建。
