2gb内存服务器上go mod tidy卡住或oom，主因是并发解析依赖图致内存峰值超1.5gb；建议用-mod=readonly校验、go mod download分步拉取、设gonoproxy跳过校验，并将gocache移至tmpfs。
go mod tidy 在 2GB 内存服务器上卡住或 OOM
根本不是网络慢，而是 go mod tidy 默认会并发解析整个依赖图并下载校验，内存峰值常超 1.5GB。尤其当项目含大量间接依赖（如 golang.org/x/ 全家桶）时，go 进程容易被系统 OOM killer 杀掉。
实操建议：
- 加
-mod=readonly避免自动写入go.mod—— 多数情况下你只需要校验，不需修改依赖声明 - 用
go mod download -x分步拉取：先跑go list -m all | head -20看前 20 个主依赖，再逐批go mod download github.com/xxx/yyy@v1.2.3 - 临时限制并发：设环境变量
GOMODCACHE=/tmp/modcache（避免 SSD 小盘爆满），并执行go env -w GONOPROXY="*" GONOSUMDB="*"跳过校验（仅内网可信环境） - 若必须用
go mod vendor，先go mod download完再跑，否则 vendor 过程中仍会反复触发网络请求
依赖本地化后 go build 仍报 cannot find package
常见于 go mod vendor 后直接 go build，但 Go 并不会自动启用 vendor 目录 —— 它只在显式加 -mod=vendor 时才读 ./vendor，否则仍走 $GOPATH/pkg/mod 或网络。
实操建议：
- 确认 vendor 目录存在且非空：
ls -A ./vendor/modules.txt必须有内容，否则go mod vendor实际没生效 - 编译命令必须带
-mod=vendor：例如go build -mod=vendor -o app ./cmd/app - 不要混用
replace和vendor：若go.mod里有replace，go build -mod=vendor仍会按 replace 路径去找源码，而非 vendor 中的副本 - CI 构建脚本里务必检查
go version输出，Go 1.14+ 才完整支持-mod=vendor；旧版本需降级用GO111MODULE=off+ GOPATH 模式
CGO_ENABLED=0 导致某些包编译失败却找不到原因
不是所有包都兼容纯静态构建。net、os/user、database/sql 等标准库子包在 CGO_ENABLED=0 下会回退到纯 Go 实现，但部分第三方驱动（如 github.com/lib/pq）强制依赖 cgo，此时报错是 build constraints exclude all Go files，而非直观的 missing package。
实操建议：
- 先用
go list -f '{{.CgoFiles}}' ./...扫描项目里哪些包含 C 文件，再针对性处理 - 对必须用 cgo 的模块，改用构建标签隔离：
//go:build cgo+go build -tags cgo，其余路径保持CGO_ENABLED=0 - 交叉编译时注意：Linux 上设
CGO_ENABLED=0 GOOS=linux GOARCH=amd64是安全的；但 macOS 上禁用 cgo 可能导致 DNS 解析异常（net包 fallback 不稳定） - 若为容器部署，优先用
FROM golang:alpine镜像，它默认CGO_ENABLED=0且已预装 musl，比在 CentOS 上硬切更可靠
低配机器上 $GOCACHE 命中率低甚至不生效
$GOCACHE 默认路径在 $HOME/.cache/go-build，但在内存紧张的服务器上，Linux VFS 缓存机制会让磁盘 I/O 成瓶颈，且 go 工具链频繁读写小文件，SSD 性能不足时缓存反而拖慢整体速度。
实操建议：
- 把缓存挪到 tmpfs：
mkdir -p /dev/shm/go-cache && go env -w GOCACHE=/dev/shm/go-cache（需 root 权限挂载，或用mount -t tmpfs -o size=512M tmpfs /dev/shm） - 禁用冗余校验：加
-trimpath参数（减少路径哈希差异），同时设go env -w GODEBUG=gocacheverify=0关闭缓存校验（仅限可信构建环境） - 避免
go run：它绕过$GOCACHE，改用/tmp下临时目录；调试时用go build -o /tmp/a && /tmp/a才能复用缓存 - 检查是否被 CI 清理：Docker 构建中若每轮都重置
/root/.cache，缓存必然失效；应挂载 volume 或用docker build --cache-from复用层
真正卡住的往往不是 Go 编译器本身，而是低配环境下缓存策略、依赖解析和 cgo 切换之间的隐式冲突。每个参数开关背后都有明确的副作用，别盲目堆砌优化选项。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
