go build OOM被kill时，应立即执行三步缓解：①用free -h确认内存，若available＜2GB则sudo fallocate -l 2G /swapfile && sudo swapon /swapfile启用swap；②清理缓存go clean -cache -modcache；③禁用CGO（CGO_ENABLED=0）或关闭缓存（GOCACHE=off）。
go build 时 OOM 被 kill，怎么快速缓解？
直接原因是 go build 在解析大量模块依赖、类型检查和生成中间代码时，内存峰值远超可用物理内存（尤其在 GOOS=linux GOARCH=arm64 等多平台交叉编译场景下）。这不是 Go 编译器 bug，而是默认行为在资源受限机器上的自然表现。
- 先用
free -h确认当前可用内存 —— 如果Mem available小于 2GB，go build很可能被内核 OOM killer 杀掉（dmesg | grep -i "killed process"可验证） - 临时加 swap 最快：运行
sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile。注意别用swapon -a启动未配置的 swap，会报错 - 避免用
-a参数：它强制重编译所有依赖，内存压力翻倍；日常构建去掉这个 flag - 限制并发数：
GOMAXPROCS=2 go build比默认值更稳，尤其在 4 核以下机器上
模块缓存膨胀导致构建卡顿或失败
$GOCACHE 和 $GOPATH/pkg/mod 不清理，会让 go build 加载更多旧版本符号、重复解析、拖慢速度并抬高内存占用 —— 这类“隐性内存压力”常被忽略。
- 清空构建缓存：
go clean -cache（删$GOCACHE），不是rm -rf $GOPATH/pkg—— 后者可能破坏 vendor 构建一致性 - 清空模块下载缓存：
go clean -modcache（删$GOPATH/pkg/mod），适合刚升级 major 版本或切换分支后使用 - 查真实路径：
go env GOCACHE和go env GOPATH，确认你操作的是对的位置 - CI 或临时环境可关缓存：
GOCACHE=off go build，牺牲速度换确定性
CGO 启用后内存暴增怎么压？
启用 cgo 会让 Go 编译器调用 gcc 处理 C 代码，链接阶段额外加载系统头文件、静态库，内存占用常翻 2–3 倍。很多项目其实不需要它。
- 先确认是否真需 CGO：纯 Go 项目设
CGO_ENABLED=0再 build，能绕过整个 C 工具链 - 必须用 CGO 时，禁用调试信息：
go build -ldflags="-s -w"，减少符号表体积 - 避免无意义交叉编译：
GOOS=windows GOARCH=386 go build会触发额外 C runtime 链接，如非必要别这么干 - 检查
#cgo CFLAGS是否误含了大体积头文件路径（比如把/usr/include整个递归进去）
磁盘空间不足伪装成内存不足
当 /tmp 或 $GOCACHE 所在分区写满，go build 会在 tmpdir 创建临时对象文件失败，错误日志却显示 runtime: out of memory 或直接 panic —— 实际是 ENOSPC 被掩盖了。
立即学习“go语言免费学习笔记（深入）”；
- 查磁盘：
df -h /tmp和df -h $(go env GOCACHE | cut -d'/' -f1-3) - 清理临时文件：
rm -rf /tmp/go-build*（Go 构建临时目录命名规律） - 改缓存位置：
go env -w GOCACHE=$HOME/.cache/go-build，避开根分区小容量限制 - 别信 “no space left on device” 字符串匹配 —— 必须用
errors.Is(err, syscall.ENOSPC)判断才可靠
GOCACHE 路径不对 + /tmp 分区已满这三件事叠在一起。单独解决任一环节，都能让 build 恢复成功。 
