在 Go 语言开发中，选择合适的标识符名称是编程的重要组成部分。好的命名能让代码更清晰、更可预测、更易导航；差的命名则起到相反作用。Go 对命名有相当强的约定和一些硬性规则，理解并遵循这些规范能够显著提升代码质量。
标识符的硬性规则与基本约定
Go 标识符可以包含 Unicode 字母、数字和下划线，但不能以数字开头，也不能使用任何 Go 关键字作为标识符。在这些基本规则之上，存在一套值得遵循的命名约定：未导出的标识符使用驼峰式（camelCase），已导出的标识符使用帕斯卡式（PascalCase），不应使用蛇形命名（snake_case）或全大写形式。
对于 API、URL、HTTP 等缩写词或首字母缩写词，应在标识符内保持一致的大小写形式。例如 apiKey 或 APIKey 都是符合惯例的，但 ApiKey 则不符合。这一规则同样适用于作为 “身份” 或 “标识符” 缩写的 ID，因此应写成 userID 而非 userId。虽然 Go 允许使用 Unicode 字母，但使用非 ASCII 字符往往会使代码更难阅读和编写，除非有非常合适的用例，否则建议坚持使用 ASCII 字母。
另一个重要原则是避免选择与 Go 内置类型冲突的标识符。例如，不应创建名为 int、bool 或 any 的变量，也不应创建与内置函数名冲突的函数如 min、max、len 或 clear。同样，除非有特定需要，否则应避免选择与标准库包名冲突的标识符，如正在使用 url 和 net/mail 包时，不应在同一代码中将 url 和 mail 用作标识符。
导出与未导出标识符的策略
Go 标识符是大小写敏感的。当标识符以大写字母开头时，它会被导出，意味着对包外的代码可见。这意味首字母的大小写是有意义的，它直接影响代码的行为。因此，不应仅仅因为看起来美观就使用大写字母开头，只有在确实需要导出并被包外代码访问时才应这样做。
一个实用的建议是默认使用未导出的标识符，只在真正需要时才导出。导出越少，就越容易在不影響代码库其他部分的情况下重构包内代码。正如《程序员 Pragmatic Programmer》中所说：编写 “害羞” 的代码 —— 不向其他包暴露不必要的实现，也不依赖其他包的内部实现。对于 main 包来说尤其如此，因为 main 包很少会被其他包导入，其中的标识符通常都应该使用小写字母开头。唯一的例外是需要通过反射工作的包（如 encoding/json、encoding/gob 或 github.com/jmoiron/sqlx）来访问导出的结构体字段。
标识符长度与描述性的平衡
一般来说，标识符的使用位置离其声明位置越远，就应当越具有描述性。如果一个标识符作用域很窄且仅在声明附近使用，使用简短且描述性不强的名称是可以接受的。例如，在小的 for 循环、range 块或非常短的函数中，使用短名称甚至单字母名称在 Go 中是非常常见的。
但如果命名对象具有更大的作用域，或在离声明很远的地方使用，就应该使用能够清晰描述所代表内容的名称。例如，在处理人员列表的函数中，range 块内使用单字母 p 来表示列表中的元素是足够的，因为这个范围块非常小且紧凑。但在同一函数中声明的 count 和 sum 变量，它们在 range 块内使用，之后又在 return 语句中再次使用，给它们更具描述性的名称会使代码的意图更加清晰。
这种平衡并非精确的科学，而是需要根据具体场景判断。Go 代码中鼓励使用 “合适长度” 的标识符 —— 有时可能很长且具有描述性，有时可能很短且简洁。
包名设计的实用原则
包名的硬性规则与标识符相同：可以包含 Unicode 字母、数字和下划线，不能以数字开头，不能是 Go 关键字。但在实践中，包名的约定要严格得多。包名应该只包含小写 ASCII 字母和数字，因为包名在编写代码时需要经常输入，名称应该简短、易于输入，并能反映包的内容。通常简单的名词（如 orders、customer、slug）效果很好。
如果想在一个包名中使用多个单词，应该将所有单词小写并连接在一起，不使用分隔符。例如 ordermanager 是一个符合约定的包名，而 orderManager 或 order_manager 则不是。如果包名太长，可以使用缩写，如标准库中的 expvar（代替 exportedvariables）和 strconv（代替 stringconversion）。应避免使用与常用标准库包同名的包名，也应避免使用以 . 或 _ 开头的包名，因为这些包名会被 Go 工具完全忽略。
特别需要注意的是，应避免使用 common、util、helpers、types 或 interfaces 这类 “万能” 包名。这类名称并不能真正说明包的内容，容易导致包变成一个杂物间，被代码库各处引用，增加导入循环的风险，并使更改可能影响整个代码库。
文件命名与避免冗余
理想的 Go 文件名应该总结文件内容，使用一个单词，全部小写。例如标准库 net/http 包中的 cookie.go、server.go 和 status.go 都是很好的例子。如果无法想到一个好的单词名称而需要使用两个或更多单词，Go 标准库本身也没有一致的做法，有时使用下划线分隔（如 routing_index.go），有时则直接连接（如 batchcursor.go）。由于没有强烈的约定，建议选择其中一种方式并在整个代码库中保持一致。
在导出函数命名时，应避免重复包名。例如，如果有一个名为 customer 的包，函数名如 NewCustomer() 或 CustomerOrders() 会显得冗余，在包外调用时变成 customer.NewCustomer() 和 customer.CustomerOrders()。使用 New() 和 Orders() 就足够了，在调用点阅读效果更好。同样的建议也适用于导出的类型，如在 customer 包中，使用 Address 和 PhoneNumber 就比 CustomerAddress 和 CustomerPhoneNumber 更加简洁。
方法接收者与接口命名
方法接收者通常应该使用短名称，一般 1 到 3 个字符，通常是所实现方法的类型的缩写。例如，在 Customer 类型上实现方法，符合习惯的接收者名称可以是 c 或 cus；在 HighScore 类型上，良好的接收者名称可以是 hs。Go 代码审查注释建议不要使用 this、self 或 me 这类通用名称作为接收者。同时应该保持一致性：同一类型上的所有方法应该使用相同的接收者名称，不应在一个方法中使用 c 而在另一个方法中使用 cus。
对于接口，惯例是只包含一个方法的接口应该用方法名加上 “-er” 后缀来命名。例如 io.Reader、io.Writer 和 fmt.Stringer 都遵循这一约定。同样，避免在接口名中包含类型，除非真的想不出更好的替代方案。
实践中的灵活处理
虽然绝大多数情况下应该遵循上述命名规则和约定，但在少数情况下，打破约定实际上可以让代码更清晰。例如，当与外部系统交互时，使用与外部系统完全相同的标识符可以使程序的意图更清晰，更容易看出正在同步什么。然而，这只是例外情况，大部分时间还是应该遵循本文讨论的命名规则和约定，因为它们的存在是有充分理由的：使代码更加一致和可预测，让其他 Gophers 能够快速理解，并降低某些 bug 的风险。
资料来源：Alex Edwards 的博客文章《Go Naming Conventions: A Practical Guide》提供了全面的 Go 命名规范实用指南，涵盖了标识符、包名、文件命名等各个方面。