Go init 函数和变量初始化的先后如何确认

排查 Go 包启动行为时，最容易混淆的是“变量初始化”和“init() 执行”其实是两个阶段。包级变量先根据依赖关系完成初始化，当前包的所有变量都准备好后，才按源码中出现的顺序调用 init 函数；被导入的包则先完成自己的初始化。要确认一段代码的实际先后，先按规范推导，再用短日志核对当前构建输入。

先把 Go 初始化拆成两个阶段

程序启动时，导入图决定包之间的先后：依赖包完成后，当前包才开始。进入一个包后，Go 先处理包级变量，再处理该包中的一个或多个 init()。这些初始化动作在一个 goroutine 中顺序完成；init 内部如果主动启动 goroutine，才会引入并发。

因此下面的直觉是不对的：看到文件里先写了 init()，就认为它会先于后面的变量。变量阶段和 init 阶段有明确边界，init() 不能被普通代码调用，多个 init 也只是按照编译器呈现的源码顺序依次运行。

包级变量先看依赖，再看声明位置

规范的判断方法是：每一轮选择“当前还没初始化、且不依赖未初始化变量”的变量；在这些可选变量中，取声明顺序最早者。依赖不仅是表达式里直接写出的变量，也会沿着初始化函数体传递。

package sample

import "fmt"

var base = mark("base")
var total = base + mark("total")

func mark(name string) int {
	// 用短标记观察初始化表达式何时被求值。
	fmt.Println(name)
	return 1
}

func init() {
	// 变量阶段完成后才会看到这个标记。
	fmt.Println("init")
}

这个例子中，total 明确依赖 base，所以即使把声明位置改得更靠前，也不能绕过 base。而同一条多值初始化语句左侧的变量会被视作同一步完成。若初始化表达式形成循环，程序就不是合法的 Go 程序。

多文件场景要确认“编译器看到的顺序”

同一个包可以拆成多个文件。规范把多文件的声明顺序定义为编译器提供文件的顺序，并建议构建系统按字典序提交文件，以获得可复现行为。实际排查时，不要用“编辑器里哪个标签在前”作证据；应该固定构建命令，查看文件列表，再用上面的标记运行一次。

运行标记只回答“这个构建输入实际观察到了什么”，不会替代规范分析。不要在正式初始化代码中长期保留大量打印；排查完成后应移除，或改成测试包中的临时探针。

需要静态清单时读取 go/types.InitOrder

如果只是查一个小包，标记法最快；如果要做工具或批量审查，可以使用标准库 go/types 的类型检查结果。types.Info.InitOrder 会给出包级初始化表达式的顺序，每个元素对应一条初始化表达式及其左侧变量。它适合回答“类型检查器依据当前语法和依赖推导出什么”，不等于运行时日志。

判断结果时可按这张速查表收敛范围：

常见问题

同一个文件里能写多个 init 吗？

可以。它们按源码中出现的顺序调用，但都发生在本包包级变量完成之后。

没有初始化表达式的变量也要考虑吗？

要。它先取得类型对应的零值；在判断整体依赖和同一步初始化时，不能把它当成不存在。

接口方法调用会不会改变变量顺序？

可能出现隐藏依赖。规范的依赖分析只识别当前包中可静态追踪的变量、函数和非接口方法引用，接口动态派发等隐藏数据依赖不应被当成确定顺序。

实际工作中，先画出导入包、包级变量和 init() 的边界，再用一次短标记确认当前构建；只有在做静态工具时，才进一步读取 go/types.InitOrder。这样既能解释输出，也能避免把偶然的文件顺序误当成语言保证。