Go 规范要求构建系统按词法文件名顺序向编译器提供同一包内的多个源文件，以保证 init() 函数调用顺序确定且可重现，从而避免因文件处理顺序不确定导致的初始化行为差异。
go 规范要求构建系统按词法文件名顺序向编译器提供同一包内的多个源文件，以保证 `init()` 函数调用顺序确定且可重现，从而避免因文件处理顺序不确定导致的初始化行为差异。
在 Go 程序中，每个源文件可定义零个或多个 func init() 函数，它们会在 main 函数执行前、按特定顺序自动调用。当一个包由多个 .go 文件组成时，Go 不规定这些文件的“逻辑依赖关系”，而是依赖词法文件名顺序（lexical file name order） 来统一确定 init() 的执行次序——这是构建可重现、可预测初始化行为的核心机制。
什么是词法文件名顺序？
词法顺序（Lexicographical Order）本质上是字符串的字典序比较：逐字符依据其 Unicode 码点（即 UTF-8 编码下的字节值）进行比较，而非按数字大小或语义理解。例如：
a.go → 首字符 'a' (U+0061) ab.go → 前两个字符 'a','b' → 与 a.go 比较：a.go 较短，但前缀相同，故 a.go < ab.go z.go → 'z' (U+007A) > 'a'，因此排在后面 01_init.go → '0' (U+0030) < 'a'，因此排在所有以字母开头的文件之前 config.go → 'c' < 'z'
常见排序结果（从小到大）：
0_constants.go 1_utils.go api.go main.go z_test.go
⚠️ 注意：
- 10_main.go 会排在 2_main.go 之前（因为 '1'
- 大小写敏感：Z.go（U+005A）排在 a.go（U+0061）之前，因大写字母 ASCII 码小于小写；
- Unicode 安全：支持中文、emoji 等（如 配置.go 会按其 UTF-8 字节序列参与比较），但为可移植性，建议坚持 ASCII 命名。
为什么它重要？——影响 init() 执行顺序
Go 规范明确指出：同一包内，init() 函数的执行顺序 = 源文件被编译器接收的顺序 = 词法文件名升序。例如：
// a.go
package main
import "fmt"
func init() { fmt.Println("init A") }// b.go
package main
import "fmt"
func init() { fmt.Println("init B") }若文件名为 b.go 和 a.go，则实际加载顺序为 a.go → b.go，输出：
init A init B
但若重命名为 z_a.go 和 a_b.go，顺序将反转——可见，不显式控制文件名，就等于放弃对初始化顺序的控制。
最佳实践与建议
- ✅ 显式编号命名：对存在隐式依赖的 init()（如注册全局配置、初始化单例、设置日志钩子等），使用前缀如 01_config.go、02_db.go、03_routes.go，确保顺序稳定；
- ✅ 避免跨文件 init 依赖：理想情况下，init() 应无副作用或相互依赖；若必须依赖，请通过函数调用显式表达（如 db.Init()），而非依赖执行顺序；
- ✅ 验证顺序：可通过 go list -f '{{.GoFiles}}' . 查看 Go 工具链实际识别的文件列表（已按词法排序）；
- ❌ 勿依赖构建工具自定义排序：go build 默认遵守该约定；若使用 Bazel、Buck 等需确认其是否严格按文件名排序传递给 gc。
总之，词法文件名顺序不是 Go 的“魔法”，而是一项简单、确定、可验证的工程约定——它用最小的机制代价，换取了大型项目中包初始化行为的完全可重现性。理解并善用它，是编写健壮 Go 库与服务的重要一环。
