init函数在main前按包依赖拓扑序执行，同包内按源文件字典序；变量初始化先于init，不可做阻塞操作或错误处理，应仅用于轻量无副作用操作。
init函数的执行时机和顺序规则
Go 包中所有 init 函数会在 main 函数运行前自动执行，但不是按文件名或定义顺序，而是严格遵循「包依赖拓扑序」：被导入的包先初始化，导入它的包后初始化。同一个包内多个 init 函数，则按源文件在 go list 输出中的字典序执行（实际是编译器遍历文件系统的顺序，通常等价于文件名升序）。
常见错误现象：panic: runtime error: invalid memory address 出现在 main 开头，往往是因为某个 init 里提前用了未初始化的全局变量，或跨包依赖时 A 包的 init 试图访问 B 包尚未执行完的变量。
- 一个包可定义多个
init函数，但不能带参数、不能有返回值、不能被显式调用 - 如果包有多个源文件，每个文件可含一个
init，它们全部参与排序，不因文件名含下划线或数字而跳过 -
import _ "pkg"的匿名导入仍会触发该包的全部init，这是实现驱动注册等机制的基础
如何调试 init 执行流程
当初始化逻辑出错且堆栈不清晰时，最直接的办法是加日志并配合 go build -gcflags="-m=2" 观察编译期报告，但更有效的是运行时打点：
func init() {
fmt.Printf("init in %s\n", "utils.go")
}
不过要注意：标准库如 log 在早期 init 阶段可能尚未就绪（其自身也有 init），优先用 fmt.Printf；若需格式化输出又担心竞态，可改用 os.Stderr.WriteString。
立即学习“go语言免费学习笔记（深入）”；
- 使用
go tool compile -S main.go | grep "CALL.*init$"可看到编译器生成的初始化调用序列 - 设置环境变量
GODEBUG=inittrace=1运行程序，会打印每个包的初始化耗时与依赖关系（Go 1.20+） - 不要在
init中做阻塞操作（如 HTTP 请求、数据库连接），这会导致整个程序启动卡住且无超时机制
init 和变量初始化的交互细节
包级变量声明时的初始化表达式，会在对应 init 函数之前执行。例如：
var a = func() int { println("var a init"); return 1 }()
func init() { println("in init") }
输出一定是：var a init → in init。这是因为 Go 规范将「包级变量初始化」视为初始化阶段的第一步，init 是第二步。
- 如果变量初始化表达式中调用了其他包的函数，那么那个包必须已初始化完成（否则 panic）
- 循环引用包（A 导入 B，B 又导入 A）在编译时报错，不会进入运行时初始化阶段
- 常量（
const）和类型定义（type）不参与初始化流程，无执行开销
init 不适合做什么
init 不是通用启动逻辑容器。它无法接收参数、无法返回错误、无法重试、无法被测试框架控制生命周期。一旦失败，整个进程立即终止，且错误信息极其简陋（只有 panic 栈，无上下文）。
- 避免在
init中打开文件、连接数据库、读取配置——这些应移到main或显式初始化函数中，便于错误处理和单元测试 - 不要用
init注册回调或全局钩子，除非你明确接受「不可撤销、不可重置」的语义（比如database/sql驱动注册） - 多 goroutine 启动（如起后台定时器）在
init中极易引发竞态，因为此时maingoroutine 尚未开始，调度器状态不稳定
真正需要初始化逻辑的地方，往往更适合设计成一个 Setup() 函数，在 main 开头显式调用，并返回 error —— 这样可控、可测、可调试。而 init 应只保留极轻量、无副作用、必然成功的操作，比如设置默认值、预热 sync.Pool、注册已知安全的接口实现。
