goproxy是解决国内go依赖拉取超时、404和校验失败的唯一可靠路径，必须显式配置如https://goproxy.cn,direct，direct必须置于末尾以确保私有模块直连。
go mod + GOPROXY 是异地依赖同步的唯一可靠路径
本地 go.mod 文件只能锁定版本，但无法解决团队成员在不同地区首次拉取依赖时超时、404 或校验失败的问题。真正起作用的是 GOPROXY 配置 —— 它决定了模块下载的源头和缓存行为。
国内开发者必须显式设置代理，否则默认直连 proxy.golang.org（不可达）：
-
go env -w GOPROXY=https://goproxy.cn,direct（推荐，响应快、镜像全） -
go env -w GOPROXY=https://proxy.golang.org,https://goproxy.cn,direct（兜底策略，先试官方再 fallback） - 若公司有私有代理（如 Nexus Go Repository），应设为
https://nexus.example.com/repository/golang/
注意：direct 末尾必须保留，否则私有模块（如 git.example.com/internal/lib）会因不匹配代理规则而失败。
交叉编译产物不能直接共享，但可统一构建环境
你不能把 macOS 上用 GOOS=linux GOARCH=amd64 go build 编译出的二进制文件，直接发给同事在 Windows 上运行 —— 它只适配目标平台，不是“跨平台可执行”。真正需要同步的是构建环境本身。
- 用
Dockerfile固定构建镜像（如golang:1.23-alpine），所有人在相同GOROOT、CGO_ENABLED和GOVERSION下编译 - 避免在 CI 中写
go install golang.org/x/tools/cmd/goimports@latest—— 不同时间拉取的版本可能不一致；改用 commit hash 或语义化版本：go install golang.org/x/tools/cmd/goimports@v0.15.0 - 本地开发若需快速验证跨平台行为，优先用
GOOS=xxx GOARCH=xxx go run main.go，而非生成文件再传输
缓存目录（$GOCACHE）异地无效，别试图 rsync
$GOCACHE 默认指向 $HOME/Library/Caches/go-build（macOS）、$HOME/.cache/go-build（Linux）或 %LocalAppData%\go-build（Windows）。它的内容是编译中间对象，与 CPU 指令集、系统调用 ABI、甚至 Go 工具链版本强绑定。
- 不同机器间拷贝
$GOCACHE目录会导致go build报错：invalid cache object或静默跳过缓存 - CI 环境中每次 clean 构建是常态，
$GOCACHE本就不该持久化；若想提速，用 GitHub Actions 的actions/cache缓存整个~/.cache/go-build（注意 key 要包含go-version和os） - 本地开发提速靠的是单机复用，不是跨机同步 —— 这是设计使然，不是配置缺陷
go.work 文件不适合跨区域协作
go.work 是 Go 1.18 引入的多模块工作区机制，用于本地调试多个未发布模块。但它**不参与版本控制同步**，也不被 go mod download 解析。
- 若你在 A 地电脑上用
go work init+go work use ./module-a ./module-b，B 地同事 clone 仓库后执行go build会报错：no required module provides package - 正确做法：每个子模块独立
go mod init，通过replace指向本地路径仅限临时调试；正式依赖一律走go get github.com/org/repo@v1.2.3 - CI 构建永远以
go.mod为准，忽略go.work—— 所以它本质是个人开发辅助，不是协同契约
异地协作最易被忽略的点：所有人必须运行 go env -w GOSUMDB=off 吗？不是。只要 go.sum 在 Git 中提交且未被篡改，GOSUMDB 就能自动校验；强行关掉反而掩盖了依赖被污染的风险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
