golangci-lint本身不支持自动修复代码问题，仅gofmt、goimports和revive等少数linter具备有限修复能力，需显式启用并配合--fix参数或IDE集成；errcheck、staticcheck等语义级检查器完全不提供修复功能。

golangci-lint 本身不支持自动修复代码问题——它是个静态分析工具，不是格式化器或重构器。想靠 golangci-lint run --fix 一键修 bug？会报错：unknown flag: --fix。

真正能“自动修复”的，只有极少数 linter（如 gofmt、goimports、revive 的部分规则），且必须显式启用、单独调用，或通过 IDE 集成触发。

下面说清楚哪些能修、怎么修、为什么多数时候修不了。

哪些 linter 支持自动修复？

目前 golangci-lint 集成的 linter 中，**仅以下几类具备有限修复能力**：

立即学习“go语言免费学习笔记（深入）”；

Golangci-lint 2.12.2

Golangci-lint 2.12.2 版本下载，修复 gomodguard_v2 blocked 配置并更新 iface，适合模块依赖规则检查。

下载

• gofmt：修复缩进、括号、空格、import 排序等基础格式问题（需配置 gofmt 在 enable 列表中）
• goimports：自动增删 import 语句（需单独安装并启用，非默认开启）
• revive：部分规则（如 var-naming、indent-error-flow）可修复，但需在 .revive.toml 中设 severity = "error" 并配合 IDE 或命令行参数
• staticcheck 和 errcheck 等主流 linter：**完全不提供修复功能**，只报错

如何启用 gofmt 的自动修复？

这是最常用、最稳妥的修复路径。关键点不是 golangci-lint 自己修，而是让它调用 gofmt -w。

• 确保 .golangci.yml 中启用了 gofmt：

  linters:
    enable:
      - gofmt

• 运行时加 --fix 参数：golangci-lint run --fix
• 注意：--fix 只对明确支持修复的 linter 生效；其他 linter 的告警仍只会显示，不会改代码
• 验证是否生效：改一个明显格式错误（如 import 未排序），执行后检查文件是否被重写

为什么 errcheck、staticcheck 等不修复？

这类 linter 检测的是语义级问题，修复需要上下文理解，机器无法安全决策。例如：

• errcheck 报 unused result of call to ...：是忽略错误？还是该用 if err != nil 处理？还是该用 _ = 显式丢弃？golangci-lint 不知道你的意图
• staticcheck 报 SA1019: xxx is deprecated：替换成哪个新 API？参数怎么变？文档都没写全，工具不敢瞎换
• gosimple 提示 “可以简化为 x == y”：但如果 x 和 y 是自定义类型且重载了 !=，简化反而破坏逻辑

强行自动修复这类问题，大概率引入新 bug —— 所以设计上就禁掉了。

本地开发中更实用的“半自动修复”方案

与其等 golangci-lint 修复，不如把修复动作前置、绑定到编辑器或提交流程：

• VS Code / GoLand 中启用 "editor.formatOnSave": true + "editor.codeActionsOnSave": {"source.fixAll": true}，保存即调用 gofmt + goimports + revive（若配置支持）
• 用 pre-commit hook 自动跑：gofmt -w . && goimports -w . && golangci-lint run --fix，失败则中断提交
• CI 中不要依赖 --fix：它只修格式，不修逻辑；CI 应该严格报错，逼人手动处理语义问题

真正容易被忽略的是：很多团队以为开了 --fix 就万事大吉，结果上线前才发现 errcheck 报的 20 个错误一个没修——因为那些根本不能自动修。