大型项目golangci-lint卡死或超时，主因是默认扫描vendor等无关目录、未跳过生成代码、并发过高引发GC与内存带宽瓶颈、缓存未稳；应显式配置skip-dirs、concurrency:2–3、timeout:3–5m、modules-download-mode:readonly并固定缓存路径。
大型代码库用默认配置跑 golangci-lint，基本等于卡死或超时失败——不是工具不行，是没关掉 vendor、没跳过生成代码、没压住并发、也没稳住缓存。
为什么 golangci-lint run 在大型项目里动不动就 2 分钟起跳？
根本原因不是 CPU 不够，而是它默认把整个目录树（包括 vendor/、testdata/、examples/、甚至 gen/ 下的 Go 文件）全塞进分析流水线。每个 linter 都要重新加载类型信息，而 go/types 在百万行级项目里反复解析模块，GC 压力陡增，内存带宽打满，结果就是高并发下越跑越慢、越慢越卡。
- 别信
--fast：它直接砍掉staticcheck和unused，等于放弃最核心的语义检查 -
skip-dirs必须显式写死在.golangci.yml的run段里，而不是靠.gitignore—— 默认不读 - 如果项目有大量
replace或本地 module，modules-download-mode: "readonly"是刚需，否则并发下会抢go.mod锁，直接 hang 住
concurrency 和 timeout 怎么配才不翻车？
在 4 核 8G 的 CI 环境（比如 GitHub Actions ubuntu-latest）上，concurrency: 4 + timeout: 2m 的失败率比 concurrency: 2 + timeout: 3m 高出近 3 倍。这不是玄学，是 GC 和内存带宽瓶颈的真实反馈。
- 中小项目（concurrency: 2，
timeout: 2m足够 - 大型单体（>50 万行）：
concurrency: 3是甜点，timeout: 5m起步；再往上加并发，收益断崖下跌 - 永远不要设
concurrency: 0—— 它不会自适应，而是退化成单线程，耗时可能翻 3–5 倍 - CI 中必须显式写死
concurrency，不能依赖机器核数，否则本地和 CI 行为不一致
输出报告总“看不见问题”，到底是哪一环断了？
CI 里 ::error file= 不标红、Jenkins 显示 0 issues，90% 是因为 --out-format 没走对路。配置文件里写了 github-actions 格式，但命令行没传 --out-format=github-actions，它就还是输出彩色终端文本——机器根本没法解析。
-
output.formats只能选一个：想给 GitHub Actions 用，就只配format: github-actions；想存 JSON 后续处理，就只配format: json，混用无效 -
github-actions格式不支持path: -或空值，必须指定具体路径或留stdout；写错会静默失败 -
issues.max-issues-per-linter: 0必须设，否则staticcheck超过 50 条就截断，深层问题直接消失 -
exclude-rules必须放在issues下，写在linters-settings里完全不生效
缓存不稳，等于没优化
本地开发时加 -v 看日志，如果没出现 cache hit 或 loaded from cache，说明缓存根本没用上。CI 里更麻烦：缓存路径不固定、没挂载卷、没跨 job 复用，每次都是冷启动。
- 本地：设环境变量
GOLANGCI_LINT_CACHE=$HOME/.cache/golangci-lint - GitHub Actions：必须同时做三件事——设
GOLANGCI_LINT_CACHE: /tmp/golangci-cache、用actions/cache持久化该路径、确保工作目录是项目根（否则路径错位） - 别用
~/.cache这类相对路径写死在配置里，CI 容器里~可能指向不可写位置
真正难调的不是数字本身，而是同一组参数在 Go 1.21 和 Go 1.22+ 下表现差异极大——尤其泛型密集型代码，staticcheck 分析耗时能差 2 倍。上线前务必在目标 Go 版本下实测。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
