Go 编译器按源文件名的字典序（lexical order）依次处理同一包内的 .go 文件，其 init 函数也严格遵循该顺序执行；该行为由 Go 工具链保证，可视为稳定约定。
go 编译器按源文件名的字典序（lexical order）依次处理同一包内的 `.go` 文件，其 `init` 函数也严格遵循该顺序执行；该行为由 go 工具链保证，可视为稳定约定。
在 Go 程序中，init 函数用于包级初始化，每个源文件可定义零个或多个 init() 函数，它们会在 main() 执行前自动调用。当一个包由多个 .go 文件组成时（如 a.go、b.go、c.go），init 函数的执行顺序不取决于代码位置或导入关系，而取决于编译器接收文件的顺序。
根据 Go 语言规范，构建系统“应（are encouraged to）以字典序呈现同一包的多个文件给编译器”。而 go build（及所有官方 Go 工具链命令）严格遵守这一约定：它会自动对包内 .go 文件按文件名进行字典序排序，再依次编译和初始化。
以你的示例为例：
main/ ├── a.go ├── b.go └── c.go
由于 "a.go"
a b c
✅ 你可通过以下方式验证该行为：
# 显式指定文件顺序（等价于 go build 的默认行为） go run a.go b.go c.go # 输出：a → b → c # 反序指定（绕过默认排序，仅用于演示原理） go run c.go b.go a.go # 输出：c → b → a（⚠️ 非推荐做法，破坏可维护性）
⚠️ 注意事项：
- 不要依赖 init 的跨文件调用顺序实现关键逻辑（如依赖注入、全局状态初始化链）。若存在强依赖，应显式封装为函数并手动调用（例如 initA() → initB()）。
- 文件名应具有语义一致性（如 config_init.go、db_init.go），避免使用 z_setup.go 等误导性命名导致意外的初始化时序。
- init 函数不可被直接调用、不能带参数或返回值，且每个文件中可定义多个 init 函数——它们在本文件内按出现顺序执行，再与其他文件按文件名序整体串联。
总结：Go 中同一包内 init 的执行顺序是确定且可预测的：即源文件名的字典升序。这是 Go 工具链的稳定行为，而非未定义实现细节，可安全用于组织轻量级初始化逻辑（如注册、常量预热），但仍建议优先采用显式初始化模式以提升代码清晰度与可测试性。
