Go模块依赖管理直接决定二进制可复现性与运行正确性；需严格锁定go.mod、go.sum、CGO_ENABLED、GOOS/GOARCH，vendor和交叉编译也受其约束。
Go 模块依赖管理直接决定 go build 能否成功、生成的二进制是否可复现、以及它到底链接了什么——不是“影响编译速度”这种次要问题，而是“编译出的程序在目标机器上能不能跑”的根本问题。
go.mod 和 go.sum 如何强制控制构建结果
go build 一旦发现当前目录或任一父目录有 go.mod，就立刻进入 module 模式，完全忽略 $GOPATH/src 下同名包。所有依赖版本都严格按 require 声明走，哪怕本地 github.com/some/lib 目录里是 v2.0 的代码，只要 go.mod 写着 v1.2.0，就只用这个版本。
go.sum 不是校验可选项：缺失或哈希不匹配时，go build 直接中止，报错类似 verifying github.com/xxx@v1.2.3: checksum mismatch。常见诱因包括手动改过 go.sum、代理返回被篡改的 zip、或本地模块缓存损坏。
- 修复首选
go mod download -dirty && go mod tidy，而不是删go.sum后重跑 - CI 环境必须保留
go.sum并校验，否则依赖可能悄悄漂移 -
go build -mod=readonly可防止意外修改go.mod或go.sum，适合发布流水线
vendor 目录不是“备份”，而是构建隔离开关
go build -mod=vendor 不是“优先读 vendor”，而是**强制只读 ./vendor，完全跳过远程模块解析和 go.mod 中的 require 路径**。但前提是：vendor 必须已由 go mod vendor 生成且内容完整。
立即学习“go语言免费学习笔记（深入）”；
如果 vendor 缺少某个子依赖（比如 golang.org/x/sys），go build -mod=vendor 会直接报 cannot find package，不会 fallback 到网络下载——这和 -mod=readonly 完全不同。
-
go mod vendor会把所有 transitive 依赖平铺进vendor/，不保留嵌套结构；go build -mod=vendor就按这个平铺路径去 import - 修改
vendor里的代码后，go build会直接使用，但go mod tidy不会感知，容易导致本地与 CI 行为不一致 - 交叉编译时，
vendor中的平台特定代码（如golang.org/x/sys/unix）仍受GOOS/GOARCH控制，不是“全量打包就万事大吉”
CGO_ENABLED=0 不只是禁用 C 代码，它改写了整个标准库路径
默认 CGO_ENABLED=1（Linux/macOS），net 包走 libc 的 getaddrinfo，os/user 读 /etc/passwd；设成 0 后，这些包自动切换到纯 Go 实现：DNS 解析走内置 UDP 查询，user.Current() 直接 panic，因为没 libc 支撑。
这意味着：同一个 go.mod，在 CGO_ENABLED=0 和 =1 下，go build 解析出的依赖树是不同的——前者可能跳过 golang.org/x/sys，后者必须拉它。
- 静态二进制不是靠
-ldflags="-s -w"实现的，而是靠CGO_ENABLED=0切断对 libc 的调用链 -
file myapp显示statically linked≠ 真静态；必须ldd myapp返回not a dynamic executable才算数 - 如果项目用了
cgo（比如 sqlite3 驱动），又想静态链接，得换musl-gcc工具链，不能只设CGO_ENABLED=0
GOOS/GOARCH 在模块解析阶段就起作用，不是链接时才生效
GOOS=linux GOARCH=arm64 go build 不仅让输出是 ARM64 二进制，还会在依赖解析阶段就过滤掉 golang.org/x/sys/windows 这类 Windows 专属模块，并激活 golang.org/x/sys/unix 的对应子集。如果漏设，go build 可能因找不到平台相关符号而报 undefined: xxx。
更隐蔽的是：某些模块（如 net）内部用 // +build linux,amd64 标记文件，go build 在加载 go.mod 后、编译前就根据 GOOS/GOARCH 决定哪些文件参与构建——这直接影响最终二进制里有没有某段逻辑。
- 交叉编译务必在
go build命令前设置环境变量，而不是靠go env -w持久化，避免污染本地开发环境 -
go list -f '{{.Stale}}' std可检查标准库是否因GOOS/GOARCH变更而需重编译（源码版GOROOT下尤其明显） - 容器内构建时，别依赖宿主机的
GOOS默认值；显式传入比靠环境变量更可靠
真正难处理的不是“怎么让二进制变小”，而是“怎么确保 go build 在任何机器上解析出的依赖树完全一致”——这要求 go.mod、go.sum、CGO_ENABLED、GOOS/GOARCH 全部显式锁定，缺一不可。漏掉任意一个，都可能让同一份代码在不同环境产出行为不同的二进制。
