真实瓶颈常在磁盘 I/O 和内存分配，而非 CPU 型号；$GOCACHE 和 $GOPATH/pkg/mod 所在磁盘性能及剩余空间、系统可用内存，才是影响 Go 开发体验的关键因素。
不高，但“不卡顿”和“能用”是两回事——真实瓶颈常在磁盘 I/O 和内存分配，而非 CPU 型号。
为什么 4 核 8GB 的机器跑 go test -race 还是卡死？
Go 编译本身轻量，单次 go build 对 CPU 压力很小；但开发中真正吃资源的是：go mod download（拉模块）、go test -race（开数据竞争检测）、gopls（VS Code 后台语言服务器）。这些操作会并发启动数十个 goroutine 和子进程，持续占内存。实测：中型服务启用 -race 时，峰值内存常超 6GB；若物理内存仅 8GB，又开了 Chrome + Docker，系统极易触发 OOM killer 杀掉 go test 进程。
- 小项目（纯标准库 + 少量模块）：2 核 4GB 足够，
go run main.go秒出结果 - 中型服务（含
gin、gorm、redis-go等 20+ 模块 +-race）：建议 ≥8 核 16GB，否则gopls响应延迟明显，编辑器光标卡顿 - 用
cgo或交叉编译（如 macOS → Linux ARM64）：此时clang或gcc成为瓶颈，主频比核心数更重要，别只盯着核数
$GOCACHE 和 $GOPATH/pkg/mod 放在哪块磁盘上，比 CPU 型号影响更大
Go 的缓存机制重度依赖高频小文件随机读写：go mod download 首次执行时，要解压并写入上千个模块 tar 包；go build 后续复用缓存时，又要密集读取 $GOCACHE 中的 .a 文件。机械硬盘（HDD）下，go list -m all 可能卡 3–5 秒；换成 NVMe SSD，基本无感。
-
$GOCACHE默认路径：$HOME/Library/Caches/go-build（macOS）、$HOME/.cache/go-build（Linux）、%LocalAppData%\go-build（Windows） -
$GOPATH/pkg/mod存放所有下载的模块，一个中型项目缓存常超 2GB，建议预留 ≥20GB 空间 - Docker 构建时，宿主机挂载的
/tmp或 volume 若落在 HDD 上，go build耗时翻倍——不是 CPU 不够，是磁盘慢
Windows 上 WSL2 和原生 go.exe，硬件压力模型完全不同
WSL2 是轻量虚拟机，内存默认只分给它 50% 物理内存，且不会自动释放空闲页。你开了个 go test -race 占了 6GB，WSL2 就真锁住这 6GB，宿主机立刻卡顿；而原生 Windows 下的 go.exe 走的是 Windows 内存管理，调度更直接，但要注意：GOROOT 别装在中文路径或 C:\Program Files 这类带空格的目录，某些 cgo 工具链会解析失败。
立即学习“go语言免费学习笔记（深入）”；
- WSL2 用户：运行
cat /proc/meminfo | grep MemAvailable看可用内存，再决定是否调高wsl.conf中的memory限制 - 原生 Windows 用户：安装 MSI 包时务必勾选
Add Go to PATH，否则go version一定报错 - 两者共存时，别让
GOBIN指向同一目录，容易因权限/符号链接冲突导致go install失败
真正该先查的不是 CPU 型号，而是 df -h $GOCACHE 和 free -h —— 缓存盘快没空间了，或者内存只剩 500MB，再好的 i9 也救不了 go mod download 的超时。
