Go模块管理对编译的影响解析

go build 会读取 go.mod 并锁定依赖版本，依据 require/replace 解析依赖树，严格使用声明版本，忽略 GOPATH；go.sum 必须存在且校验通过，否则构建中止；-mod=vendor 强制只读 vendor，但需先执行 go mod vendor 同步。

Go build 会读取 go.mod 并锁定依赖版本

Go 编译（go build）本身不直接编译模块定义，但它在构建前会隐式执行模块加载和依赖解析。如果当前目录或其任意父目录存在 go.mod，go build 就进入 module 模式，并严格依据 go.mod 中的 require 和 replace 规则解析依赖树。

这意味着：即使本地 $GOPATH/src 下有同名包，只要 go.mod 里声明了 github.com/some/lib v1.2.0，go build 就只用这个版本，不会 fallback 到 GOPATH 或本地未版本化代码——除非显式加了 replace。

• 没有 go.mod 时，go build 可能退化为 GOPATH 模式（Go 1.13+ 默认关闭，需设 GO111MODULE=off）
• go build -mod=readonly 禁止自动修改 go.mod 或 go.sum，CI 场景常用
• go build -mod=vendor 强制只从 ./vendor 目录读依赖，忽略 go.mod 中远程路径（但要求 vendor 已通过 go mod vendor 生成）

go.sum 文件缺失或校验失败会导致构建中止

go.sum 不是可选文件。当 go build 需要下载新依赖（比如首次构建或 go.mod 新增 require），它会校验每个模块 zip 包的哈希值是否与 go.sum 记录一致。不一致会报错：verifying github.com/xxx@v1.2.3: checksum mismatch。

常见诱因包括：手动编辑 go.sum、代理返回被篡改的包、本地缓存损坏、或使用了不兼容的 Go 版本（不同 Go 版本对同一模块可能生成不同哈希）。

• 修复方法通常是运行 go mod download -dirty 清理缓存，再 go mod tidy 重生成 go.sum
• 若确定信任来源，可用 go mod verify 手动检查，或临时设 GOSUMDB=off（仅限开发环境）
• CI 构建建议保留 go.sum 并校验，避免依赖漂移

GOOS/GOARCH 环境变量影响模块感知的构建目标

GOOS 和 GOARCH 不仅控制输出二进制格式，也影响模块内条件编译逻辑（如 // +build linux）及某些依赖的构建行为。更重要的是：部分模块（尤其是含 cgo 或平台特定代码的）会在 go build 阶段根据目标平台动态选择子模块或跳过某些 require。

例如，golang.org/x/sys/unix 在 Windows 下不会参与构建，而 golang.org/x/sys/windows 会被激活；这种切换由 go build 在模块解析阶段完成，不是链接期才决定。

• 交叉编译时务必提前设置 GOOS/GOARCH，否则 go build 可能因平台不匹配跳过必要依赖，导致 “undefined: xxx” 错误
• 使用 go list -f '{{.StaleReason}}' ./... 可查看哪些包因平台变化被标记为 stale
• cgo 启用状态（CGO_ENABLED=0）也会改变模块行为，比如禁用 cgo 时 net 包会回退到纯 Go 实现，不依赖系统 DNS 库

vendor 目录未更新时，go build 仍可能拉取远程模块

即使项目存在 ./vendor，go build -mod=vendor 才强制只读 vendor；默认模式下，go build 仍会读取 go.mod 并尝试验证 vendor 内容是否与声明一致。若发现 vendor 缺失某依赖、或版本不匹配，它会报错：vendor directory is out of date，并拒绝构建。

这不是 bug，而是模块一致性保护机制。vendor 只是缓存，不是权威源。

• 同步 vendor 的正确流程是：go mod tidy → go mod vendor → 提交 go.mod、go.sum 和 vendor/
• CI 中若跳过 go mod vendor 而直接 go build -mod=vendor，且 vendor 未随代码更新，构建必然失败
• go mod vendor 不会自动删除已废弃的 vendor 子目录，需配合 go mod vendor -v 查看冗余项

模块管理真正介入构建的节点比想象中早：从解析 import 路径开始，到决定用哪个版本、是否启用 cgo、甚至是否允许某包参与编译，都在 go build 的前期阶段由模块系统拍板。很多人以为 vendor 或 go.sum 是“事后校验”，其实它们是构建策略的一部分，任何改动都可能让 go build 拒绝继续——哪怕语法完全合法。