golangci-lint run --fix 仅转发修复指令给明确支持的底层 linter，真正能修改代码的只有 gofmt（格式化）、goimports（import 管理）和 revive（少数规则），且须显式启用、正确配置并满足依赖条件。
golangci-lint run --fix 能修什么？
它本身不修复，只转发命令给底层 linter。真正能改代码的只有 gofmt、goimports、revive（部分规则）这三类，且必须显式启用并满足条件。运行 golangci-lint run --fix 时，其他 linter（如 errcheck、staticcheck）的报错照常输出，但源文件不会被修改。
-
gofmt：修复缩进、括号、空行、import 排序等纯格式问题；需在.golangci.yml的linters.enable中列出 -
goimports：增删 import、排序、去重；需单独安装（go install golang.org/x/tools/cmd/goimports@latest），并在配置中启用 -
revive：仅限少数规则（如var-naming、indent-error-flow）支持修复；需在.revive.toml中设severity = "error"，且命令行调用时带--fix
为什么 .golangci.yml 里配了 gofmt 还不生效？
常见失效不是因为配置写错，而是执行路径或参数没对齐：
- 必须确保
gofmt在linters.enable列表里，而不是只写在linters-settings或注释中 -
golangci-lint run --fix必须显式加--fix参数；不加就只是检查，不写入文件 - 如果项目用了
gofumpt或golines等替代格式化器，gofmt启用也无效——它们互斥，得换配置项 - 执行时工作目录不在项目根（即
.golangci.yml所在处），工具会退回到默认配置，忽略你的enable列表
golangci-lint fmt 命令和 run --fix 有什么区别？
这是 v2.0+ 引入的明确分工：fmt 是纯格式化入口，run 是静态检查入口。两者不共享配置段，也不能混用参数。
-
golangci-lint fmt：只调用格式化器（gofmt、goimports等），无视所有linters和issues配置；它的配置在format段下，例如format: gofmt -
golangci-lint run --fix：只触发已启用且支持修复的 linter，且仅当该 linter 被run命令实际调用时才生效；gofmt在这里属于“检查器”，不是“格式化器” - 想统一做格式化？直接用
golangci-lint fmt ./更可靠；想边查 bug 边修格式？用run --fix，但得接受它只修 subset
CI 或 File Watchers 里自动修复失败的典型原因
不是工具不行，而是环境链路断了一环：
立即学习“go语言免费学习笔记（深入）”；
- GoLand 的 File Watchers 中，
Working directory没设成$ProjectFileDir$→ 加载不到.golangci.yml→gofmt不启用 →--fix无效果 - CI 脚本里写了
golangci-lint run --fix，但没指定配置文件路径 → 工具在临时目录运行，找不到.golangci.yml→ 回退默认 linter 列表（不含gofmt） - CI 容器里没装
goimports，但配置里启用了它 →--fix过程中该 linter 跳过，不报错也不修复，静默失败 - 用
--fast模式跑run --fix→gofmt属于 fast linter，不受影响；但若误配了其他 slow 格式化器（极少见），也会被跳过
真正要盯住的，从来不是“能不能修”，而是“谁在修、在哪修、按什么规则修”。--fix 不是魔法开关，它只把控制权交给具体 linter，而每个 linter 的行为边界、依赖、配置位置都不同。漏掉任一环节，修复就停在半路。
