Go的init函数执行顺序由编译器静态分析决定：跨包按依赖拓扑序，同包按文件名Unicode字典序，同一文件内按源码自上而下顺序；该顺序不可手动控制，强依赖应改用显式Init()函数。
Go 的 init 函数不是按源码顺序执行的，而是按包初始化依赖图拓扑排序执行——这意味着你写的顺序不等于运行顺序，依赖关系才是关键。
为什么 init 函数的执行顺序看起来“乱”？
Go 编译器会先构建整个程序的包依赖图：如果包 A 导入包 B，那么 B 必须在 A 之前完成初始化（包括所有 init）。这个过程和文件书写顺序、init 在文件里的位置完全无关。
- 同一包内多个
init函数，按源文件名的字典序执行（不是代码出现顺序） - 跨包时，只看
import关系，哪怕你 import 的只是个空导入（_ "xxx"），也会触发该包初始化 - 循环 import 会导致编译失败，Go 不允许依赖环
怎么验证当前项目的 init 执行顺序？
最直接的办法是加日志并用 go run -gcflags="-l" main.go（关闭内联，避免日志被优化掉），但更可靠的是用 go tool compile -S 查看初始化伪指令，或借助调试器断点。
- 在每个
init里写fmt.Printf("init %s\n", "pkgname")，观察输出顺序 - 注意：标准库包（如
fmt、os）自身也有init，它们会在你的包之前执行，且顺序固定 - 如果用了
go:linkname或 cgo，可能引入隐式依赖，导致意外的初始化提前
哪些常见写法会让 init 行为变得不可控？
真正踩坑的地方往往不是顺序本身，而是把 init 当作“启动脚本”来用，忽略了它无法访问未初始化的全局变量、不能 panic 后恢复、也不支持参数传递。
立即学习“go语言免费学习笔记（深入）”；
- 在
init中调用尚未初始化的其他包的函数（比如依赖另一个包的全局变量，而那个包还没走到自己的init）→ 可能 panic 或零值 - 用
init注册 HTTP handler 但没确认http.ServeMux是否已准备好 → 实际上安全，因为net/http的init已确保 mux 初始化，但自定义 mux 就不一定 - 在多个文件中定义
init并假设它们按文件顶部到底部顺序执行 → 错误；应依赖显式依赖（比如通过函数调用强制顺序）
真正难处理的，是那些隐藏在第三方库 import 路径里的间接依赖——你删掉一行 import，整个 init 链就变了。别靠猜，用 go list -f '{{.Deps}}' your/package 看实际依赖树。
