多个init函数按文件字典序及文件内出现顺序执行；空白导入触发的init在当前包init前完成；循环import会导致初始化环panic；测试文件init不干扰主包但需注意状态污染。
多个 init 函数在同一个包里怎么执行
同一个包内可以定义多个 init 函数，它们按源文件从上到下、文件名按字典序（Go 1.21+ 默认启用 GOEXPERIMENT=fileorder 前是未定义顺序，但实际编译器仍按读取顺序）依次执行。关键不是“谁先写”，而是“编译器看到的顺序”。
常见错误现象：init 里依赖了另一个同包变量，但该变量的初始化语句在后一个文件里，结果得到零值——这不是 bug，是明确的执行顺序规则。
- 每个
.go文件内的多个init函数，按出现顺序执行 - 不同文件间的
init执行顺序：Go 1.21 起由go list -f '{{.GoFiles}}'输出顺序决定；旧版本依赖文件系统遍历顺序，不可靠 - 不要跨文件假设初始化顺序；用显式函数调用替代隐式依赖
import _ "xxx" 触发的 init 什么时候跑
空白导入（import _ "net/http/pprof"）只为触发目标包的 init，不引入任何符号。它的 init 在当前包所有变量声明和 init 执行前完成，但严格来说是在「导入链解析完毕后、主包 init 开始前」执行。
使用场景：注册 HTTP handler、设置全局 codec、启用 pprof、初始化数据库驱动等。
立即学习“go语言免费学习笔记（深入）”；
-
init是包级的，只要该包被 import（哪怕用_），就一定会执行一次，且仅一次 - 如果 A 包
import _ "B"，而 B 又import "C"，那么 C 的init→ B 的init→ A 的init（变量初始化→init） - 避免在
init里做阻塞操作（如网络请求、锁等待），它会卡住整个包加载流程
循环 import 导致 init 崩溃的典型表现
Go 不允许直接循环 import（A→B→A），但间接循环（A→B→C→A）在某些条件下可发生，此时 init 会 panic，错误信息类似：runtime: goroutine stack exceeds 1000000000-byte limit fatal error: stack overflow 或更直接的 initialization loop。
根本原因不是语法报错，而是运行时检测到初始化图存在环，无法确定执行起点。
- 常见诱因：两个包互相用空白导入触发对方
init，或通过接口/函数间接形成依赖闭环 -
go build -x可看到 import 链，配合go list -f '{{.Deps}}' pkg检查依赖图 - 解决思路：把共享逻辑抽到第三个包；用 lazy 初始化（如
sync.Once+ 函数）替代init中的强依赖
测试文件里的 init 和主代码冲突怎么办
测试文件（*_test.go）属于独立包（xxx_test），即使和主包同名，也是两个包。因此它的 init 不会干扰主包 init，但可能因共享外部状态（如全局 map、环境变量、临时文件）造成干扰。
最容易被忽略的是：测试中调用主包代码，而主包 init 已执行过；但若测试文件本身也 import 主包（非 _），就会触发主包 init —— 这是唯一一次测试能“触发”主包 init 的方式。
- 测试文件中的
init仅影响xxx_test包自身，不会污染主包 - 若测试需重置主包状态（如清空全局缓存），不能靠重新
init（不可能），得提供显式 reset 函数 - 避免在
init里写日志或修改 stdout/stderr，测试框架可能已接管输出流，导致 panic 或静默失败
init 里的副作用——它们不报错、不文档、只在特定环境里悄悄改掉你的配置。 
