go mod download 默认将模块下载至单机全局共享的 $GOMODCACHE（如 $GOPATH/pkg/mod），不自动跨机器共享；团队一致依赖统一 GOPROXY、提交 go.mod/go.sum，并可选私有代理或挂载共享缓存目录。
go mod download 本身不共享，但缓存路径可以共享
go mod download 默认把包下到 $GOMODCACHE（通常是 $GOPATH/pkg/mod 或 ~/go/pkg/mod），这个目录是**单机全局共享**的，不是 per-project 的。所以“团队共享”不是靠命令本身，而是靠让多台机器共用同一个缓存位置，或统一走代理+校验机制。
常见误区是以为执行一次 go mod download 就能“同步到所有人”，其实它只影响当前机器的本地缓存。真正能让团队一致的关键点有三个：统一代理、提交 go.mod/go.sum、以及可选的集中式缓存服务。
- 所有成员必须把
go.mod和go.sum提交进 Git —— 这是版本一致的底线 -
go mod download在 CI 或本地执行时，只是填充本机$GOMODCACHE，不会上传或广播 - 如果团队机器都挂载了同一 NFS 目录作为
GOMODCACHE，那才真正实现物理级共享（但需注意并发写冲突和权限）
GOPROXY 是团队依赖可重现的核心
国内团队最常踩的坑是：有人能 go build 成功，有人失败，报错 Get "https://proxy.golang.org/...": dial tcp: lookup proxy.golang.org: no such host。这不是网络问题，而是 GOPROXY 没统一。
必须在所有开发机和 CI 环境中强制设置：
立即学习“go语言免费学习笔记（深入）”；
export GOPROXY=https://goproxy.cn,direct
或者更稳妥的写法（避免被子 shell 覆盖）：
go env -w GOPROXY=https://goproxy.cn,direct
这样所有 go get、go build、go mod download 都会走同一个可信源，且 direct 保底用于私有模块。
- 不要用
off或空值 —— 这会让 Go 尝试直连 GitHub，极大概率超时或限流 - 私有模块路径（如
git.internal.company/project）要加进GOPRIVATE，否则会被代理拦截 -
GOPROXY设置后，go mod download实际是从代理拉取，而非原始仓库，速度和稳定性都提升
如何安全地复用他人已下载的模块
直接拷贝 $GOPATH/pkg/mod 目录过去？不推荐。哈希校验可能失效，go.sum 里记录的 checksum 与实际文件不匹配时，go build 会直接报 checksum mismatch 错误。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
真正安全的复用方式只有两种：
- 让新机器也跑一遍
go mod download（前提是go.mod/go.sum已提交、GOPROXY已配置）—— 它会从代理拉取并自动校验 - 部署私有 Go Proxy（如 Athens），所有机器指向它；首次下载后，后续请求全部命中缓存，等效于“共享下载结果”
如果你在 Docker 构建中想复用宿主机缓存，得显式挂载：
docker run -v $(go env GOMODCACHE):/go/pkg/mod golang:1.21 go build
注意：GOMODCACHE 路径必须一致，且容器内用户要有写权限。
GOMODCACHE 自定义后容易忽略的权限问题
很多人为了节省 SSD 空间，把 GOMODCACHE 改到大容量盘（比如 /data/gomod），然后发现 go mod download 报 permission denied。
根本原因不是路径错，而是 Go 进程没权限在目标目录创建子目录或写文件。尤其在 Linux 上，如果该目录由 root 创建、权限为 755，普通用户就无法写入。
验证和修复步骤：
- 运行
go env GOMODCACHE确认路径输出正确 - 手动
ls -ld $(go env GOMODCACHE)查 owner 和 perm - 确保目录属主是你当前用户，且至少有
drwxr-xr-x（即 755） - 必要时执行
sudo chown -R $USER:$USER /data/gomod
Windows 用户还要避开路径含中文、空格或过长的问题 —— Go 对这类路径的处理仍不稳定。
