golangci-lint 通过 issues.max-issues-per-linter 限制单个 linter 总告警数，通过 issues.max-same-issues 合并相同错误模板（如 SA1019）的重复告警，默认最多显示 3 次；二者均属顶层配置，不支持按规则 ID 精确限流。
golangci-lint 里怎么控制同一类告警最多显示几条
它用 max-issues-per-linter 控制单个 linter 输出的告警总数上限，但**不支持按“告警类型”（比如 SA1019、ST1005）分别限流**。所谓“同一类型告警最多 N 条”，实际得靠组合两个配置项实现：一是限制每个 linter 的总输出数，二是靠 max-same-issues 压缩重复模式。
常见错误现象是：staticcheck 在一个文件里对几十个 time.After 报 SA1015，刷屏到根本看不到其他问题；或者 revive 对上百个命名风格不一致的地方狂报，掩盖真正该修的逻辑缺陷。
-
max-issues-per-linter是硬上限，比如设为30，那staticcheck最多只报告前 30 个问题，不管是不是同一类 -
max-same-issues才管“相似性”：它会把堆栈位置不同但错误信息完全一致（或高度相似）的告警合并计数，超过阈值就折叠。默认值是3，意味着相同错误模板最多显示 3 次 - 这两个参数都属于
issues段，必须写在顶层，不能嵌套进某个 linter 的 settings 里
示例配置片段：
issues: max-issues-per-linter: 50 max-same-issues: 5
为什么 max-same-issues 不总是生效
它依赖 linter 自身是否提供足够稳定的错误指纹。比如 govet 的 printf 类型不匹配，每次参数不同就会生成不同消息，max-same-issues 基本无效；而 staticcheck 的 SA 系列规则（如 SA1019 调用弃用函数）错误模板固定，就压得住。
- 检查你用的 linter 是否在文档里明确说明支持去重 ——
staticcheck、revive支持较好，errcheck和gosimple效果有限 - 别调高
max-same-issues到 20+：看似“看到更多”，实则让真正分散的问题被淹没，失去告警提示价值 - 如果某类告警反复出现且无法收敛（比如大量未处理 error），优先查代码模式，而不是调参 —— 这说明
errcheck正在正确地暴露系统性疏漏
想精准按规则 ID 限流？目前做不到
golangci-lint v2 没有提供类似 staticcheck.SA1019.max-count: 3 这种细粒度控制。所有规则 ID（SA/ST/DE 等）共享同一个 max-same-issues 计数器。
- 真要隔离某条规则的输出量，只能临时禁用它：
disable: ["staticcheck"]，再单独用staticcheck命令跑一次并加-f=stylish -checks=SA1019 - 或者改用
--out-format=json导出后用脚本过滤，但这就脱离了原生 lint 流程 - 社区已有相关 issue（#3287），但截至 2026 年 10 月仍属 “help wanted” 状态，没进主线
最常被忽略的一点：这些限制只影响终端输出和 JSON 报告里的条目数，**不影响 exit code 和 CI 门禁结果**。哪怕只显示 3 条，只要存在 1 条未修复的 errcheck 告警，CI 依然会失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
