是。物理内存≤3GB时go mod tidy易卡死，因模块解析器内存不足导致反复GC和mmap失败；可通过GOMEMLIMIT、-mod=readonly、go mod download替代go get等缓解。
go mod tidy 卡住不动，是不是内存不够？
是。物理内存 ≤ 3GB 时，go mod tidy 或 go list -m all 极易卡死或超时，尤其在首次拉取大量依赖时。这不是网络慢，而是 Go 的模块解析器在内存不足时会反复 GC + mmap 失败，最终陷入不可响应状态。
- 检查当前可用内存：
free -h，若available小于 1.5G，基本可判定为内存瓶颈 - 临时缓解：运行前设
GOMEMLIMIT=1G（Go 1.21+），强制 runtime 限制堆上限，避免 OOM 触发内核 kill - 更有效做法：加
-mod=readonly参数跳过自动下载，只校验本地缓存 ——go mod tidy -mod=readonly - 别用
go get拉单个包，它会触发完整模块图重建；改用go mod download github.com/xxx/yyy@v1.2.3精准获取
VS Code 里 gopls 启动就卡死，怎么救？
gopls 默认启用模块加载和符号索引，在低配机上极易夯住 —— 表现为光标不动、Ctrl+Click 无响应、状态栏长期显示 “Loading packages…”。
- 必须关闭模块自动加载：在 VS Code 设置中添加
"go.goplsArgs": ["-rpc.trace", "-no-load-modules-on-open"] - 确认
gopls版本 ≥ v0.14.0（对应 Go 1.20+），旧版在小内存下解析逻辑更激进 - 删掉项目根目录下的
gopls.cache目录（通常在$HOME/.cache/gopls），避免残留索引污染 - 不要打开父目录或 workspace 含多个 go.mod 的文件夹，gopls 会尝试合并分析，内存翻倍上涨
go build -o xxx 链接阶段卡住十几秒，怎么回事？
不是编译慢，是 linker 在读取 $GOCACHE 中的归档文件时遭遇 I/O 延迟。旧硬件（尤其是 HDD）上，/home/user/.cache/go-build 路径若落在机械盘，单次链接可能阻塞 5–20 秒。
- 把
$GOCACHE指向 tmpfs：export GOCACHE=/dev/shm/go-build（需先mkdir -p /dev/shm/go-build） - 或直接挂载 tmpfs：
sudo mount -t tmpfs -o size=1G tmpfs /home/user/.cache/go-build - 验证是否生效：
go env GOCACHE输出应为你指定的新路径 - 注意：tmpfs 占用的是物理内存，别设超过可用 RAM 的 50%
私有模块 replace 后 still not found，是不是代理没关干净？
是。即使写了 replace example.com/internal => ./internal，如果 GOPROXY 仍为 https://proxy.golang.org，gopls 和 go mod 仍会尝试去公网查证模块存在性，低带宽+高延迟下直接超时卡死。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式禁用代理对私有域名的请求：
export GONOPROXY="example.com"（支持逗号分隔多个域名） - 同时设
GOPROXY=direct彻底绕过代理，仅在完全离线或全私有环境使用 - 检查是否被 shell 配置覆盖：
go env GOPROXY GONOPROXY，确保输出符合预期 - 执行
go mod download前先go clean -modcache，避免缓存里残留失败记录干扰后续解析
free -h 和 df -h，比盲目调参数更管用。 
