golangci-lint OOM 主因是内存配置不足或扫描范围过大，非自身泄漏；需设容器 memory limit ≥2.5GiB、GOMEMLIMIT=1750MiB、-j 2、--fast，并禁用高开销 linter 或限制扫描路径。
直接说结论：golangci-lint 运行时 OOM，95% 不是它本身有泄漏，而是你给它的内存太小、或它要扫描的代码量远超预期——尤其在 CI 环境里用默认配置跑整个 monorepo 时，golangci-lint 会把所有包 AST 全加载进内存做跨文件分析。
为什么 golangci-lint 容器会 OOM？
它不是轻量级 linter，而是一个带缓存、并发、多 linter 聚合的分析引擎。几个关键事实：
-
golangci-lint启动后会预编译并缓存所有依赖包的 AST，内存占用≈（源码总行数 × 20~50 字节）+ Go 编译器开销；单个 50 万行项目轻松吃掉 1.2GB RSS - Docker 默认没设
--memory，宿主机内核看到它 RSS 暴涨就直接触发 OOM Killer，exit code 137就是铁证 - CI 流水线常复用基础镜像（如
golang:1.21），但该镜像没配GOMEMLIMIT，Go 运行时堆无软上限，容易冲破容器 memory limit - 启用
govet、staticcheck或自定义runner插件时，内存峰值会再 +30%~60%
golangci-lint 容器 OOM 的实操修复项
别急着调大内存，先压测定位瓶颈：
- 本地复现：用
docker run --rm -m 1g --memory-swap=1g -v $(pwd):/work -w /work golangci/golangci-lint:v1.57 golangci-lint run --timeout=5m --concurrency=4模拟 CI 环境，观察是否 OOM - 加
--mem-profile输出内存快照：golangci-lint run --mem-profile=mem.pprof，然后用go tool pprof mem.pprof查最大分配者（通常是go/types或golang.org/x/tools/go/ssa） - 禁用高开销 linter：在
.golangci.yml中关掉gosimple、unused、bodyclose等需要全 AST 分析的项，换成govet、errcheck这类轻量项 - 限制扫描范围：用
--skip-dirs排除vendor/、third_party/、testdata/；用--files只扫当前 PR 修改的文件（Git 集成方式见下条）
CI 流水线中安全运行 golangci-lint 的硬约束
容器环境必须同步满足三个条件，缺一不可：
立即学习“go语言免费学习笔记（深入）”；
- 容器内存 limit 设为至少
2.5GiB（docker run --memory=2.5g或 K8sresources.limits.memory: 2500Mi） - 启动时强制设
GOMEMLIMIT=1750MiB（即 limit 的 70%，防止 mmap/cgo 冲破边界） - 命令行加
-j 2（限制并发数）+--timeout=3m（防卡死）+--fast（跳过未修改文件的重复检查） - Git 集成写法（避免全量扫描）：
git diff --name-only origin/main...HEAD -- '*.go' | xargs golangci-lint run --files
最易被忽略的一点：很多团队在 .golangci.yml 里写了 run: timeout: 5m，但 Docker 容器没设 memory limit，导致 OOM Killer 在 3 分钟左右就把进程杀了——此时 golangci-lint 根本没机会输出 timeout 错误，只留下空日志和 exit code 137。内存限制和超时必须双控，且 limit 值得比 GOMEMLIMIT 高出至少 25% 才留出 mmap 余量。
