Go中init函数执行顺序由源文件内声明先后决定，而非文件名或导入顺序；可靠控制方式是用sync.Once或显式Init函数替代多init依赖。
Go 中 init 函数的执行顺序规则是固定的
同一个包内多个 init 函数的执行顺序，**由它们在源文件中声明的先后顺序决定**，而不是按文件名、导入顺序或定义位置的“逻辑顺序”。Go 编译器会按源文件被解析的顺序（即 go build 时的文件遍历顺序）依次收集每个文件里的 init，再按每个文件内部从上到下的顺序执行所有 init 函数。
这意味着：如果你有 a.go 和 b.go，且两者都在同一包下，a.go 里有两个 init，b.go 里有一个，实际执行顺序取决于 go build 读取文件的顺序——而这个顺序在 Go 1.19+ 默认是按文件名字典序（a.go 在 b.go 前），但不保证跨 Go 版本或不同构建环境完全一致。所以不能依赖文件名排序来控制 init 顺序。
如何可靠地控制 init 执行顺序
唯一可信赖的方式，是把依赖关系显式编码进代码里：让后执行的逻辑主动等待前序初始化完成。Go 标准库和主流项目都用这种方式，比如 sync.Once 或简单布尔标记 + 循环检查（不推荐）。
- 用
sync.Once包裹真正需要单次执行的初始化逻辑，把多个init拆成普通函数，在需要时手动调用 - 把初始化拆成明确的
InitX()、InitY()函数，由主程序或某个中心init按需调用，避免把所有逻辑塞进init - 如果必须用多个
init，且存在强依赖（如 A 必须在 B 前运行），就把 B 的逻辑延迟到 A 完成后再触发——例如用sync.Once+ 闭包，或用atomic.Bool标记 A 是否就绪，B 中轮询或阻塞等待（仅限极少数场景，慎用）
常见错误：误以为 init 执行顺序可跨文件控制
典型错误是给文件编号（01_config.go、02_db.go），以为这样就能保证 init 执行顺序。实际上：
- Go 不保证按文件名排序加载（即使当前版本这么做，也不应依赖）
- 使用
//go:build条件编译时，某些文件可能被跳过，导致顺序突变 -
go test可能只编译部分文件，顺序与go build不同 - IDE 或构建缓存可能改变文件读取顺序
你看到的“稳定顺序”只是巧合，不是契约。
替代方案：用显式初始化代替 init 链
更健壮的做法是放弃多 init 依赖，改用可测试、可控制的初始化流程：
- 定义一个
func Setup() error，集中管理初始化步骤，按需调用initDB()、loadConfig()等 - 在
main()开头或init()中只做最轻量的注册（如flag.StringVar），重逻辑延后 - 对第三方库（如
sql.Open、log.SetOutput）的初始化，也应在Setup()中统一处理，而非散落在多个init
init 函数适合做无副作用、无依赖、幂等的注册动作（如 http.HandleFunc、database/sql.Register）。一旦涉及状态依赖或顺序敏感操作，它就不再是合适的载体。
