golangci-lint fmt 仅执行格式化、不运行 linter，需在 linters.enable 中显式启用格式化器（如 gofmt）并配置 linters-settings；它不递归子目录（需写为 mypkg/），且与 run 的路径处理、参数规则、用途严格分离。
golangci-lint 的 fmt 命令专用于格式化，不执行任何静态检查；run 命令只做检查，不改写代码 —— 两者职责分离，不能互相替代。
fmt 命令只调用格式化器，不触发 linter
从 v2.0.0 开始，golangci-lint fmt 是独立入口，它只会运行配置中启用的格式化器（如 gofmt、goimports、gofumpt 等），完全跳过所有 linter（比如 errcheck、staticcheck）。这和旧版靠 --fix 参数“捎带”格式化的做法有本质区别。
- 执行
golangci-lint fmt ./不会报错、不会警告，只做格式重写 - 若想查看当前启用了哪些格式化器，运行
golangci-lint fmt --list - 格式化器是否生效，只看
linters-settings下对应项是否配置，而非linters.enable列表里有没有它 - 常见误操作：在
linters.enable里加了gofmt，但没在linters-settings.gofmt下设任何配置 —— 此时fmt命令仍可用，但run命令不会把它当 linter 执行
格式化器必须显式启用并配置才生效
golangci-lint 不默认启用任何格式化器。即使你写了 gofmt: {} 在 linters-settings 下，也不代表它会被 fmt 命令调用 —— 必须在 linters 配置块中明确声明启用：
- 正确写法（启用
gofmt格式化器）：linters: enable: - gofmt linters-settings: gofmt: # 空配置也行，表示用默认行为 - 错误写法（仅配置但未启用）：
linters-settings: gofmt: {}→golangci-lint fmt运行时会静默跳过gofmt - 多个格式化器可共存，例如同时启用
goimports和gofumpt，它们会按顺序依次处理源码；注意顺序影响最终结果（比如goimports改了 import 后，gofumpt可能再调整空行） -
golines这类长行折行工具，对注释和字符串字面量敏感，开启前建议先小范围试跑，避免意外拆分多行字符串
fmt 与 run 的路径参数行为不一致
两者对目录参数的处理逻辑不同，容易踩坑：
立即学习“go语言免费学习笔记（深入）”；
-
golangci-lint fmt mypkg：只处理mypkg目录下的文件，**不递归子目录**；要递归，必须写成mypkg/（末尾加/） -
golangci-lint run mypkg：默认递归扫描整个包树，包括子目录；但若混用mypkg和foo.go，会直接报错：“cannot mix file and package arguments” -
fmt支持单个文件参数（golangci-lint fmt main.go），而run要求所有文件属于同一 Go 包 —— 如果传入跨包的多个.go文件，run会失败，fmt却可以成功 - CI 脚本里如果沿用旧的
run ./写法去跑fmt，可能漏掉子目录；应统一为fmt ./或fmt ./**/（取决于 shell 是否支持 glob）
本地开发与 CI 中 fmt 的使用边界
格式化不是“越全越好”，实际落地要考虑人机协作效率：
- 编辑器保存时自动运行
golangci-lint fmt是可行的，但建议限制作用域为当前文件（fmt $FILE_PATH），避免保存一个文件就重刷整个模块 - CI 中慎用
--fix（这是run的参数，不是fmt的），因为部分 linter 的自动修复不可逆（比如删掉看似未使用的变量，实则被反射调用）；fmt命令本身无此风险，但需确保团队对格式化器行为有共识 -
gofumpt比gofmt更激进（如强制函数体空行、禁止冗余括号），若项目已存在大量历史代码，首次全量执行可能产生上千行 diff；建议先用golangci-lint fmt --dry-run预览变更 - 生成代码（如
pb.go、swaggo输出）应加入run.skip-files，但fmt命令默认也会跳过它们 —— 因为格式化器内部通常自带跳过逻辑，无需额外配置
真正难的不是配出能跑的命令，而是让所有人理解：格式化是约定，不是魔法；fmt 输出的结果，必须和 run 报告的问题正交 —— 一个文件格式再漂亮，errcheck 该报错还是得报。
