Go 1.22+ 彻底移除 GOPATH 依赖，其配置已失效且可能干扰 go install；go env GOPATH 应为空或仅作缓存路径，模块构建完全基于 go.mod 和 vendor 目录，后者在 CI/CD 中必须启用以保障离线、可重现构建。
Go 1.22+ 版本下 GOPATH 已失效，别再写进 .bashrc
Go 1.16 起默认启用 go modules，1.22 彻底移除对 GOPATH 的依赖逻辑。你如果还在 .bashrc 或 .zshrc 里 export GOPATH，不仅没用，还可能干扰 go install 的二进制安装路径（比如 go install github.com/xxx/cli@latest 会默认装到 $HOME/go/bin，但若你设了 GOPATH，它可能误用你的旧路径）。
验证方式很简单：go env GOPATH 应该返回空或只显示默认值（如 /home/xxx/go），且这个路径仅用于 go get 旧式包管理时的缓存，不参与构建。
- 删掉所有 shell 配置文件中关于
GOPATH的 export 行 -
go env -w GOMODCACHE=$HOME/.cache/go-mod—— 显式指定模块缓存位置，避免散落在$GOPATH/pkg/mod - 确认
GOBIN未被手动设置；如有，删掉——go install现在统一走$HOME/go/bin（macOS/Linux）或%USERPROFILE%\go\bin（Windows）
go mod init 不等于项目就“能跑”，vendor 目录不是可选配件
很多新手执行 go mod init myapp 后直接 go run .，结果报错 cannot find module providing package xxx。这不是模块没初始化，而是本地依赖未锁定、远程包版本漂移或私有仓库认证缺失。
vendor 在 CI/CD 或多团队协作中仍是刚需：它让 go build 完全离线、版本确定、不受上游 tag 删除或分支 force push 影响。
- 首次拉取依赖后立即执行
go mod vendor，生成vendor/目录 - 把
vendor/加入 Git —— 别信“go modules 就不用管 vendor”的说法，生产环境必须保证可重现 - 若用私有 Git 仓库（如 GitLab 自建），需提前配置
go env -w GOPRIVATE=git.example.com/mygroup，否则go mod download会因 401 失败
CGO_ENABLED=0 不是万能开关，交叉编译时 libc 依赖仍会漏判
想编译纯静态二进制？设 CGO_ENABLED=0 确实能绕过 libc，但部分标准库（如 net、os/user）在禁用 CGO 后行为会退化：DNS 解析 fallback 到纯 Go 实现（慢且不支持某些记录类型），user.Lookup 返回空用户名等。
立即学习“go语言免费学习笔记（深入）”；
更隐蔽的问题是：某些第三方包（如 github.com/mattn/go-sqlite3）强制依赖 CGO，设 CGO_ENABLED=0 会导致构建失败，错误信息常被淹没在一堆 #cgo 报错里。
- 先运行
go list -deps ./... | grep cgo检查是否有 CGO 依赖 - 若必须静态链接且含 sqlite，改用
github.com/glebarez/sqlite（纯 Go 实现）替代 - 交叉编译 Linux 二进制到 macOS 时，即使
CGO_ENABLED=0，也要加GOOS=linux GOARCH=amd64，否则默认用宿主机平台，容易忽略目标系统 ABI 差异
go test -race 不是“一键开箱即用”，它会掩盖真实并发问题
go test -race 能检测数据竞争，但它的运行时开销大（内存翻倍、速度降 2–3 倍），且**只报告已触发的竞争事件**。如果测试用例没真正并发执行读写，race detector 就不会报警——这正是多数人误以为“没报错=线程安全”的根源。
更麻烦的是，开启 race 检测后，调度器行为改变，原本偶发的 goroutine 死锁或 channel 阻塞可能被掩盖或延迟暴露。
- 不要只靠
-race过 CI；对关键临界区（如全局计数器、连接池）手写并发测试，显式启动 100+ goroutine 并发调用 - 用
go tool trace查看真实 goroutine 执行轨迹，比 race report 更早发现调度倾斜 - 若项目用
sync.Pool，务必在测试中调用pool.Put后再pool.Get，否则 race detector 可能漏掉对象复用导致的指针重用问题
go build 成功、go test 通过、服务跑起来也正常时，线上某次高峰流量突然出现 goroutine 泄漏或内存持续上涨——那些问题，往往藏在 vendor 里某个包的 init 函数、CGO 回调的生命周期管理、或是 test 中没覆盖到的并发边界条件里。 
