init函数在包初始化阶段由运行时自动执行，同一文件内按源码顺序执行，跨包按依赖图拓扑序执行；多个init共享包级作用域，任一panic则终止程序；避免在init中调用未确保初始化完成的第三方包函数。
init函数的执行时机和顺序规则
init 函数不是普通函数，它没有参数、不能被调用，只在包初始化阶段由 Go 运行时自动执行。关键在于：每个源文件中可以有多个 init 函数，它们按**源码出现顺序**执行；而不同包之间，init 的执行顺序严格遵循**依赖图拓扑序**——被依赖的包先初始化，主包（main）最后。
容易踩的坑是误以为 init 会按文件名或 import 顺序执行。实际上，即使 import _ "pkgA" 写在最前面，如果 pkgB 依赖 pkgA，那 pkgA.init() 仍会在 pkgB.init() 之前完成，与 import 语句位置无关。
多个init函数共存时的行为表现
同一文件中定义多个 init 函数完全合法，Go 编译器会把它们收集起来，按声明顺序依次调用。这种写法常见于模块化初始化逻辑，比如分别处理配置加载、日志设置、数据库连接。
但要注意：所有 init 函数共享包级作用域，变量已声明但未赋值时访问会 panic；且一旦某个 init 函数 panic，整个程序终止，后续 init 不再执行。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func init() {
fmt.Println("first")
}
func init() {
fmt.Println("second")
}
// 输出一定是：
// first
// second
init中调用其他包函数的风险点
在 init 中调用其他包的函数看似方便，但隐含初始化依赖风险。如果被调用函数内部又依赖尚未执行 init 的包，就会触发“未定义行为”或 panic —— 因为 Go 不保证跨包函数调用时对方已完成初始化。
- 避免在
init中调用非标准库的第三方包函数（尤其是带副作用的） - 若必须使用，确保该包明确声明其
init已完成全部前置准备，或改用显式初始化函数（如pkg.Init()）替代 - 标准库如
net/http的http.HandleFunc可在init中安全调用，因其不依赖其他包的未完成初始化
main函数前到底发生了什么
Go 程序启动流程是：runtime.main → 初始化所有依赖包（递归执行各包 init）→ 执行 main 包的 init → 调用 main 函数。这意味着：所有全局变量的初始化表达式（如 var x = heavyComputation()）在对应包的 init 之前就已求值，而 init 函数本身可用于补全这些变量、注册回调、校验环境等。
一个典型错误是把耗时操作（如读取大文件、建立数据库连接）直接放在全局变量初始化里，这会拖慢整个启动过程，且无法错误处理。正确做法是在 init 中做轻量检查，在 main 或首次使用时惰性初始化。
真正复杂的是循环导入场景 —— Go 编译器会拒绝编译，所以你不会遇到运行时 init 死锁，但得提前理清依赖链。
