gofmt是Go项目落地的第一道门槛，必须在保存时自动执行；手动运行易遗漏，CI失败返工成本高，且会导致协作中因空格/换行差异产生无意义diff。
gofmt 不是可选插件，是 Go 项目落地的第一道门槛。没跑过 gofmt -w 的代码，连编译前检查都算不上完成。
为什么 gofmt 必须在保存时自动执行
手动运行容易漏、CI 检查失败再返工成本高，最直接的后果是：多人协作时同一行代码因空格/换行差异触发无意义 diff，Git 记录变脏，Code Review 被干扰。
VS Code 中仅靠 "editor.formatOnSave": true 不够——必须确认 "go.formatTool" 明确设为 "gofmt"（不是 "goimports" 或空值），且 "go.formatFlags" 包含 -s（简化格式，删冗余空行）。
- 不设
-s：函数间可能留两行空行，go fmt ./后仍会报格式不一致 - 用
goimports替代：它会动导入语句，但格式化行为与gofmt不完全等价，团队统一工具链时易出偏差 - 没配
formatOnSave：靠人自觉，三天后就回归手写风格
gofmt -w 和 go fmt -w 有什么区别
本质一样：go fmt 是 gofmt 的封装命令，底层调用相同二进制。但行为细节有差异：
-
gofmt -w *.go：只处理当前目录匹配的 .go 文件，不递归子目录 -
go fmt -w ./...：推荐用法，...表示递归所有子包，适合项目根目录执行 -
go fmt -w ./：只处理当前目录（不含子目录），常被误认为“整个项目”，实际漏包 -
gofmt -l输出未格式化文件路径，go fmt -l同样可用，但 CI 中建议统一用go fmt避免工具链割裂
哪些地方 gofmt 不会帮你修，得自己盯
gofmt 只管布局，不管语义。以下问题它视而不见：
立即学习“go语言免费学习笔记（深入）”；
- 包名含下划线（如
http_client）→ 应改为httpclient - 变量名用
user_name→ 应改为userName - 常量全小写
max_retry→ 应改为MaxRetry（导出）或maxRetry（未导出） - 函数参数命名冗长如
theUserInputString→input或userStr更符合 Go 习惯 - 错误忽略：比如
os.Open(...)后没处理err→ 这得靠go vet或staticcheck
CI 中验证 gofmt 的最小可靠写法
别只跑 go fmt -l 然后判断输出是否为空——某些旧版 Go 工具链在无输出时仍返回非零退出码，导致流水线误判失败。
稳妥做法是显式捕获输出并判断长度：
if [ -n "$(go fmt -l ./...)" ]; then echo "Found unformatted files" exit 1 fi
注意三点：
- 必须用
./...，不是.或./ - 不要加
-w—— CI 只做检查，不改源码 - 别依赖
go fmt返回码做判断，不同 Go 版本行为不一致
gofmt 成为编辑器里按 Ctrl+S 就发生的条件反射。一旦跳过这步，后续所有 lint、review、重构，都在补最初那几行缩进的债。 
