go中同一包内多个init函数按文件名字典序执行，文件内按出现顺序；跨包则按导入依赖链递归初始化，但仅限直接import的包。
同一个包里多个 init 函数的执行顺序
Go 会按源文件在编译时的字典序（文件名升序）依次加载，每个文件内则按出现顺序执行 init。不是按 import 顺序，也不是随机——但你不能靠写几个 init 来“控制依赖”，因为文件名排序不可控且易被重构破坏。
常见错误现象：panic: runtime error: invalid memory address，比如 A 文件的 init 用了 B 文件定义的全局变量，但 B 文件名排在 A 后面，导致变量还没初始化。
- 把强依赖的初始化逻辑收进一个
init函数里，别拆到多个文件 - 如果必须分文件，用命名一致的前缀（如
01_config.go、02_db.go）强制排序，但这是权宜之计 - 更稳妥的做法：把初始化逻辑封装成普通函数，显式调用，而非依赖
init隐式触发
跨包 init 的触发时机和依赖链
init 只在包首次被导入且尚未初始化时执行，且会递归初始化所有未初始化的直接依赖包——但只限于 import 列表里出现的包，不包括间接依赖或运行时反射加载的包。
使用场景：比如 database/sql 包的 init 会自动注册驱动，你 import _ "github.com/lib/pq" 就是为了触发它的 init；但如果你漏了这个 import，sql.Open("postgres", ...) 就会报错 sql: unknown driver "postgres"。
立即学习“go语言免费学习笔记（深入）”；
- import _ "xxx" 是为了触发副作用，不是为了用它的导出符号
- 循环 import 会导致编译失败，Go 不允许包 A import B 同时 B import A，哪怕只是 _ import
- 测试文件（*_test.go）里的
init不会影响主包初始化顺序，但 go test 会单独初始化测试包及其依赖
init 和 main 的边界与限制
init 函数不能有参数、不能有返回值、不能被显式调用——它只由运行时在包加载阶段调用一次。一旦执行完，就再无机会重试或修正。
容易踩的坑：在 init 里做 I/O、网络请求、加锁、甚至调用其他包的未初始化变量，都可能因时机不对而失败或死锁。
- 避免在
init中打开数据库连接、读配置文件、启动 goroutine——这些该交给应用启动流程统一管理 -
init里不能 defer，也不能 recover panic；一旦 panic，整个程序立即终止，不会打印完整栈，排查困难 - 交叉编译（如 darwin/amd64 → linux/arm64）时，某些条件编译的
init可能不执行，但相关变量仍被声明，造成零值误用
调试包初始化卡在哪？怎么查 init 执行流
Go 没有内置的 init 调试开关，但可以用 go build -gcflags="-m=2" 看编译器是否内联或优化掉某些调用；更直接的是用 go tool trace 或打日志——但注意：log 输出本身也依赖初始化好的 os.Stdout。
最实用的办法是加一句可定位的 print，在每个 init 开头输出包名和文件名：
func init() {
fmt.Printf("[init] %s %s\n", "mypkg", "config.go")
// ...
}
性能影响很小，但上线前记得删掉或用 build tag 控制。
真正复杂的是 vendor 和 replace 导致的包路径歧义：同名包可能来自不同路径，init 执行的是哪个版本，得看 go list -f '{{.Deps}}' . 输出和实际构建时 resolve 的路径。这点很容易被忽略，尤其在 CI 环境里复现不了本地问题。
