Go 中 init 函数因跨包依赖时序不当（如 A 包 init 访问 B 包未初始化的全局指针）导致空指针 panic；修复关键是将“真工作”移出 init，改用显式初始化函数并由 main 统一调度。
为什么 init 函数的执行顺序会引发空指针？
go 的 init 函数在包初始化阶段按依赖顺序自动执行，但**同一包内多个 init 函数的执行顺序是按源文件字典序（非声明顺序）**。当 a 包的 init 试图访问 b 包尚未初始化完成的全局变量（比如未赋值的 *sync.pool 或未初始化的 http.client），就会触发 nil dereference panic。
大型项目中常见于：配置加载、中间件注册、数据库连接池预热、日志句柄初始化等跨包依赖场景。
典型错误现象：panic: runtime error: invalid memory address or nil pointer dereference，堆栈指向某 init 函数内部对全局变量的首次解引用。
如何快速定位哪个 init 在用哪个未初始化的变量？
不要靠猜。启用 Go 的初始化追踪：
- 编译时加
-gcflags="-m -m"可看到变量逃逸和初始化位置（信息较泛） - 更直接的是在可疑包的每个
init开头插入日志：log.Printf("[init] %s starting", "pkg/name")，并确保日志不依赖任何可能未就绪的全局对象（例如用fmt.Printf替代log.Println） - 若 panic 发生在测试中，运行
go test -gcflags="-l" -v禁用内联，让堆栈更清晰 - 用
go tool compile -S main.go查看汇编，确认变量初始化指令是否在对应init之前生成（进阶排查）
修复策略：避免在 init 中做“真工作”
init 应只做无副作用、无外部依赖的纯初始化（如常量映射预设、简单切片分配）。所有需跨包协作的初始化，必须显式延迟到 main 或启动函数中。
常见重构方式：
- 把
var db *sql.DB和init() { db = setupDB() }拆成：声明var db *sql.DB+ 导出函数func InitDB(cfg Config) error { db = setupDB(cfg); return nil } - 中间件注册从
init()改为app.Use(middleware.Auth)显式调用，由框架启动流程统一控制时序 - 若必须“自动注册”，改用函数值注册表：定义
var initHooks []func() error，各包通过func init() { initHooks = append(initHooks, myInit) }注册，再由主程序遍历执行 —— 这样顺序可控，且可加 error 处理
Go 1.21+ 的新约束：init 不再允许调用其他包的导出函数？
不是。Go 语言规范从未禁止该行为，但 Go 1.21 强化了初始化图（initialization graph）验证逻辑，使得原本“侥幸成功”的跨包 init 调用（比如调用另一个包尚未执行完的 init 中初始化的函数）更容易暴露为 panic。
这意味着：以前能跑通的代码，在升级后可能突然崩在 init 阶段。重点检查所有跨包调用，尤其是类似 log.SetOutput(zap.L().Writer()) 这类依赖对方 init 已设置好 logger 实例的写法 —— 它们现在更大概率会遇到 nil。
真正容易被忽略的是：第三方库自身的 init 行为不可控。如果它在 init 里做了网络请求或读配置，而你的代码又恰好和它同包或强依赖，时序就彻底失控。此时唯一稳妥做法是——别让它进你的构建流，用 go.work 或 replace 暂时锁定旧版，或 fork 后删掉其 init 改为显式初始化。
