Go 规范要求构建系统按词法文件名顺序向编译器提供同一包内的多个源文件，以保证 init() 函数执行顺序确定、可重现，从而避免因文件处理顺序不确定导致的初始化行为差异。
go 规范要求构建系统按词法文件名顺序向编译器提供同一包内的多个源文件，以保证 `init()` 函数执行顺序确定、可重现，从而避免因文件处理顺序不确定导致的初始化行为差异。
在 Go 程序中，每个源文件可定义零个或多个 init() 函数，它们会在 main() 执行前自动调用，且按包内文件的处理顺序依次执行。但 Go 并未规定多文件包中 init() 的跨文件调用顺序——除非明确约定。为此，Go 语言规范 §Package initialization 明确指出：
To ensure reproducible initialization behavior, build systems are encouraged to present multiple files belonging to the same package in lexical file name order to a compiler.
这里的 lexical file name order（词法文件名顺序），本质是字符串的字典序（lexicographic order）：即逐字符按 Unicode 码点（code point）大小比较文件名，等价于使用 strings.Compare 或 sort.Strings 的默认排序逻辑。
例如，以下同属 main 包的文件：
a.go config.go main.go z_test.go 01_utils.go 99_constants.go
按词法顺序排列后为：
01_utils.go // '0' (U+0030) < '9' < 'a' < 'c' < 'm' < 'z' 99_constants.go a.go config.go main.go z_test.go
✅ 正确示例：控制初始化依赖
假设需确保配置加载早于服务启动，可利用文件名显式约束顺序：
// 01_config.go
package main
import "fmt"
func init() {
fmt.Println("loading config...")
}// 02_server.go
package main
import "fmt"
func init() {
fmt.Println("starting server...")
}运行 go run *.go（或 go build）时，只要构建工具（如 cmd/go）遵守规范，01_config.go 总先于 02_server.go 被处理，输出恒为：
loading config... starting server...
⚠️ 注意事项：
- 该顺序仅作用于同一包内多个 .go 文件的 init() 执行次序，不适用于跨包依赖（跨包顺序由导入图决定）；
- 文件名含非 ASCII 字符（如中文、emoji）时，严格依据 UTF-8 编码后的字节序列比较，建议在生产项目中坚持使用 ASCII 命名以保可移植性；
- go test 会额外包含 _test.go 文件，其词法顺序同样参与排序（如 a_test.go 会在 b.go 之前）；
- 不要依赖未文档化的实现细节（如 go list -f '{{.GoFiles}}' 输出顺序），始终以文件名本身为唯一可控依据。
? 总结：词法文件名顺序不是 Go 运行时的“魔法”，而是构建系统层面的重要契约。它赋予开发者对 init() 时序的可预测控制力——虽应尽量避免强初始化依赖，但在配置注入、全局注册、资源预热等场景下，合理利用前缀命名（如 00_, 01_, zz_）是一种简洁、标准、无需额外工具的工程实践。
