并发数与超时需按项目规模和机器能力调优：中小项目建议concurrency: 2–4并显式指定，timeout设3–5m，配合skip-dirs、缓存及readonly模块模式，避免高并发引发GC压力与锁争抢导致卡死。
并发数设太高会吃光 CPU，超时太短会误杀正常检查；两者都得按项目规模和机器能力调，不是越大越好。
concurrency 参数怎么设才不卡死
默认值是机器 CPU 核心数，但实际中常导致 CI 机器负载飙高、其他任务被饿死。尤其在共享型 CI 环境（如 GitHub Actions 的 ubuntu-latest）上，8 核默认值很容易让 golangci-lint 抢光资源。
- 中小型项目（concurrency: 2 或
3就够用，响应快且稳定 - 大型单体项目（>50 万行）：可试
concurrency: 4，但必须配合skip-dirs过滤掉vendor、testdata和生成代码目录 - 别盲目写
concurrency: 0—— 它不会自动适配，而是退化成单线程，耗时可能翻 3–5 倍 - CI 中建议显式指定，避免依赖本地环境的 CPU 数，例如：
concurrency: 2写死在.golangci.yml的run段里
timeout 设置太短会导致检查中断并报错
常见现象是 context deadline exceeded 或直接退出码非 0，但没输出具体哪条规则失败。这不是代码问题，是 golangci-lint 自己没跑完就被系统掐了。
- 本地开发：设
timeout: 2m足够覆盖绝大多数项目，改完代码秒出结果 - CI 流水线：建议
timeout: 5m起步，若频繁超时，先确认是否启用了缓存（GOLANGCI_LINT_CACHE）和跳过了无关目录 - 别用
--fast换 timeout —— 它跳过unused、staticcheck等重量级 linter，等于自欺欺人 - 如果某次 PR 突然超时，优先查是不是新引入了巨量泛型代码或复杂嵌套模板 ——
staticcheck在 Go 1.22+ 对泛型分析更细，耗时明显增加
并发与超时组合使用时的真实瓶颈
很多人以为调高 concurrency 就能抵消 timeout 不足，其实反而更容易触发超时：并发高 → 内存分配激增 → GC 频繁 → 单个 linter 实例响应变慢 → 总体耗时不降反升。
立即学习“go语言免费学习笔记（深入）”；
- 实测发现：在 4 核 8G 的 CI 机器上，
concurrency: 4+timeout: 2m的失败率比concurrency: 2+timeout: 3m高出近 3 倍 - 关键点在于：linter 本身不是纯 CPU 绑定，它重度依赖 Go 的
go/types加载和类型推导，这部分受内存带宽和 GC 压力影响更大 - 最稳的组合是保守 concurrency（2–3）+ 合理 timeout（3–5m）+ 显式
skip-dirs+ 缓存启用 - 如果项目用了大量
replace或本地 module，务必确保modules-download-mode: "readonly"，否则并发下模块解析会争抢go.mod锁，直接卡死
真正难调的不是数字本身，而是不同 Go 版本下同一组参数表现差异很大 —— 比如 Go 1.21 和 1.23 对泛型包的类型检查开销能差一倍，上线前最好在目标 Go 版本下压测一轮。
