golangci-lint 本身无 warning/error 分级，靠 issues-exit-code 控制 CI 是否失败（设为1则任一issue均导致失败），IDE中严重性需单独配置；本地不报错而CI失败常因环境不一致致AST解析失败，须确保go build通过、GO111MODULE=on、Go版本≥1.16且go.mod已提交。
golangci-lint 里怎么设 warning / error 级别
它本身没有传统意义上的「warning / error」分级，而是靠 issues-exit-code 和 IDE 的严重性映射来体现。真正起作用的是：哪些问题被报告、报告后是否中断流程、以及在编辑器里用什么颜色/图标标出。
关键配置在 .golangci.yml 的 run 和 output 区块：
-
issues-exit-code: 1—— 只要有任意一个 issue（无论类型），就返回非零码，CI 会失败；设为0则永远不失败（不推荐） -
output.print-issued-lines: true和output.print-linter-name: true能让每条输出带上下文和来源 linter，方便判断轻重 - GoLand 或 VS Code 中的「严重性级别」是独立配置项，和 YAML 无关：在 IDE 设置里进
Go | 静态分析器 → 配置严重性，可把staticcheck设为 Error，unused设为 Warning
为什么本地不报错、CI 却因 lint 失败
常见不是规则太严，而是环境没对齐导致解析失败，继而触发大量 undefined: xxx 类错误 —— 这类问题被当成普通 issue，但本质是 linter 根本没成功加载 AST。
- CI 中
go build ./必须能过，否则golangci-lint run一定失败；检查GO111MODULE=on和 Go 版本（≥ 1.16） - 确保
go.mod已提交，且无未同步的replace指向本地路径 - CI 缓存了旧版
golangci-lint二进制？不同版本对泛型或模块路径的解析行为可能不一致，尤其staticcheck在 1.21 和 1.22+ 表现不同 - 别在 CI 命令里加
--fast：它跳过部分 linter（如unused），但也会绕过缓存重建逻辑，反而让某些问题漏检或误判
如何让特定规则不导致构建失败
不能靠“降级为 warning”，只能控制「是否报告」或「是否计入退出码」。最稳妥的做法是分类过滤：
立即学习“go语言免费学习笔记（深入）”；
- 用
issues.max-same-issues: 1限制重复告警刷屏，避免单个问题淹没真正风险 - 对低价值规则直接禁用：
disable: ["golint", "maligned"]，而不是留着再调级别 - 用
exclude-rules屏蔽特定文件或模式的 issue，例如忽略 testdata 里的sqlrows报错：exclude-rules: - path: "testdata/.*" linters: - "sqlrows" - CI 中若需宽松策略（如仅做提示），可用
--out-format=github-actions+issues-exit-code: 0，但必须配套人工 review 机制，否则等于关掉门禁
容易被忽略的 exit-code 行为细节
issues-exit-code 不是“有 error 就退出”，而是“只要输出了 issue 行，就按该值退出”——哪怕所有 issue 都来自 gosimple 这种风格建议，也会触发失败。
这意味着：
- 别指望靠 IDE 里调低严重性来影响 CI 行为；IDE 设置只改高亮，不影响 exit code
-
run.timeout超时会导致退出码为124（不是issues-exit-code指定的值），CI 流程需额外捕获这个信号 - 如果用了
--fix，修复成功后 issue 数归零，自然不会触发issues-exit-code；但自动修复有风险，尤其涉及 error handling 或并发逻辑时，别在 CI 主流程启用
