Go高并发应用需≥1.21版本、正确配置GOPROXY、禁用GOPATH、显式设置GOMAXPROCS，否则将引发goroutine泄漏、channel死锁、依赖拉取失败及环境不一致等问题。
go 命令能跑起来，不代表高并发应用就 ready 了。环境没搭对，后面 goroutine 泄漏、channel 死锁、依赖拉不下来、本地调试和线上行为不一致——全都会在压测时集中爆发。
Go 版本必须 ≥1.21
go-zero、gRPC-Go v1.50+、Gin v1.10+ 等主流框架已弃用旧版 runtime 的调度逻辑。低于 go1.21 会导致：
-
runtime/trace输出缺失关键调度事件，性能分析失效 -
net/http的连接复用策略降级，QPS 直接掉 20%+ - 某些
sync.Pool行为异常，对象复用率下降，GC 频率升高
验证方式：go version；升级路径：直接下载官方安装包，**不要**用系统包管理器（如 apt/yum），它们常滞后 2–3 个 minor 版本。
模块代理和 GOPROXY 必须设对
国内不配代理，go mod download 会卡在 proxy.golang.org，超时后 fallback 到 direct，再触发 checksum mismatch 错误。
- 推荐配置：
export GOPROXY=https://goproxy.cn,direct - 验证是否生效：
go env GOPROXY应输出该值 - 若公司有私有 registry，把
goproxy.cn换成内部地址，并补上GOSUMDB=off（仅限内网可信环境）
注意：go mod tidy 第一次执行时会缓存 module，后续即使改了 GOPROXY 也不会重拉——删掉 $GOPATH/pkg/mod/cache/download 再试。
立即学习“go语言免费学习笔记（深入）”；
GOROOT 和 GOPATH 不要混用
Go 1.16+ 默认启用 GO111MODULE=on，但很多人仍手动设置 GOPATH，结果：
- 编辑器（如 VS Code）识别错 module root，跳转失效
-
go build找不到本地 replace 路径，报cannot load ...: module ... not found - CI 构建时因
GOPATH未清理，意外复用旧 cache，编译出错
正确做法：彻底删除 GOPATH 环境变量，所有项目用 go mod init xxx 初始化，依赖全走 go.mod 管理。唯一需要 GOPATH 的场景只剩 go install 安装 CLI 工具——那也建议用 go install -m=xxx@latest 显式指定版本。
别忽略 GOMAXPROCS 和资源限制
默认 GOMAXPROCS 等于 CPU 核心数，但在容器里常被 cgroup 限制，导致实际可用 P 数远小于预期。
- 查真实值：
go run -gcflags="-m" main.go 2>&1 | grep "GOMAXPROCS" - 启动时显式设值：
GOMAXPROCS=4 ./myapp（根据容器 CPU limit 设置） - 更稳妥的做法是在
main()开头加：runtime.GOMAXPROCS(runtime.NumCPU())，但需配合docker --cpus=4使用
容易被忽略的是：goroutine 泄漏往往不是代码写错，而是环境没设对——比如本地开发机 16 核，测试环境只给 2 核，time.After + channel 组合在低核数下更容易堆积未消费的 goroutine。
