Go 规范要求构建系统按“词法文件名顺序”向编译器提供同一包内的多个源文件，以保证 init() 函数执行顺序确定且可重现，从而避免因文件处理顺序不确定导致的初始化行为差异。
go 规范要求构建系统按“词法文件名顺序”向编译器提供同一包内的多个源文件，以保证 `init()` 函数执行顺序确定且可重现，从而避免因文件处理顺序不确定导致的初始化行为差异。
在 Go 程序中，当一个包由多个 .go 文件组成时，每个文件可能定义自己的 func init()。这些 init() 函数会在 main() 执行前被自动调用，且同一包内多个 init() 的调用顺序是确定的——但该顺序并非由代码位置或依赖关系决定，而是由 Go 构建工具（如 go build）传递给编译器的源文件顺序所决定。
为确保这种顺序跨环境、跨构建始终一致，Go 规范明确要求：构建系统应将属于同一包的多个源文件，按“词法文件名顺序”（lexical file name order）提交给编译器。
什么是词法文件名顺序？
词法顺序（Lexicographical Order）本质上是字符串的字典序比较，即逐字符依据其 Unicode 码点（对 ASCII 字符等价于 ASCII 码值）进行比较。它不依赖文件系统实际存储顺序、创建时间或读取顺序，而纯粹基于文件名字符串本身。
例如，以下文件名按词法顺序排列为：
a.go ab.go b.go z.go z1.go za.go
注意关键细节：
- '0'（U+0030）到 '9'（U+0039）的码点小于 'a'（U+0061），因此 z1.go 会排在 za.go 之前；
- 连字符 -（U+002D）、下划线 _（U+005F）等符号也参与比较：config.go
- 大小写敏感：A.go（U+0041）排在 a.go（U+0061）之前。
✅ 正确示例（推荐命名习惯）：
constants.go # 先定义常量 types.go # 再定义类型 utils.go # 工具函数 main.go # 主逻辑（含 init）
❌ 潜在风险命名（易引发意外顺序）：
v2_service.go # 可能早于 v1_service.go？不，实际是：v1_ < v2_ ✅ # 但若混用符号：service_v1.go vs service-v1.go → '-' (U+002D) < '_' (U+005F)，所以 service-v1.go < service_v1.go
为什么这很重要？——init() 顺序的确定性
Go 不允许包级变量跨文件依赖未初始化的变量，但 init() 函数之间可能存在隐式依赖。例如：
// config.go
package main
var Config = struct{ Port int }{}
func init() {
Config.Port = 8080
}// server.go
package main
import "log"
func init() {
log.Printf("Starting server on port %d", Config.Port) // 依赖 config.go 中的 init()
}若 server.go 被先处理（即其 init() 先执行），则 Config.Port 尚未赋值（仍为 0），输出将不符合预期。而按词法顺序确保 config.go
⚠️ 注意：Go 不保证不同包之间 init() 的执行顺序（仅保证单个包内按文件词法序），跨包依赖应通过显式函数调用或 sync.Once 等机制控制，而非依赖初始化时序。
实践建议
- 显式编号命名：对存在初始化依赖的多文件包，采用 01_*.go、02_*.go 等前缀，既符合词法序，又具备自文档性；
- 避免特殊符号歧义：优先使用字母、数字和下划线；谨慎使用 -、.（除扩展名外）、空格等可能影响排序或兼容性的字符；
- 验证当前顺序：可通过 go list -f '{{.GoFiles}}' . 查看构建系统实际识别的文件列表（已按词法序排列）；
- 勿依赖未声明的顺序：即使测试中看似稳定，也应将关键初始化逻辑封装为显式 Setup() 函数并由 main() 显式调用，提升可维护性与可测试性。
词法文件名顺序不是 Go 的实现细节，而是规范强制约定——它用最简单（字符串比较）、最稳定（与平台/FS无关）、最可预测的方式，为包级初始化这一底层机制提供了坚实基础。理解并善用它，是编写健壮、可重现 Go 程序的重要一环。
