gocritic 必须显式启用，它默认不参与检查；需在 .golangci.yml 的 linters.enable 下添加 - gocritic，且不属任何 preset，不可依赖 enable-all，其 100+ 规则须按 check 粒度开关，并单独配置 timeout、max-same-issues 等参数。
gocritic 必须显式启用，它默认不参与检查
很多人以为 gocritic 是 golangci-lint 默认启用的 linter，其实不是——它被归类为「高价值但高噪声」的深度审查工具，必须手动加入 enable 列表，否则 golangci-lint run 完全不会调用它。
常见错误现象：配置了 linters-settings.gocritic 却没生效，终端输出里压根不出现 gocritic 的检查结果，甚至 golangci-lint linters 里也显示为 disabled 状态。
- 在
.golangci.yml的linters.enable下明确添加- gocritic - 避免与
enable-all: true混用——gocritic不在默认白名单中，enable-all也不会激活它 - 如果项目已启用
presets: ["bugs", "performance"]，注意gocritic不属于任何 preset，仍需单独写
gocritic 的 enabled-checks 控制粒度比其他 linter 更细
gocritic 不像 staticcheck 那样按 severity 分级，而是以「检查项（check）」为单位开关。它内置 100+ 个独立规则，比如 rangeValCopy、underef、unnecessaryBlock，每个都可单独启停。
不推荐直接开全：enabled-checks: ["all"] 容易触发大量低价值警告（如过度建议内联小函数），反而掩盖真正危险的模式（如 flagDeref 或 httpNoContentType）。
立即学习“go语言免费学习笔记（深入）”；
- 从高风险项开始：优先启用
"rangeValCopy"（循环中值拷贝）、"flagDeref"（未检查 flag 解析错误）、"httpNoContentType"（HTTP 响应缺 Content-Type） - 禁用易误报项：例如
"unlambda"（反对匿名函数字面量）在测试或 DSL 场景下常误报，加到disabled-checks更稳妥 - 路径级开关：用
exclude-rules把生成代码（如pb.go）或 vendor 目录整体排除，避免扫出无意义结果
gocritic 性能敏感，必须配合 concurrency 和 timeout 调整
gocritic 是所有内置 linter 中分析耗时最长的之一，尤其在含大量泛型或嵌套结构体的项目中。若不做限制，它可能拖慢整个 golangci-lint run 流程，甚至导致超时退出。
典型表现：CI 中 golangci-lint 卡住 2 分钟后报 timeout: 1m0s 错误，但去掉 gocritic 就秒过。
- 在
run区块下调低并发：把concurrency: 8改为concurrency: 4，缓解 CPU 争抢 - 单独为
gocritic设 timeout：用linters-settings.gocritic.timeout: 30s（单位是字符串，必须带s） - 跳过大文件：通过
skip-files排除.*_test\.go$或vendor/.*，避免扫描冗余内容
与 govet/staticcheck 冲突时，gocritic 优先级更低
gocritic 会复盖部分 govet 和 staticcheck 的检查范围（比如 printf 格式错误、nil 比较），但它的诊断信息更粗略、修复建议更弱。当多个 linter 同时报同一行问题，gocritic 的提示容易被忽略或覆盖。
实际调试中发现：某行 fmt.Printf("%s", nil) 同时触发 govet 的 printf 错误和 gocritic 的 badPrintf，但 IDE 只高亮前者，因为 govet 返回的 position 更精确。
- 保持
govet和staticcheck启用——它们仍是基础防线 -
gocritic应作为补充层，专注它独有的深度规则（如shadow、typeUnparen） - 若想统一输出，用
output.sort-order: ["linter", "severity"]让gocritic结果集中排布，方便人工聚焦
配置 gocritic 最容易被忽略的点是：它不继承全局 issues.max-issues-per-linter，必须在 linters-settings.gocritic 下单独设 max-same-issues，否则单个文件里几十个 rangeValCopy 警告会刷屏，根本看不到其他问题。
