init函数执行顺序由依赖图拓扑排序决定，被依赖包init先于依赖包执行；同一包内按文件字典序执行，但该顺序未被语言规范保证，不应依赖。
init 函数的执行顺序由包依赖图决定
Go 编译器不会按文件名或 import 语句出现顺序执行 init，而是基于构建时解析出的**有向无环图（DAG）**：被依赖的包一定先于依赖它的包执行 init。比如 main 包 import 了 http，而 http 又 import 了 net，那么 net 的 init 一定在 http 之前，http 的一定在 main 之前。
这个顺序是编译期静态确定的，和运行时无关；同一包内多个 init 函数则按源文件字典序执行（但不应依赖此行为）。
同一包内多个 init 函数的执行顺序不可靠
一个 Go 包中可以定义多个 init 函数，它们会按所在源文件的文件名排序后依次执行。但这只是当前实现细节，Go 语言规范明确指出：同一包内多个 init 的执行顺序未定义。实际开发中常见踩坑点：
- 在
a.go中初始化全局变量var cfg Config，又在b.go的init中读取它 —— 看似能跑，但换编译环境或加新文件就可能 panic - 用
init注册回调，但注册顺序影响最终行为（如中间件链），结果在 CI 上偶发失败 - 测试时因
go test可能只编译部分文件，触发不同文件加载顺序，导致测试通过但主程序崩溃
跨包循环 import 会导致编译失败，init 不会执行
如果 pkgA import pkgB，而 pkgB 又直接或间接 import pkgA，Go 编译器会报错：
import cycle not allowed
此时整个构建中断，所有 init 都不会运行。注意以下隐式循环场景：
- 通过
_ "some/pkg"引入副作用包，而该包又 import 当前包 - vendor 或 replace 导致路径解析异常，使两个模块互相引用
- 内部工具生成代码时硬编码 import 路径，未考虑模块边界
这类错误通常不报 init 相关信息，容易误判为启动逻辑问题。
测试时 init 执行时机与 go test -run 的关系
go test 会先完成整个包的初始化（包括所有 init），再运行测试函数。这意味着：
- 即使你只跑单个测试（
go test -run TestFoo），所有被导入包的init仍会执行 - 测试文件（
*_test.go）中的init也参与排序，且与普通源文件同级竞争执行顺序 - 如果测试依赖某个
init设置的全局状态（如修改http.DefaultClient），而该init在另一文件中，就可能因文件名变化导致测试 flaky
真正可控的初始化方式是显式调用函数（如 SetupTest()），而不是把逻辑塞进 init。
init 的设计初衷是做「不可跳过的、包级的、一次性的」准备动作，比如注册驱动、设置默认值。一旦它开始承担业务逻辑、状态协调或跨包协作职责，就很容易滑向不可维护的边缘 —— 尤其当团队成员不熟悉 DAG 执行模型时。
