go mod tidy 不会直接导致 OOM，但解析庞大模块图、循环引用、大量 replace 或间接依赖爆炸时，工具链可能因内存超限而崩溃；可通过清空 go.sum、设置 GOMEMLIMIT、禁用 vendor、拆解 list 操作及排查高频间接依赖来安全执行。
go mod 本身不会直接导致内存溢出，但你在执行 go mod tidy、go build 或 go list -m all 等依赖解析操作时，如果模块图庞大、存在循环引用、或 vendor 目录混乱，Go 工具链可能在构建依赖图阶段分配大量内存，最终触发 runtime: out of memory。
这不是 Go runtime 的 bug，而是依赖规模 + 工具链内存模型共同作用的结果。下面直说怎么压住它。
go mod tidy 卡住或 OOM 的常见诱因
不是网络慢，也不是磁盘满——是 Go 在解析 go.sum 和遍历 module graph 时，把所有模块元数据（版本、require、replace、exclude）全 load 到内存里做拓扑排序和一致性校验。
- 项目引入了上百个间接依赖，且其中包含多个 fork 分支（比如
github.com/xxx/repo v1.2.3和github.com/yyy/repo v1.2.4同时存在） -
go.mod里写了大量replace，尤其是指向本地路径或私有 Git 仓库，Go 会为每个replace尝试读取其go.mod并递归解析 - 存在隐式
indirect依赖爆炸：某个库的test依赖被带入主模块（例如用_ "some/test-only/pkg"），而该 test 包又拉了 heavy 的工具链依赖 - 使用了
go.work且 workspace 内模块数 > 20，Go 1.22+ 虽优化了 workspace 解析，但仍有显著内存增幅
如何安全执行 go mod tidy 不崩
别一上来就 go mod tidy -v，尤其在 CI 或低内存机器上。先做减法：
- 临时清空
go.sum（保留go.mod），再运行go mod tidy -e（-e表示容忍错误，不 panic）；成功后再补回 checksum - 用
GOMEMLIMIT=1.5GiB限制 Go 工具链自身内存上限，避免吃光整机 RSS：GOMEMLIMIT=1.5GiB go mod tidy - 拆解操作：先
go list -m all | head -n 50看前 50 个模块是否能列出来；卡住就说明 module graph 某处有环或 unreachable repo - 禁用 vendor：加
-mod=readonly避免 Go 尝试同步 vendor 目录（vendor 冗余时会加剧内存压力）
排查间接依赖爆炸的实操命令
真正占内存的是那些你没显式 require、却通过 transitive 依赖悄悄进来的模块。用以下组合快速定位：
-
go list -m -u -f '{{if not .Indirect}}{{.}}{{end}}' all：只列出直接依赖（去掉indirect标记的） -
go list -m -f '{{.Path}} {{.Version}}' all | grep -E "(test|tool|dev)"：筛出疑似测试/开发依赖的模块（如golang.org/x/tools、gotest.tools） -
go mod graph | awk '{print $2}' | sort | uniq -c | sort -nr | head -20：看哪些模块被最多其他模块引用（高频节点可能是内存热点）
如果发现某个 xxx/testutil 被 37 个模块引用，但它本身 require 了 google.golang.org/protobuf + github.com/spf13/cobra，基本就是它在撑大内存图。
立即学习“go语言免费学习笔记（深入）”；
vendor 目录引发的静默 OOM
go mod vendor 不是“复制一份就完事”。它会递归解析所有 require 的模块，并为每个模块提取全部 .go 文件——包括 internal/、testdata/、甚至 examples/ 下的文件。一个带 20MB testdata 的库，会被完整拷进 vendor。
- 检查 vendor 大小：
du -sh vendor/ | grep G，超过 500MB 就要警惕 - 用
go mod vendor -v观察输出末尾是否出现大量copying xxx/testdata/... - 解决方案不是删 vendor，而是用
go mod edit -dropreplace=xxx或go mod edit -exclude=xxx主动切断不需要的依赖路径，再go mod tidy重算
真正难搞的不是某一行代码，而是依赖图里没人维护的旧模块——它们可能已删 repo、改 license、或硬编码了不存在的 commit hash，导致 Go 工具链反复 retry + alloc buffer，直到 OOM。
