go中init函数执行顺序由编译器静态决定：先按依赖拓扑排序执行包级init，再按文件字典序、最后按文件内出现顺序；它无参数返回值，不可手动调用，且跨包顺序易受import变更影响。
Go 中 init 函数的执行顺序由编译器静态决定，不是运行时动态调度
Go 的 init 函数没有手动调用入口，也不支持参数或返回值；它在包加载阶段自动触发，顺序完全由依赖图和源文件排列共同决定。你改了 import 顺序、加了个新文件、甚至只是重命名了一个 .go 文件，都可能让跨包 init 执行顺序发生变化——这不是 bug，是语言设计使然。
常见错误现象：
– 主程序启动后发现某个全局变量仍是零值，但明明在另一个包的 init 里赋过值
– 两个包互相 import（循环导入）导致编译失败，但删掉其中一个 init 就能过
– 测试时行为正常，CI 环境里却偶尔 panic，查下来是某包的 init 比预期晚执行了
- Go 编译器按“依赖拓扑排序”确定包级
init顺序：被依赖的包一定先于依赖它的包执行 - 同一包内多个
init函数，按源文件名的字典序执行（a.go先于b.go），而非定义顺序 - 同一文件中多个
init函数，按出现顺序执行（但不建议这么写，易混淆）
排查跨包 init 依赖断裂：用 go list -deps -f '{{.ImportPath}}: {{.Deps}}'
当怀疑 A 包的 init 依赖 B 包已初始化，但实际没发生，本质是 A 并未真正 import B——可能用了 _ import、反射加载、或间接依赖路径断了。不能只看代码里有没有 import "B"，得看编译期是否纳入依赖图。
实操建议：
– 运行 go list -deps -f '{{.ImportPath}}: {{.Deps}}' ./cmd/myapp，检查 A 包是否出现在 B 包的 Deps 列表里
– 如果 A 仅通过 _ "B" 引入，它不会出现在 Deps 中，此时 B 的 init 不保证在 A 之前执行
– 若 B 是通过第三方库间接引入（比如 C → B），而 A 直接 import C，那 A 和 B 之间无直接依赖边，init 顺序不可控
立即学习“go语言免费学习笔记（深入）”；
- 避免用
_ "xxx"触发初始化逻辑，改用显式函数调用（如xxx.Register()） - 若必须靠
init建立顺序，确保有直接 import 关系，且无条件地出现在至少一个非-test 文件中 -
go build -x可看到实际编译的文件顺序，辅助验证字典序影响
调试 init 执行时机：加日志不如打堆栈，用 runtime.Caller
在 init 里写 fmt.Println("A init") 只能告诉你“它跑了”，无法确认“它在谁之后跑”。尤其跨包时，输出混在一起根本分不清上下文。真正有用的是定位调用链。
示例（放在任意 init 函数中）：_, file, line, _ := runtime.Caller(0); fmt.Printf("init %s:%d\n", file, line)
- 比字符串日志更可靠：文件路径+行号不会因重构重命名而失效
- 不要用
Caller(1)或更高——init是编译器插入的，调用栈顶就是它自己 - 如果发现某包的
init完全没输出，先确认它是否被编译进最终二进制（go list -f '{{.Name}}' xxx看是否为main或被依赖）
替代方案：把关键初始化逻辑从 init 移到 main 或显式注册函数
凡涉及跨包状态协同、外部依赖（DB、配置、信号）、或需要错误处理的初始化，都不该塞进 init。它的设计初衷只是做最轻量的、无副作用的准备，比如注册格式、预置常量映射。
典型误用场景：
– 在 db/init.go 的 init 里连接数据库
– 在 config/init.go 的 init 里读取环境变量并解析 YAML
– 在 http/server.go 的 init 里调用 http.HandleFunc
- 连接 DB？放到
main()开头，或封装成db.Open()，由调用方控制时机和错误分支 - 加载配置？提供
config.Load()，返回(*Config, error)，而不是在init里 panic - 注册 handler？用
func RegisterRoutes(r *chi.Mux)显式传入路由实例，避免隐式依赖
复杂点在于：很多人以为把初始化挪到 main 就万事大吉，其实只是把问题从“顺序不可控”变成“调用漏掉”。真正要盯住的是——谁负责触发、谁负责校验、谁承担失败后果。这些没法靠 init 自动解决。
