go 的 init 函数按包依赖拓扑序执行，同一文件内多个 init 按声明顺序执行，跨文件顺序不保证；变量初始化在 init 前求值，但依赖包的完整初始化必须先完成；flag.parse() 等需运行时环境的操作不可在 init 中调用。
Go 的 init 函数不是按文件顺序执行，而是严格按依赖图拓扑排序——包 A 依赖包 B，则 B 的 init 一定在 A 之前运行，哪怕 B 的文件写在 A 后面。
多个 init 函数的执行顺序怎么确定
同一个文件里可以定义多个 init 函数，它们按源码从上到下的声明顺序执行；跨文件时，Go 编译器不保证顺序（即使 go build 每次结果一致，也不应依赖）；真正可靠的只有「包级依赖顺序」——比如 import "net/http" 的包，其所有 init 一定在当前包的 init 之前完成。
- 不要在不同文件的
init里互相读写全局变量，除非你明确控制了导入依赖链 - 如果必须串行初始化，把逻辑合并到单个
init函数里，或改用显式Init()函数调用 -
go tool compile -S main.go可查看编译器生成的初始化调用序列，用于调试隐式依赖
init 和包变量初始化谁先谁后
包级变量初始化表达式（var x = f()）在 init 函数之前求值；但若变量初始化依赖另一个包的变量，则那个包的整个初始化流程（包括其变量初始化和 init）必须先完成。
- 下面代码中，
y的初始化会触发log包加载，因此log的所有init在y赋值前执行完毕：var y = log.New(os.Stderr, "", 0)
- 循环导入会导致编译失败，不会进入
init阶段，所以不必担心死锁 - 切忌在变量初始化表达式里调用本包其他未初始化的变量——它可能还没被赋值（如
var a = b; var b = 1中a得到 0）
为什么 init 里不能用 flag.Parse()
flag.Parse() 必须在 main 函数开始后调用，因为命令行参数此时才可用；而 init 在 main 之前执行，os.Args 虽已存在，但 flag 包内部状态尚未就绪，直接调用会 panic：
flag provided but not defined: -test.timeout（尤其在测试环境下更明显）。
- 常见错误：在
init里解析配置、连接数据库、注册 handler——这些操作应推迟到main开始后，或用惰性初始化（sync.Once）封装 - 如果想让配置“看起来像初始化就绪”，可把解析逻辑放在函数里，
init中只做轻量注册，真正在首次使用时触发 - 测试时
init会被执行两次（一次单元测试，一次go test主流程），容易导致资源重复初始化
最常被忽略的是：init 函数里的 panic 不会打印完整堆栈，默认只输出 panic 内容，且无法用 recover 捕获——一旦出错，程序立即终止，连日志都来不及刷盘。线上服务里，建议用 log.Fatal 替代裸 panic，至少确保错误能落地。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
