Go命令正常运行且GOPATH、GOMODCACHE路径可写，才是开源协作真正可用的起点；需验证go mod init和go get是否成功，配置GOPROXY=https://goproxy.cn,direct，并确保缓存目录有写权限。
go 命令能正常运行，且 go env GOPATH 和 go env GOMODCACHE 路径可写，才是开源协作真正可用的起点。光有 go version 成功输出远远不够。
验证 go 是否真能拉依赖、建模块
很多用户卡在 go get 超时或 go mod init 失败，不是因为没装 Go，而是网络或缓存路径权限问题。
- 运行 go mod init example.com/test，看是否生成 go.mod
- 接着执行 go get github.com/stretchr/testify@v1.8.4，观察是否卡在 “Fetching” 或报 cannot find module providing package
- 如果失败，先检查代理：运行 go env -w GOPROXY=https://goproxy.cn,direct（国内推荐）
- 再确认 GOMODCACHE 所在磁盘有写权限，比如 Windows 上默认在 %USERPROFILE%\go\pkg\mod，若用户目录加密或受限，go mod 会静默失败
GOROOT 和 GOBIN 不该手动硬编码
新版 Go（1.16+）已默认启用 modules，GOROOT 由安装程序自动设好，GOBIN 默认是 $GOPATH/bin。
- 不要手动在环境变量里写死 GOROOT=C:\Go，除非你用的是多版本共存场景（如 gvm 或 asdf）
- GOBIN 也不必显式设置；只要 $GOPATH/bin 在 PATH 中，go install 出的二进制就能全局调用
- 错误示范：export GOBIN=/usr/local/bin —— 这会导致 go install 把工具装到系统目录，可能因权限失败，也容易和包管理器冲突
项目初始化必须用 go mod init，不是放对目录就行
开源项目普遍要求模块路径（module path）与代码托管地址一致，比如 GitHub 仓库 github.com/owner/repo，就该：
- 先 cd 到项目根目录（即含 .git 的目录）
- 再运行 go mod init github.com/owner/repo，不能省略域名前缀
- 若漏掉 github.com/ 直接写 go mod init repo，后续 go get 引入时路径不匹配，其他协作者 go build 会报错找不到包
- 模块名一旦提交就不能轻易改，否则破坏导入兼容性；改名必须同步更新所有 import 语句，并发版时需按语义化版本规则处理
真正影响协作的是模块路径、代理配置和缓存目录的可写性，而不是“能不能跑 hello world”。很多 PR 被拒，只因 contributor 的 go mod tidy 生成了错误的 replace 或本地路径依赖。
