init函数执行顺序由编译器按依赖图拓扑序和文件名字典序决定：跨包时被依赖包init先执行，同一包内按文件名升序执行，同一文件内按代码从上到下顺序执行。
init 函数的执行顺序不是靠写几个函数就能控制的，它由编译器按依赖图 + 文件名排序隐式决定，你无法靠调整 init 函数位置或 import 语句顺序来“安排”初始化逻辑。
同一包内多个 init 函数怎么排？
同一个 .go 文件里的多个 init 函数，按代码从上到下顺序执行；但同一包下不同文件的 init，按文件名**字典序**（不是 import 顺序，也不是创建时间）加载并执行。比如 01_config.go 一定早于 db.go，而 z_router.go 会非常晚。
- 常见错误现象：
a.go的init引用了b.go声明的全局变量dbConn，但b.go字典序在后 →dbConn还是零值，直接 panic - 别用注释、函数名或空行“假装控制顺序”，编译器不认这些
- 如果真要靠文件名排序，可用数字前缀（如
01_init.go、02_db.go），但这只是 hack，重构时极易断裂
跨包 init 为什么有时不按 import 顺序走？
Go 不按 import 语句顺序执行跨包 init，而是按**依赖拓扑序**：被依赖的包（如 pkg/config）一定先于依赖它的包（如 pkg/server）执行 init。但这个“依赖”只看 import 列表里**直接出现**的包，不包括间接依赖或运行时反射加载的包。
- 典型翻车场景：
main.go同时import "pkg/db"和import "pkg/cache"，两者无相互 import，但你误以为它们的init会按 import 行顺序执行 —— 实际顺序未定义，可能每次 build 都不同 -
import _ "github.com/lib/pq"是为了触发其init注册驱动，但它必须出现在database/sql被使用之前，且不能被优化掉（比如放在条件编译里） - 循环 import（哪怕 A→B→C→A）会导致编译失败，错误类似
import cycle not allowed
为什么在 init 里连数据库或读配置常失败？
因为 init 是包加载阶段的临界区，所有操作必须无副作用、不阻塞、不依赖运行时输入 —— 但数据库连接、配置解析、flag 解析、环境变量读取等，全都不满足。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：
init里调os.Getenv("DB_URL")，结果为空；或调flag.String("port", "8080", "")，但flag.Parse()在main里才执行 → 变量永远是默认值 - 绝对不该做：
http.ListenAndServe（永久阻塞）、sql.Open（可能超时/认证失败）、os.ReadFile（路径错或权限不足时静默失败） - 更隐蔽的坑：
init里调其他包的导出函数（如log.SetOutput），而该函数内部又依赖它自己包的未初始化变量
真正安全可控的初始化该怎么做？
把初始化逻辑从隐式的 init 拆出来，变成显式的、可测试、可控制顺序的函数调用。这是大型项目里最稳定的做法。
- 每个子包提供
Init()或Setup()函数，内部用sync.Once保证幂等 - 在
main()开头按需顺序调用：config.Init()→db.Init()→cache.Init() - 需要传参或返回错误的初始化，必须走显式函数 ——
init函数连 error 类型都不能返回 - 测试时可跳过某步初始化，或注入 mock，而
init一旦触发就不可逆、不可重试
复杂点在于：很多老项目已深陷 init 泥潭，迁移时得同步检查所有跨包变量访问和副作用调用；最容易被忽略的是——你以为某个包“没被 import”，其实它被第三方库间接引入了，它的 init 仍会执行。
