gofmt -w 是日常唯一必须掌握的命令，它强制按go官方硬编码规则格式化代码且不可配置；需在含go.mod的模块根目录执行gofmt -w .递归处理所有.go文件，ci校验用gofmt -d .预览差异。
gofmt -w 是唯一必须跑通的命令
不配置、不选风格、不商量——gofmt 就是 Go 代码格式的最终仲裁者。它硬编码了所有规则：缩进用 tab、运算符前后必须空格、函数括号不换行、import 分组顺序固定……你改不了，也不该改。
日常唯一要记住的是 gofmt -w .：进入含 go.mod 的模块根目录执行，它会递归处理所有 .go 文件。别写 gofmt -w *.go，那只会漏掉子目录；也别写 gofmt -w ./（末尾斜杠在某些 shell 下触发路径解析异常）。
- CI 中校验用
gofmt -d .：只输出 diff，不写文件，有差异就失败 - 本地误操作后想重置？直接
git checkout -- .再gofmt -w .，别手动调空格 - 报错
no Go files in？先ls go.mod确认是否在模块根目录，再which gofmt看路径是不是$GOROOT/bin/gofmt
revive 替代 golint，但规则必须显式启用
golint 已归档，revive 是当前事实标准。但它默认不开任何检查项——装完不配 .revive.toml，等于没装。
常见踩坑点是以为“装了就自动查”，结果 revive ./ 什么也不报。必须指定配置文件，且规则名要拼对：
-
[rule.exported]控制首字母大写的导出符号命名，不是exported-name -
[rule.blank-imports]检查import _ "net/http/pprof"类导入，不是blank_import - severity 设为
"error"才会让 CI 失败；设"warning"仅提示，CI 不拦
示例最小可用配置：
[rule.exported] severity = "error" [rule.blank-imports] severity = "error"
golangci-lint 不是可选项，是检查入口
团队不用 golangci-lint，等于把 go vet、errcheck、revive 全部手动轮着跑。它不是“多一个工具”，而是让所有静态检查收敛到一条命令里。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
关键配置点不在插件列表，而在启用策略：
- 禁用
gofmt检查项？不行。即使你本地开了保存自动格式化，CI 仍需golangci-lint显式跑一遍，否则格式问题会漏过 -
enable-all: true很危险：会启用大量低价值或冲突规则（比如同时开revive和gosimple对同一问题重复报错） - 真正该做的是在
.golangci.yml里明确列出需要的 linter：- revive、- errcheck、- govet、- staticcheck
运行命令始终是 golangci-lint run，别用 run --fast 跳过某些检查——CI 必须全量覆盖。
VS Code 保存自动格式化失效的三个真实断点
编辑器里按 Ctrl+S 没反应，90% 不是插件坏了，而是底层链路断在以下三处之一：
-
go命令找不到：终端能跑go version，但 VS Code 终端显示command not found——说明它没读取 shell 的$PATH，重启 VS Code 或手动配"go.goroot" - 格式化工具被悄悄覆盖：
"go.formatTool"被设成"goimports"，但你根本没装它，结果静默失败 - 实际走的是
gopls+gofumpt：如果启用了"formatting.gofumpt": true，那么保存时调用的是gofumpt，和 CLI 里gofmt -w .行为不一致，diff 会飘
验证方法永远最简单：关掉 VS Code，终端里直接跑 gofmt -w main.go，看是否生效。如果可以，问题一定出在编辑器配置或 PATH 隔离上。
复杂点在于，gofmt 的不可配置性决定了它不能妥协——要么全队列统一用，要么没人能用。而 lint 规则的粒度控制（比如是否允许空白导入）才是真正需要团队坐下来对齐的细节，不是靠工具自动解决的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
