首页/开发/代码质量与评审速查/gofmt:Go 官方格式化
规范与静态检查65 条

gofmt:Go 官方格式化

Go 自带格式化器:tab 缩进、无风格选项,gofmt -l 列出未格式化文件、gofmt -w 就地修改;goimports 额外管理 import 增删与分组。

gofmt 是什么

gofmt 是 Go 自带的格式化器:使用制表符缩进,不提供风格选项,因此团队之间没有可争的余地。它列出未格式化文件、就地写回或只显示差异都可以;配套的 goimports 在格式化之外还会增删与分组导入语句,是 Go 项目里最常见的组合。

基本信息

定位官方格式化工具,无风格配置项
常用参数列出未格式化文件、就地写回、只显示差异
配套工具goimports 额外整理导入语句的增删与分组
CI 用法检查是否仍有未格式化文件,有输出即视为失败

用法

用法
gofmt -l .        # 列出未格式化的文件
gofmt -w .        # 就地格式化
gofmt -d .        # 只显示差异,不改文件
goimports -w .    # 额外整理 import 的增删与分组

落地要点

  • 编辑器保存时自动格式化:格式问题不进评审视野。
  • CI 执行检查:有未格式化文件就让流水线失败,并提示执行格式化命令。
  • 新项目从第一天就启用:历史代码没有格式债,成本最低。
  • 导入管理统一交给 goimports 或等价工具,不手工调整分组。
  • 批量格式化单独提交:把格式改动与逻辑改动分开,评审者才看得清。
  • 预提交钩子里加一条检查:本地就能拦住未格式化文件,不必等流水线。

常见做法与效果

做法效果
编辑器自动格式化格式改动不进入评审,diff 干净
CI 检查未格式化文件阻止格式不一致的代码合入
手工整理导入分组容易反复改动,产生无意义 diff
先格式化再改逻辑两步混在一个提交,评审噪声大
Go 社区共识:格式没有讨论空间,CI 跑一遍检查即可保持全库一致。
大规模格式化后建议单独提交:把格式改动与逻辑改动分开,评审者才能看清真正的修改。
生成的代码可以排除在检查之外:把生成目录单独处理,避免每次重新生成都产生格式报错。

易错点

  • CI 不做格式检查:未格式化代码混入,后续 diff 噪声持续增加。
  • 手改导入分组:一条命令即可规范化,手工调整反而制造冲突。
  • 格式化与逻辑改动混在一个提交:真实改动被淹没,回滚也不干净。
  • 只依赖某个编辑器的自动格式化:换环境后代码风格重新漂移。

数据来源与参考

  • Go 官方文档(go.dev · gofmt)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌