gofmt 是协作前提，不是可选项：它强制统一代码格式，必须每次提交前运行并集成到CI和IDE中；命名、error处理、注释等规范共同构成降低理解成本的基础设施。
gofmt 是协作前提，不是可选项
多人一起学 Go，最常卡在“为什么我的代码格式和别人不一样”——这不是风格偏好问题，而是协作基础被破坏。gofmt 不是美化工具，它是强制统一的语法解析器：它重写 AST 后输出，连空格、换行、括号位置都由规则决定，不是人工能“调得更好”的。
-
gofmt -w main.go必须在每次提交前运行，CI 流程里加这一行比写文档更有效 - IDE 插件（如 Goland 的 “Save Actions”）设为保存时自动
gofmt，避免有人漏执行 - 别用空格缩进——
gofmt只认 tab；混用空格+tab 会导致 diff 里全是格式噪音，掩盖真实修改
命名不一致会直接阻断理解链
一个叫 getUserName、另一个叫 FetchUser、第三个写成 Getuser，三个人写的函数在同一个包里，调用方根本不敢猜哪个导出、哪个私有、哪个拼错。Go 的导出规则（首字母大写）和命名约定不是为了好看，是为了让 IDE 和 go doc 能准确推导作用域和用途。
- 包名必须小写单数，比如
user，不是users或UserLib；否则import "user"和import "users"会被当成两个包 - 接口名以
er结尾，如Reader、Writer，这是约定俗成的信号：“这个类型是用来被实现的”，不是随便起的 - 错误变量统一用
ErrXXX前缀，比如ErrNotFound，这样if err == user.ErrNotFound一眼可知是业务错误，不是临时变量
error 处理方式不同，会让协作变成“猜谜游戏”
有人写 if err != nil { log.Fatal(err) }，有人写 if err != nil { return err }，还有人直接忽略 _ = os.ReadFile(...)。这些写法在单人练习时都能跑通，但放到协作场景里，前者让整个服务崩掉，后者让上游永远收不到失败信号，调试时得翻三个人的代码才能定位源头。
- 所有返回
error的函数，调用后必须显式检查；go vet能报出未检查的error，但得先启用 - 包装错误用
fmt.Errorf("xxx: %w", err)，不是fmt.Errorf("xxx: %s", err.Error())；前者保留原始堆栈，后者把上下文全丢了 - 测试中要覆盖
err != nil分支，哪怕只是写if err != nil { t.Fatal(err) }，否则 PR 里没人敢信这个路径真跑过
注释不是补充说明，是契约声明
协作学习中最容易被跳过的环节是注释，但 Go 的注释直接影响 go doc 输出和 IDE 提示。如果 // GetUserByID returns user by ID 写在函数上，VS Code 悬停就能看到；如果只在函数体里写 // get user，那对协作者来说等于没写。
立即学习“go语言免费学习笔记（深入）”；
- 每个导出函数/类型前必须有
//开头的文档注释，且第一句是完整句子，不能是短语 - 参数和返回值不用在注释里重复类型（
func Add(a, b int) int类型已明确），但要说清语义，比如 “a 和 b 都应为非负整数” - 别写 “TODO: refactor later” 这类注释——它既不帮助当前读者，也不约束后续人；真要留坑，就用
//nolint:xxx加具体 lint 规则禁用，或提 issue 编号
协作式学习里，规范不是用来打分的 checklist，而是降低“理解成本”的基础设施。少一个人不守 gofmt，就多五个人在 review 时花时间分辨哪行是改了逻辑、哪行只是空格变了；少一条清晰的 error 包装，就多一次线上排查时翻日志到凌晨。
