Golang 初始化函数 init() 的执行顺序是什么？

说到 Go 语言的 init() 函数，很多开发者都在这上面栽过跟头——不是执行顺序没搞对，就是莫名其妙 panic。其实顺序本身并不复杂，关键是把底层的规则吃透。

先抛出核心结论：init() 的执行顺序不是靠代码位置或 import 顺序决定的，而是由编译器静态分析包依赖图 + 文件名排序共同确定的；跨包按拓扑序，同包按文件名字典序，同一文件内按源码从上到下顺序。

同一包多个 .go 文件的 init 执行顺序

Go 编译器会对同一个包下的所有 .go 文件，按文件名的 Unicode 字典序进行排序，然后依次传入。这意味着，a.go、b.go、c.go 这三个文件的 init 顺序就是严格按照这个顺序来的——a.go 先跑，接着 b.go，最后 c.go。

有几个细节值得注意：

• 这个顺序跟你在 go build 命令里怎么写参数没有关系，除非你显式列出文件名（比如 go build c.go a.go b.go）。否则最终的决定权在构建工具传递给编译器的顺序手里。
• 不同操作系统对文件系统大小写的敏感性差异（macOS 和 Linux 就不太一样）理论上会影响字典序。不过好消息是，go 命令内部统一用 strings.Compare，实际行为是稳定的，不用太担心跨平台带来的诡异问题。
• 一个很常见的翻车现场：在 a.go 的 init 中直接使用 b.go 定义的全局变量 dbConn。由于 b.go 字典序靠后，此时 dbConn 还是零值，一调用 Ping() 就 panic 了。

那怎么解决？一个粗暴但管用的办法是用数字前缀强制排序，比如 01_config.go、02_db.go。不过更推荐的做法是：把强依赖的逻辑合并进一个文件，或者改用显式函数（比如 SetupDB()），然后在 main 中按需调用——这样主动权就在你手里了。

同一文件内多个 init 函数的执行顺序

一个 .go 文件里可以定义多个 func init()，它们会按照源码中间出现的文本顺序从上到下依次执行。注意，这个顺序跟函数名或声明位置无关，纯靠代码的物理排列。

• 这几个 init 互相不能调用——语法层面就报错了。
• 容易踩的坑：人眼扫代码时，总觉得“写在后面的就后执行”，结果后面的 init 偏偏先跑了，而它用了前面 init 才赋值的包级变量，自然就出问题了。
• 变量初始化表达式（比如 var port = os.Getenv("PORT")）是在该文件所有 init 之前执行的。但要注意，如果这个初始化表达式调用了别的包的函数，仍然可能因为依赖未就绪而 panic。

说实话，不推荐靠多个 init 来拆分逻辑——可读性差，调试起来也头疼。如果真需要分步初始化，用普通函数加显式调用要可控得多。

跨包 init 的执行顺序怎么判断

编译器会按照导入依赖图的拓扑序来执行：被依赖包的 init 一定在依赖它的包之前完成。举个例子，如果 pkg/httpserver 导入了 pkg/config，那么 pkg/config.init 一定先于 pkg/httpserver.init 执行。

这里有几个关键点：

• import _ "net/http/pprof" 这种“空白导入”会触发 net/http/pprof 的 init，而且这个触发发生在当前包所有变量声明和 init 之前。
• 间接依赖（A→B→C）不会自动触发 C 的 init，除非 C 被 A 或 B 显式 import 了。
• 循环 import（哪怕只是 import _）会导致编译失败，根本到不了 init 阶段。
• 又一个常见陷阱：在 httpserver.init 里直接用了 config.Port，但 config 包只是被 import _ 触发，且没被其他符号引用。在 Go 1.20+ 版本中，编译器可能直接丢弃这个包，导致 config.Port 的值是 0。

init 里访问跨包变量为什么容易 panic

说穿了，跨包变量初始化没有语言级的保障。你写了一句 var Port = os.Getenv("PORT")，看似简单直接，但它依赖 os 包已经就绪。而 os 自身的 init 是否已完成，取决于它是否被当前的初始化链“需要”——这个链条只要有一环断裂，问题就来了。

典型的现象是：panic: runtime error: invalid memory address or nil pointer dereference，堆栈指向日志打印或数据库连接语句，但你翻到根源才发现，是上游配置包的 init 没执行，导致 log.Logger 或 sql.DB 还是 nil。

所以，别在 init 中调用其他包的导出函数（比如 log.SetOutput），除非你百分之百确认它不依赖未初始化的内部状态。如果想验证实际的执行顺序，可以用 go tool compile -S main.go | grep INIT 查看编译器生成的初始化调用序列。

最后提醒一句：测试中也要留意——每个包的 init 在整个 go test 过程中只执行一次。但如果开了并行测试（-p=4），就可能暴露竞态问题，尤其是在 init 修改了环境变量或全局状态的时候。

真正危险的不是顺序本身不可控，而是人误以为“写了就等于能用”。init 阶段没有同步机制、无法 recover、不能阻塞，一旦依赖断裂就是硬失败。所以最稳妥的做法永远只有一个：把初始化逻辑收进显式函数，由 main 来控制调用时机。