Go命名规范要求包名全小写无下划线、导出标识符首字母大写、变量函数用驼峰且缩写按导出规则处理、接口名以er结尾或功能明确，违反将导致导入失败、不可见或协作混乱。
包名必须全小写，且不能带下划线
包名出现在 import 语句里，也决定你导出符号的前缀（比如 http.Get），写错就直接导致导入失败或命名冲突。常见翻车点：user_v2、User、util —— 这些要么被 go build 忽略，要么和标准库撞名，IDE 补全也会失效。
记住口诀：「小写单数无下划，目录包名须一致」
-
package user✅（目录也是user/） -
package payment✅ -
package user_repo❌（含下划线） -
package Util❌（大写 + 泛化）
导出标识符首字母必须大写，私有就小写
Go 没有 public/private 关键字，可见性全靠首字母大小写硬控制。这不是风格问题，是编译器级规则：小写开头的函数、结构体、字段，别的包根本 import 不进来，也不会报错，而是静默不可见。
记住口诀：「大写才导出，小写包内溜」
立即学习“go语言免费学习笔记（深入）”；
-
type User struct{ Name string }✅（外部可实例化、可访问字段） -
func GetUser() *User✅（外部可调用） -
func getUser()❌（别的包调用会报undefined） -
type user struct{ name string }❌（字段全不可导出，JSON 序列化为空对象）
变量/函数/方法用驼峰，特有名词要小心
驼峰是默认，但遇到 DNS、HTTP、ID、URL 这类缩写时容易出错。关键不是“统一大写”或“统一小写”，而是看是否导出 + 是否在词首。
记住口诀：「导出全大写，私有首小写，中间照原样」
-
APIClient✅（导出，API 全大写） -
apiClient✅（私有，首字母小写，API 小写） -
userID✅（私有，ID 小写） -
UserID✅（导出，ID 大写） -
urlString✅（私有，url 小写） -
URLString✅（导出，URL 全大写）
接口名单函数加 er，多函数按功能起名
这不是强制语法，但标准库和主流项目都这么用，IDE 和工具链（如 gopls）也依赖这个约定做补全和提示。写成 Reader，别人一眼懂；写成 DataReader 或 ReadInterface，反而增加认知负担。
记住口诀：「一函数 er 尾，多函数说清事」
-
type Reader interface{ Read([]byte) (int, error) }✅ -
type Writer interface{ Write([]byte) (int, error) }✅ -
type UserService interface{ Get(int) (*User, error); Create(*User) error }✅（不说功能，没人猜得出） -
type IUser interface{ ... }❌（I 前缀是 C# 风格，Go 社区不用）
复杂点在于：这些规则不是孤立生效的。比如 userID 写成 userid，虽能编译，但和 URL、API 风格不一致，团队协作时容易引发字段命名混乱；又比如包名用 v2 后缀，看似区分版本，实则破坏了 Go 的导入路径语义，升级时需手动改所有 import。真正难的不是记口诀，而是每次敲下 type 或 package 时，条件反射式判断“它会不会被别的包用”。
