低配linux执行go mod download卡住是因内存不足被oom killer终止，解决方法为：禁用校验（gosumdb=off）、串行下载（xargs -n1 go get -d）、关闭cgo（cgo_enabled=0），避免vendor加重内存负担。
go mod download 卡在 fetching 阶段，不是网络慢，是资源不足被系统 kill 了
低配 Linux（比如 1GB 内存、无 swap 的云服务器或树莓派）上执行 go mod download 或 go build 时，常出现「卡住不动」或「中途静默退出」——dmesg 里能看到 Out of memory: Kill process go (pid XXX)...。这不是代理没配好，也不是 GOPROXY 不通，而是 Go 工具链并发下载+解压+校验时内存峰值超限，被内核 OOM killer 干掉了。
- 默认
go mod download会并发拉取所有依赖，每个模块解压+解析go.mod都要加载进内存；小内存机器上几十个包一齐来，很容易冲到 800MB+ 峰值 - 即使加了
-v也看不到明显日志，因为卡在底层net/http连接池和archive/zip解压阶段，不报错也不超时 -
go env -w GODEBUG=netdns=cgo这类调试开关对内存问题无效，别白试
用 -x + --no-sumdb + 串行下载三板斧压低内存占用
目标是让 Go 工具链「一次只干一件事」，避开并发高峰。不用改源码、不装额外工具，纯命令行可操作：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 先禁用 checksum 校验：执行
go env -w GOSUMDB=off（临时跳过go.sum网络校验，省下大量 TLS 和 HTTP 连接开销） - 用
-x暴露每一步动作，方便定位卡点：go mod download -x 2>&1 | grep "curl\|unzip"，确认是否真卡在解压环节 - 最关键的：把并发数压到 1 —— Go 没提供直接参数，但可用
GOPROXY=direct强制本地模式，再配合find+xargs -n1逐个拉：go list -m -f '{{.Path}}' all | xargs -n1 go get -d（注意：必须在模块根目录下运行，且确保go.mod已存在） - 如果连
go list -m all都卡，说明go.mod里已有间接依赖但本地没缓存，此时先删掉go.sum，再跑上面命令
CGO_ENABLED=0 不只是为交叉编译，更是低配机的救命开关
很多低配 Linux（如 Alpine 容器、Debian slim 镜像）默认没装 gcc、musl-dev 等 C 工具链。一旦项目里有 import "C"（哪怕只是某个依赖的 cgo 注释没删干净），go build 就会尝试调用 gcc，失败后反复重试+打印大量错误，看起来像「卡死」。
- 执行前务必加环境变量：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .（GOOS/GOARCH可按需换） - 别写成
go build CGO_ENABLED=0—— 这个参数会被当成包名，Go 直接忽略 - 如果项目确实依赖 C 库（如 SQLite、OpenSSL），那低配机上基本无解，要么换机器，要么改用纯 Go 实现的替代库（如
mattn/go-sqlite3改成glebarez/sqlite）
真正容易被忽略的是：go mod vendor 在低配机上比 go mod download 更吃内存
很多人想「先 vendor 再构建」来规避网络问题，结果 go mod vendor 会把所有依赖复制进本地 vendor/ 目录，同时做完整路径重写和符号链接处理——这步内存峰值比 download 还高 30%。小内存机器上，它可能成功拉完依赖，却倒在最后一步 cp -r 上。不如老老实实走 CGO_ENABLED=0 + GOSUMDB=off + 串行 go get -d 这条路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
