.golangci.yml中排除文件或目录必须用run.skip-dirs或run.skip-files，不能仅靠issues.exclude-rules；后者只过滤报告不跳过扫描，影响性能和稳定性。
golangci-lint 的 .golangci.yml 排除规则怎么写才生效
排除文件或目录必须用 run.skip-dirs 或 run.skip-files，不能只靠 issues.exclude-rules —— 后者只过滤已触发的 lint 报告，不跳过扫描本身，性能和误报都受影响。
常见错误是把 vendor/ 或 mocks/ 写进 issues.exclude-rules.pattern，结果 golangci-lint 仍会解析这些目录里的 Go 文件，拖慢速度甚至因语法错误崩溃。
-
run.skip-dirs支持 glob（如**/gen_*.go），但注意：路径是相对于配置文件所在目录的相对路径 - 若项目有多个模块（
go.work），每个子模块的.golangci.yml都需单独配置，父级配置不会自动继承 - 排除
testdata/时，建议同时加run.skip-files: ["**/testdata/**"]，因为部分 linter（如govet）会主动读取该目录
启用严格模式：让 golangci-lint 报错而非仅警告
默认运行是“报告所有问题”，但 exit code 仍是 0 —— 这会让 CI 误以为检查通过。真正严格，得靠 issues.exit-code 和 linters-settings 双控制。
- 设
issues.exit-code: 1：只要有任何 issue（哪怕只是stylecheck的命名建议），命令就返回非 0 - 对关键 linter 单独收紧，例如
linters-settings.errcheck.check-exported: true，避免漏检未处理的 error 返回值 - 禁用宽松 linter：显式关掉
golint（已废弃）、deadcode（在 module mode 下不可靠），防止干扰信号
示例片段：
立即学习“go语言免费学习笔记（深入）”；
issues:
exit-code: 1
max-issues-per-linter: 0
max-same-issues: 0
linters-settings:
errcheck:
check-exported: true
govet:
check-shadowing: true
golangci-lint run 本地调试时如何快速验证配置是否生效
别直接跑完整检查——太慢。用 --debug + --no-config 组合定位问题最准。
-
golangci-lint run --debug会输出实际加载的配置路径、启用的 linter 列表、跳过的目录列表，一眼看出skip-dirs是否被识别 -
golangci-lint run --no-config -E unused强制只跑unused，再配合--print-issued-lines看具体哪行被标出，验证 exclude-rules 的正则是否匹配正确 - 如果某条 exclude-rule 没生效，大概率是 pattern 写成了
"func.*TODO"（缺少锚点），应改为"^func.*TODO$"或用source: "TODO"更可靠
CI 中集成时容易忽略的兼容性陷阱
GitHub Actions / GitLab CI 默认用最小镜像（如 golang:1.21-alpine），而 golangci-lint 二进制可能依赖 glibc 或特定 Go 版本的 go/types API。
- 务必用官方推荐的安装方式：
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.54.2，别用apk add装旧版 - 若项目用 Go 1.22+ 的泛型特性（如
type T ~int），确保golangci-lint≥ v1.53.2，否则gosimple会 panic - 在
go.work多模块项目中，golangci-lint默认只检查当前目录下的模块，需加--modules-download-mode=readonly避免意外拉取依赖
复杂点在于：排除规则和严格模式不是开关式配置，而是分层作用域叠加的结果。一个 exclude-rules 生效与否，取决于它在配置中的位置、linter 是否支持该字段、以及 Go 源码解析阶段是否已报错退出 —— 所以调试永远从 --debug 开始，而不是猜。
