同一包内多个init函数执行顺序由编译器严格确定：同一文件内按代码从上到下顺序执行，同一包不同文件按文件名unicode字典序执行（如01_config.go早于db.go），跨包则按依赖拓扑序，被依赖包init先执行。
同一包内多个init函数的执行顺序怎么确定
Go 编译器不看 import 顺序、不看文件创建时间、也不认注释或空行，它只按两个规则走：同一文件内，init 函数严格按源码从上到下出现的顺序执行；同一包下不同文件，则按文件名 Unicode 字典序排序后依次加载——比如 01_config.go 一定早于 db.go，而 z_router.go 几乎总在最后。
常见错误现象：a.go 的 init 直接用了 b.go 声明的 var db *sql.DB，但 b.go 字典序靠后 → db 还是 nil，调 db.Ping() 就 panic。
- 别用函数名或注释“暗示”顺序，编译器完全忽略
- 想强制排序？可用数字前缀（如
01_db.go、02_cache.go），但这只是临时 hack，重构时极易断裂 - 更稳妥的做法：把强依赖逻辑全收进一个
init函数里，或干脆不用init，改用显式函数
跨包init为什么没按import语句顺序执行
Go 不按 import 行顺序触发跨包 init，而是构建依赖图后按拓扑序执行：被直接 import 的包（如 pkg/config）一定先于依赖它的包（如 pkg/server）完成 init。但这个“依赖”只认 import 列表里**显式写出**的包，不包括间接依赖或运行时反射加载的包。
典型翻车场景：main.go 同时 import "pkg/db" 和 import "pkg/cache"，两者无相互 import，你误以为它们的 init 会按 import 行顺序执行 —— 实际顺序未定义，可能每次 go build 都不同。
-
import _ "github.com/lib/pq"是为了触发其init注册驱动，但它必须出现在database/sql被使用之前，且不能被编译器优化掉（比如放在// +build ignore条件编译块里） - 循环 import（哪怕只是
import _）会导致编译失败，报错类似import cycle not allowed - 间接依赖（A→B→C）不会自动触发 C 的
init，除非 A 或 B 显式 import C
为什么在init里连数据库或读配置常失败
init 是包加载阶段的临界区，所有操作必须无副作用、不阻塞、不依赖运行时输入。但数据库连接、配置解析、flag 解析、环境变量读取等，全都不满足这个前提。
常见错误现象：init 里调 os.Getenv("DB_URL")，结果为空；或调 flag.String("port", "8080", "")，但 flag.Parse() 在 main 里才执行 → 变量永远是默认值。
- 绝对不该做：
http.ListenAndServe（永久阻塞）、sql.Open（可能超时/认证失败）、os.ReadFile（路径错或权限不足时静默失败） - 更隐蔽的坑：
init里调其他包的导出函数（如log.SetOutput），而该函数内部又依赖它自己包的未初始化变量 - 包级变量初始化表达式（如
var port = os.Getenv("PORT")）在本文件所有init之前执行，但如果它调了别的包函数，仍可能因依赖未就绪而 panic
多模块项目中真正安全可控的初始化怎么做
把初始化逻辑从隐式的 init 拆出来，变成显式的、可测试、可控制顺序的函数调用。这是唯一能避开所有陷阱的路径。
例如，在各模块定义 func Init() error，返回错误便于链式校验；在 main() 中按需顺序调用：config.Init() → db.Init() → router.Init()。
- 配合
sync.Once确保多次调用安全，或用状态标记防止重复初始化 - 测试时可单独调用某个
Init()，不用启动整个程序，也不怕init执行两遍（go test会为每个测试文件单独初始化包） - 如果必须用
init（比如注册 driver），只做最轻量的副作用：赋值、注册、预热常量，绝不碰 I/O、网络、锁、全局状态
复杂点从来不在“怎么写 init”，而在“要不要用 init”——一旦初始化逻辑涉及任何外部依赖或运行时状态，init 就不再是帮手，而是定时炸弹。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
