golangci-lint 不提供全自动推导式配置生成，但支持通过 golangci-lint --new-config > .golangci.yml 一键输出带注释的初始 YAML 模板，包含 run 参数、默认启用的 10+ 主流 linter（如 govet、errcheck、staticcheck）及 skip-dirs 示例，需人工删减冗余项并补充 linters-settings 等定制内容。
golangci-lint 不提供「全自动推导式」配置生成，但支持基于项目结构和常用实践，一键输出可编辑的初始 YAML 模板——这是最接近“自动生成”的可靠方式。
用 golangci-lint --new-config 生成基础模板
这是官方唯一内置的配置生成机制，不依赖外部脚本或 AI 推断，直接输出一个带注释、已启用主流 linter 的 .golangci.yml 骨架：
golangci-lint --new-config > .golangci.yml
它会包含：run 基础参数（timeout、concurrency）、默认启用的 10+ 个 linter（如 govet、errcheck、staticcheck）、以及常见 skip-dirs 示例。生成后需手动删减或调整，因为默认启用项可能过全（比如 dupl 或 lll 在多数项目里并不必要）。
- 该命令不读取现有代码，也不分析 import/错误处理模式，纯模板输出
- 生成的配置中
linters-settings为空，所有 linter 都用默认阈值，需按需补充（例如gocyclo: min-complexity: 15） - 若项目已存在
go.mod，生成的配置默认适配模块路径；但不会自动识别testdata或internal目录，仍需人工加到skip-dirs
为什么不用 golangci-lint run --fix 反推配置？
--fix 是修复已有问题的开关，不是配置发现工具。它只对支持自动修复的 linter（如 gofmt、goimports、部分 revive 规则）起作用，且：
立即学习“go语言免费学习笔记（深入）”；
- 运行前必须已有配置文件，否则报错
no config found - 即使配置为空，
run默认启用约 20 个 linter，但哪些真正触发--fix完全取决于代码内容，无法反向映射出“该开哪些” - 它不告诉你某个 warning 是由哪个 linter 产生的，更不会生成
linters-settings中的参数值
真实项目中快速收敛配置的实操路径
别从零写 YAML，也别指望工具猜你想要什么。推荐三步收口：
- 先跑一次
golangci-lint --new-config > .golangci.yml，再删掉明确不用的 linter（如goconst、deadcode），保留govet、errcheck、staticcheck、gosimple、unused - 执行
golangci-lint run --out-format=github-actions，看 CI 或本地终端里实际报了哪些问题，对应去查是哪个 linter 发的（输出里带 linter 名），再决定是否禁用或调参 - 对高频误报项，用
exclude-rules精确过滤，而不是关整个 linter。例如：- linters: [govet] text: "fieldalignment" source: "struct.*has size.*but zero"
最易被忽略的是：生成的模板里 modules-download-mode: readonly 在 CI 中很关键，但本地开发时若依赖未缓存，会导致 run 卡住或失败——这个细节不会在 --new-config 输出里加注释，得自己补上判断逻辑。
