go中init函数按包依赖拓扑序（最底层包优先）和包内文件字典序执行，全局变量初始化在同文件init前但跨文件受文件名顺序约束，隐式import可能触发意外初始化链。
Go 中 init 函数的执行顺序是确定的，但依赖包导入顺序和文件名
Go 编译器按「包内文件字典序 + 包依赖拓扑序」执行所有 init 函数。不是按代码书写位置，也不是按 import 语句出现顺序——而是先递归解析依赖链，再从最底层包开始，逐个执行其内部所有 init 函数（按文件名升序）。
常见错误现象：panic: runtime error: invalid memory address，发生在某个 init 里用了另一个包的全局变量，而那个变量所在包的 init 还没跑。
- 同一包下多个
init函数，按文件名排序执行（如a.go先于b.go） -
import _ "pkg"触发该包初始化，即使没显式引用任何符号 - 循环 import 会导致编译失败，不会进入
init阶段 - 如果 A 依赖 B，B 依赖 C，则执行顺序一定是 C → B → A 的
init链
全局变量初始化和 init 的先后关系
包级变量初始化表达式在对应 init 函数之前执行，但仅限「本文件内声明的变量」；跨文件时，仍受文件名顺序约束。
使用场景：想确保某个配置结构体在所有 init 前就绪，又不想手动调用初始化函数。
立即学习“go语言免费学习笔记（深入）”；
- 变量声明带初始化表达式（如
var x = foo()），会在该文件的init前执行 - 若
foo()依赖其他包的全局变量，而那个包还没初始化，就会 panic - 不要在变量初始化表达式中调用本包其他未声明的变量（会报
undefined） - 推荐把复杂初始化逻辑收进
init，而非塞进变量声明右侧
调试 init 执行流程的实用方法
没有内置 trace 工具，但可以用极简日志快速定位哪一步卡住或错序。
性能影响几乎为零，但能避免线上环境因初始化顺序导致的偶发 panic。
- 在每个
init开头加log.Printf("[init] %s", "pkg/file.go") - 避免用
fmt.Println—— 标准库log在init阶段更稳定 - 注意：
log.SetOutput本身不能在init里调，可能触发未初始化的 io.Writer - 交叉编译时，不同平台文件系统排序可能略有差异（如 macOS vs Linux），测试需覆盖目标环境
容易被忽略的跨包初始化陷阱
看似无关的 import，可能悄悄触发一长串初始化链，尤其当引入了数据库驱动、HTTP 客户端或日志封装时。
典型例子：import "github.com/go-sql-driver/mysql" 会注册驱动，触发其 init，进而可能初始化全局连接池或默认 logger。
- 第三方包的
init可能读取环境变量、打开文件、连接网络 —— 这些行为在 main 启动前就发生了 - 无法用 go:linkname 或 build tag 关闭某个包的
init，只能删掉 import 或用空标识符跳过（import _ "xxx"仍会执行） - 如果两个包都 init 了同一个全局 map，且没加锁，可能产生竞态（go run -race 可捕获）
- 测试时用
go test -run=^$只编译不运行，可验证初始化是否成功，避免副作用干扰
真正麻烦的不是顺序本身，而是隐式依赖 —— 一个没写文档的 init 函数，可能让整个服务启动失败，还查不到源头。
