gofmt -w . 是强制统一go代码风格的唯一有效方式，必须在含go.mod的模块根目录执行，不可配置、不接受协商，ci中用gofmt -d .校验差异并失败。
团队用 gofmt 强制统一 Go 代码风格，不是“要不要做”的问题，而是“怎么确保它不被绕过、不被误用、不被当成可选项”的工程落地问题。它必须是 CI 的硬门槛、本地开发的默认动作、新人上手的第一条命令。
gofmt -w . 是唯一有效的执行方式
日常开发中，gofmt -w 不是“可选格式化工具”，而是代码提交前的强制守门员。它不可配置、不接受协商——缩进必须是 tab、运算符前后必须空格、import 分组顺序固定、函数括号不能换行。你改不了，也不该改。
- 必须在含
go.mod的模块根目录执行gofmt -w .：递归处理所有子目录下的.go文件；写成gofmt -w *.go会漏掉深层文件 - 别加末尾斜杠：
gofmt -w ./在某些 shell 下触发路径解析异常，直接报错或静默失败 - CI 中禁用写入，改用
gofmt -d .：只输出 diff，有差异就让构建失败，不给“先 merge 再 fix”的机会 - 本地误操作后重置？
git checkout -- .再跑gofmt -w .，别手动调空格——那只会引入新不一致
go fmt 和 gofmt 不是两个工具，而是一个流程的两种入口
go fmt 是 gofmt -w 的封装，但关键区别在于作用域：它按 Go 包模型工作，自动识别当前目录是否为包、是否含 go.mod，再递归处理所有源文件。而裸用 gofmt 需要你显式指定路径，稍有不慎就漏文件或错目录。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 日常开发推荐用
go fmt ./...（注意...）：它会遍历当前模块下所有包，比gofmt -w .更贴近 Go 工作区语义 - 不要混用
go fmt和gofmt在同一项目里：前者可能跳过 vendor 或 testdata 目录，后者若路径不对会静默忽略子目录，导致格式化结果不一致 - 编辑器集成必须设
"go.formatTool": "gofmt"而非"go.formatTool": "go"：VS Code 等工具里go指的是go fmt，但它的行为受 GOPATH/GOROOT 影响更大，容易在多模块项目中误判作用域
gofmt 无法覆盖的空白，必须靠 golangci-lint 补齐
gofmt 只管“怎么排版”，不管“写得对不对”。命名是否导出、import 是否空白导入、error 是否被忽略、变量是否未使用……这些都得靠静态检查工具兜底。而 golangci-lint 是当前事实标准入口，不是“加分项”，是检查链的起点。
- 别单独装
revive或errcheck：它们默认关闭全部规则，装完不配.revive.toml就等于没装；golangci-lint把它们全收编，一条命令跑完 - CI 中必须启用
--fast且设run.timeout: 5m：避免因大项目卡住构建；同时禁用typecheck类耗时检查，留给go build做 - 最小可用配置里至少开这两条：
[rule.exported]（防小写导出名）、[rule.blank-imports]（防import _ "net/http/pprof"没注释），severity 全设"error"，否则 CI 不拦
新人最容易栽在“以为格式化=做完”这件事上
看到 gofmt -w . 成功返回，就以为代码风格已达标，这是最危险的错觉。gofmt 不检查命名是否符合包级语义（比如 utils 包里出现 HTTPClient 这种带上下文的类型名）、不验证注释是否匹配 godoc 规范、不阻止你在 internal 包里导出符号。这些必须靠人盯 + golangci-lint 配置 + PR 模板里的 checklist 来守住。
真正卡住团队风格落地的，从来不是工具不会用，而是没人明确告诉新人：“你改的这行，为什么必须这么缩进、为什么这个变量要叫 userCount 而不是 uc、为什么这个 error 不 check 就不能合。” 工具只是把规则固化下来，人得把理由说清楚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
