Go的init函数执行顺序严格遵循：跨包按依赖拓扑序、同包按文件名字典序、同一文件内按源码自上而下顺序；该顺序由编译器静态分析确定，非import语句或书写位置决定。
Go 的 init 函数不是“main 前统一执行一遍”，而是按包依赖和文件顺序严格触发的副作用入口——用错就 panic，靠猜就翻车。
同一包内多个 init 的执行顺序怎么定
它不看 import 顺序，也不看代码书写位置，只认两件事：文件名、声明顺序。
- 先按文件名字典序加载（
01_config.go一定比db.go先跑） - 同一文件里，
init函数从上到下依次执行（第一个写的先跑） - 别指望靠写十个
init来拆分逻辑——一旦 A 文件的init用了 B 文件定义的变量，而 B 文件名排在 A 后面，nilpanic 立刻出现
跨包 init 为什么有时快有时慢
根本原因是 Go 只保证“被依赖包的 init 一定先于依赖它的包”，但对同级依赖（比如 main 同时 import db 和 cache，二者都 import log）不做顺序承诺。
-
log.init()总是最早，因为它是共同依赖 -
db.init()和cache.init()谁先谁后，每次go build都可能不同 - 如果你在
db.init()里注册了全局钩子，又在cache.init()里覆盖它，结果不可控 - 测试时更危险：
go test会为每个*_test.go单独初始化包，init可能重复执行多次
init 里调用其他包函数为什么常 panic
因为 init 触发时机只取决于“是否被导入”，不等于“那个包已完全初始化完毕”。
立即学习“go语言免费学习笔记（深入）”；
- 你在
a.go的init里调用config.Load()，但config包的init还没跑，config.URL还是空字符串 - 变量初始化总在同文件所有
init之前，但跨文件时只按文件名排序——02_db.go里的var db = newDB(config.URL)很可能早于01_config.go里的var config = loadConfig() - 空白导入
import _ "net/http/pprof"会立刻触发其init，哪怕你根本没起 HTTP server
为什么 init 里不能 defer 或 recover
这不是语法限制，而是运行时设计：它发生在程序启动最底层阶段，栈还没建好，panic 无法捕获，defer 根本没机会注册。
-
init中打开数据库连接失败？直接 abort，不打印完整堆栈，只留一句panic: dial tcp ...: connect: connection refused -
init里起 goroutine？它可能在main开始前就被调度，但此时 runtime 还没准备好，行为未定义 - 交叉编译时，条件编译的
init（如//go:build linux）不会执行，但相关变量仍声明为零值，容易误判为“配置缺失”而非“平台不匹配”
真正难的从来不是记住规则，而是判断某个 init 是否必须存在——多数时候，把它改成显式调用的 Setup() 函数，反而更可控、可测、可 debug。
