go111module=on在闭网环境更关键，因auto模式依赖路径判断不可靠（如不在gopath/src下即报错），off模式则彻底禁用模块功能导致go mod命令失效；必须显式设为on才能启用模块机制并支持go mod vendor等离线操作。
闭网环境下 Go Modules 能用，但必须提前缓存好所有依赖，且不能依赖远程解析；GO111MODULE=on 是硬性前提，否则连 go mod init 都会 fallback 到 GOPATH 模式并失败。
为什么 GO111MODULE=on 在闭网环境里比平时更关键
闭网时 GO111MODULE=auto 会尝试判断当前路径是否在 GOPATH/src 下——但你很可能不在（比如在 /home/user/myapp），结果直接报错：no required module provides package。而 off 模式则彻底禁用模块功能，go mod 命令全部失效，go get 会往 GOPATH/src 写，但你根本没联网拉不到代码。
所以必须显式执行：
go env -w GO111MODULE=on
这个设置只影响模块行为，不依赖网络，闭网下也完全生效。
go mod vendor 是闭网开发的刚需操作
闭网时 go build 或 go test 若发现某个包没在本地，会卡住或报 cannot find module —— 因为它默认仍尝试走 GOPROXY 或直接 git clone。
解决办法是把所有依赖“打包”进项目本地：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 确保项目已有
go.mod和完整依赖（需在有网机器上先跑过go mod tidy） - 运行
go mod vendor，生成vendor/目录 - 后续所有命令加
-mod=vendor参数，例如：go build -mod=vendor、go test -mod=vendor -
go mod vendor不会改go.sum，但会把go.sum中列出的所有模块版本完整复制进vendor/
注意：go mod vendor 后，go list -m all 仍显示远程路径，但实际编译时已不依赖网络。
私有模块和替换路径在闭网中要手动固化
如果你的项目依赖公司内网 Git 仓库（如 git.internal.company.com/lib/util），闭网时 go mod download 必然失败，除非提前配置：
- 设
go env -w GOPRIVATE=git.internal.company.com，避免 Go 尝试走代理 - 若该模块还没发布 tag，或你正在本地联调，需用
replace指向本地路径：replace git.internal.company.com/lib/util => ./util -
replace行必须在有网时就写进go.mod并运行go mod tidy，否则闭网后go mod vendor不会包含它 - 验证是否生效：
go list -m git.internal.company.com/lib/util应输出带=> ./util的行
go.sum 文件必须随项目一起带入闭网环境
go.sum 不是可选文件，它是校验依赖完整性的唯一依据。闭网后若缺失某行 checksum，go build -mod=vendor 仍可能报 checksum mismatch —— 因为 Go 会校验 vendor/ 里每个包的哈希是否与 go.sum 记录一致。
常见疏漏点：
- 手动删过
go.sum或清过vendor/，但没重新go mod tidy（有网时）再go mod vendor - 用了
go mod vendor -v清理冗余，但没同步更新go.sum（其实go mod vendor本身不改go.sum，得靠go mod tidy保证一致性） - CI 构建脚本里漏了
go mod vendor步骤，导致传入闭网环境的压缩包里没有完整vendor/
最稳妥做法：所有依赖操作（go mod tidy、go mod vendor）都在有网机器完成，然后把整个项目目录（含 go.mod、go.sum、vendor/）打包带走。闭网机器上只做构建，不做任何 go mod 操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
