超时时间必须显式配置在 .golangci.yml 的 run.timeout 字段，顶格书写如 run: timeout: 3m，单位支持 s/m/h，设太短会导致假失败，推荐 CI 中设为 3m–5m 并配合 concurrency: 2 和 modules-download-mode: readonly。
超时时间必须显式配置在 .golangci.yml 的 run.timeout 字段，不设就用默认值（通常 1m），但 Go Modules 项目中极易因 typecheck 或泛型分析卡死，实际应设为 3–5 分钟。
timeout 值写在哪、怎么写才生效
它只在 run 段下有效，不是全局字段，也不是 linter 级别参数。写错位置（比如塞进 linters-settings）完全无效。
-
run:必须顶格，缩进 0 空格 -
timeout: 3m支持单位：s / m / h，不能写成180s（部分旧版本解析失败） - CI 中建议写死，别依赖本地 CPU 或环境变量；例如
timeout: 5m比timeout: 1m更稳妥 - 若同时配了
concurrency: 4，但timeout: 2m，实测失败率反而更高——高并发加剧 GC 压力，单个检查变慢，总耗时不降反升
为什么设太短会“假失败”
不是代码有问题，而是 golangci-lint 自己没跑完就被系统中断。典型现象：
- 输出只有
context deadline exceeded，无具体 linter 名或文件路径 - 退出码非 0，但 CI 日志里看不到任何报错详情
- 本地能过，CI 频繁失败 → 很可能只是 timeout 不够，尤其在 Go 1.22+ 处理复杂泛型时 staticcheck 耗时明显增加
timeout 和其他参数的联动陷阱
它和 modules-download-mode、skip-dirs 是强关联的。哪怕 timeout 设得再大，以下情况照样卡住：
立即学习“go语言免费学习笔记（深入）”；
- 没设
modules-download-mode: readonly→ 并发下 go.mod 锁争抢，直接挂死 - 没跳过
vendor或internal/gen→ 大量生成代码触发errcheck对proto.Unmarshal的误报，且逐文件加载拖慢整体 - 缓存未启用（
GOLANGCI_LINT_CACHE未固定路径或未挂载）→ 每次都是冷启动，耗时翻倍
真正难调的不是数字本身，而是同一组 timeout + concurrency 在 Go 1.21、1.22、1.23 下表现差异极大；别迷信“别人家的配置”，务必在自己项目的 CI 环境里实测。最稳的起点是 timeout: 3m + concurrency: 2 + modules-download-mode: readonly。
