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 中，**仅以下几类具备有限修复能力**：
-
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-commithook 自动跑：gofmt -w . && goimports -w . && golangci-lint run --fix，失败则中断提交 - CI 中不要依赖
--fix：它只修格式，不修逻辑；CI 应该严格报错，逼人手动处理语义问题
真正容易被忽略的是：很多团队以为开了 --fix 就万事大吉，结果上线前才发现 errcheck 报的 20 个错误一个没修——因为那些根本不能自动修。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
