Go init 函数顺序怎样解释多包初始化

Go 的 init 顺序不是“按 main 里 import 的书写位置执行”，也不是简单地把所有文件从上到下扫描一遍。判断多包初始化，先看包依赖，再看包内的变量依赖，最后才看同一包中源文件的呈现顺序。掌握这三层，就能解释大多数启动日志顺序问题。

先看包依赖：被导入包永远先初始化

假设 main 导入 config，而 config 又导入 store，实际边界是 store → config → main。每个包只初始化一次：先完成该包的包级变量，再调用该包的全部 init，返回后才轮到直接导入它的包。

这意味着 main.init 不会抢在依赖包的 init 前执行。多个包共同依赖 store 时，也不会因为出现两条 import 路径而重复执行 store.init。

init 之前，包级变量先按依赖准备好

包级变量不是单纯按出现顺序赋值。规范会分析初始化表达式对本包变量、函数和方法的引用：有依赖的对象要等依赖完成；没有依赖的对象才从声明顺序中选择。所有变量准备好后，才进入 init。

package settings

var raw = loadRaw()       // 先得到原始配置
var normalized = trim(raw) // 该表达式依赖 raw，因此随后初始化

func init() {
	// init 只消费已经准备好的状态，不再隐式改变依赖顺序
	if normalized == "" {
		normalized = "default"
	}
}

这里不要把 loadRaw 的调用塞进另一个不透明函数，再期待编译器理解运行时才产生的依赖。规范分析的是词法引用；通过反射、接口方法或外部状态制造的隐藏依赖，顺序可能不符合直觉。

同一包多个文件：顺序可复现，但别当业务协议

一个包可以在多个文件中声明多个 init。它们会按照源文件呈现给编译器的顺序调用，文件内再按 init 的出现顺序调用。构建系统通常会按词法文件名提供文件，以获得可复现行为，但这仍不适合承载“先注册，再启动”的核心协议。

排查时可把每个 init 暂时归纳成“读取配置、注册处理器、启动后台任务”三类，再检查是否存在跨文件依赖。若注册必须先于启动，应改成一个显式的 Setup() 或 NewService() 调用，让调用者直接看到先后。

用最小输出定位顺序依赖

遇到启动日志顺序异常时，先列出完整 import 图，再逐包检查包级变量，最后才检查文件名和 init 的排列。可以用下面的示例观察“依赖包先于 main 包”的结论；代码中的输出是读者运行后应关注的观察点，不是本文配图的运行证据。

// package dep
func init() {
	// 依赖包初始化先留下一个明确标记
	fmt.Println("dep.init")
}

// package main
func init() {
	// main 包只有在 dep 包完成后才会到达这里
	fmt.Println("main.init")
}

如果真实项目依赖的是日志先后、全局注册表或后台 goroutine，请把这些副作用改成返回错误的显式初始化函数。init 适合轻量、无参数、失败处理简单的包准备，不适合让调用方无法控制的启动编排。

常见问题

多个包导入同一个依赖包，会执行几次 init？

完整程序中同一个包只初始化一次，之后复用已经初始化的包状态。

能否用 init 的文件名顺序控制业务流程？

不建议。即使构建过程通常按词法文件名保持可复现，也应使用显式函数表达必须的先后。

包级变量和 init 谁先执行？

先完成包级变量的初始化，再调用该包的 init 函数；导入包的同样规则会递归应用。

把初始化顺序当作依赖图来读，而不是当作文件列表来猜，排查会稳定很多：包依赖决定大层级，变量依赖决定包内准备阶段，显式函数决定真正需要由业务控制的顺序。