gofmt 不会重命名变量，只调整格式；goimports 在其基础上处理 import；命名规范需靠 linter（如 revive） enforce，CI 需锁死工具链版本。
gofmt 会重命名变量吗？不会，它只格式化不改语义
很多人误以为 gofmt 会按 Go 规范自动把 myVar 改成 myVar（小写）或 MyVar（大写首字母），其实它完全不碰标识符命名——只调整缩进、空格、换行、括号位置。命名是否符合规范（比如导出名首字母大写、包内私有变量用 snake_case 还是 camelCase）得靠人判断或额外工具。
-
gofmt不修改任何变量名、函数名、类型名，哪怕它们明显违反规范 - 它默认不读取
go.mod，也不感知包作用域，所以无法判断某个名字该不该导出 - 执行
gofmt -w main.go后如果命名出问题，一定是你写的，不是它改的
goimports 替代 gofmt？不是替代，是叠加使用
goimports 本身包含 gofmt 的全部能力，但它额外处理 import 块：自动增删包引用、按字母排序、合并标准库与第三方导入。但注意，它默认**不启用**对未使用 import 的清理（除非加 -local 或配置），也**不会重排已有 import 分组**，除非你明确告诉它规则。
- 直接运行
goimports -w main.go等价于先gofmt再整理 import，但不会自动补全缺失的import语句 - 如果项目用了内部模块路径（如
example.com/internal/util），需加-local example.com才能把这类包归为“本地导入”，和标准库分开排 - VS Code 默认调用
goimports，但 Go 插件若没配"go.formatTool": "goimports"，可能还在用原始gofmt
命名规范真正在哪 enforce？靠 linter，不是格式化工具
Go 官方从不强制命名风格，gofmt 和 goimports 都不检查 userID 应该叫 userID 还是 UserId，甚至不拦着你写 U_S_E_R_I_D。真正能卡命名的，是静态分析工具，比如 revive 或 staticcheck 配合自定义规则。
- 例如用
revive检查首字母大小写一致性：在.revive.toml里开exported规则，它会报错func getuser() → should be GetUser -
golint已被弃用，别再用；staticcheck对命名建议有限，主要看符号可见性 - IDE 自动补全常诱导你用错大小写（比如输入
json提示JSON，但实际该用json包），这属于开发习惯问题，工具管不了
CI 里怎么统一团队格式？别只跑 gofmt，要锁死工具链版本
同一份代码，gofmt 在 Go 1.19 和 Go 1.22 下输出可能不同（比如 switch case 末尾逗号处理）。如果 CI 用最新 Go 版本而本地用旧版，就会出现“我本地格式化过，CI 还报格式错误”的情况。
立即学习“go语言免费学习笔记（深入）”；
- CI 脚本里显式指定 Go 版本，并用
go install golang.org/x/tools/cmd/goimports@v0.14.0锁死goimports版本 - 避免用
go get安装格式化工具——它会覆盖GOBIN下的旧二进制，导致本地行为突变 - 检查是否意外启用了
gofumpt（一个更激进的 fork），它会强制添加函数参数换行、移除冗余括号，和官方规范不完全兼容
格式化工具只是流水线最前面的一环，命名是否合理、import 是否干净、大小写是否一致——这些都不是敲个命令就能解决的，得靠配置、约束和人盯住细节。
