goroot 和 gobin 必须指向同一安装路径，go111module=on 是团队硬性开关，gopath 不用作项目根目录，交叉编译前必须禁用 cgo。
GOROOT 和 GOBIN 必须指向同一安装路径
很多团队在多人协作时出现 go version 显示正常，但 go build 报错 “cannot find package” 或编译产物运行失败，根源常是 GOROOT 和实际 go 可执行文件所在位置不一致。Windows 上尤其常见：有人手动把 go.exe 复制到别的 bin 目录，却没同步更新 GOROOT。
验证方法很简单：
- 运行
where go（Windows）或which go（macOS/Linux），看输出路径 - 运行
go env GOROOT，对比是否完全一致 - 若不一致，用
go env -w GOROOT="C:\Go"（Windows）或go env -w GOROOT="/usr/local/go"（macOS/Linux）强制修正
注意：GOBIN 不必单独设——现代 Go 默认使用 $GOROOT/bin，额外设置反而容易引发 PATH 冲突。
GO111MODULE=on 是团队统一的硬性开关
团队里只要有一人没开模块（GO111MODULE=off），就可能让 go mod init 生成错误的 go.mod，或导致 go get 拉取本地 GOPATH 下的旧包而非远程版本。这不是“建议”，而是必须强制的配置项。
执行这条命令一次，全团队生效：
go env -w GO111MODULE=on
顺手加上国内代理（避免 CI 构建卡死）：
go env -w GOPROXY=https://goproxy.cn,direct
如果项目已有 go.mod，但 go list -m all 显示依赖版本混乱，直接删掉 go.sum 并运行 go mod tidy ——不要手动编辑 go.mod。
不要把 GOPATH 当项目根目录来用
新手常犯的错：把整个项目 clone 到 $GOPATH/src/github.com/xxx/yyy，再用 go run . 启动。这在 Go 1.16+ 已无必要，且会干扰模块感知——go 工具链优先按当前目录是否有 go.mod 判断是否启用模块，而不是看路径是否在 GOPATH/src 下。
正确做法只有两条：
- 项目根目录执行
go mod init example.com/myapp（域名无关，只是模块路径标识） -
GOPATH只用来存go install安装的工具（如gopls、staticcheck），不是放业务代码的地方
如果 VS Code 提示 package main 爆红，先检查当前目录是否存在 go.mod；没有就 go mod init，有就确认 go env GOPATH 输出的路径下没有同名子目录干扰模块解析。
交叉编译前务必禁用 CGO
团队部署到 Linux 服务器时，本地 macOS 或 Windows 编译出的二进制偶尔启动失败，报错类似 libc.so.6: cannot open shared object file，基本就是 CGO 没关干净。
根本原因：CGO_ENABLED=1（默认值）会让 Go 链接系统 libc，而不同 OS 的 libc 版本和 ABI 不兼容。
安全做法是所有生产构建都显式关闭：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o mysvc main.go
如果项目真要调 C 库（比如 SQLite、OpenSSL），那得在目标环境装对应 dev 包，并确保 CI 构建机和线上环境 libc 版本一致——这对多数服务来说，远不如用纯 Go 替代方案省心。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
