go的init函数执行顺序由编译器静态分析决定：跨包按依赖拓扑序（被依赖包先执行），同包按文件名unicode字典序（如01_config.go早于db.go），同一文件内按源码自上而下顺序；该顺序不可手动控制，强依赖应改用显式init()函数。
Go 的 init 函数执行顺序不是你写在哪、import 在哪行就按哪跑的——它由编译器静态分析决定，你没法“安排”，只能顺应或绕开。
同一包内多个 init 怎么排？文件名说了算
编译器把同一包下所有 .go 文件按文件名 Unicode 字典序排序（不是创建时间、不是 import 顺序），再依次执行每个文件里的 init。比如 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）是 hack，重构时极易断裂；更稳妥的是把强依赖逻辑合并进一个文件，或改用显式函数
跨包 init 为什么没按 import 行顺序走？
Go 不看 import 语句顺序，而是构建依赖图，按拓扑序执行：被依赖包的 init 一定先于依赖它的包。但这个“依赖”只认 import 列表里**直接出现**的包，不包括间接依赖或运行时反射加载的包。
- 典型误判：
main.go同时import "pkg/db"和import "pkg/cache"，两者无相互 import → 它们的init执行顺序未定义，可能每次 build 都不同 -
import _ "github.com/lib/pq"是为了触发驱动注册，但它必须出现在database/sql被使用之前，且不能被编译器优化掉（比如放在build tag条件里） - 循环 import（哪怕只是
import _）会导致编译失败，错误类似import cycle not allowed
为什么在 init 里连数据库或读配置总失败？
init 是包加载阶段的临界区，所有操作必须无副作用、不阻塞、不依赖运行时输入——但数据库连接、配置解析、flag 解析、环境变量读取全都不满足。
- 常见现象：
os.Getenv("DB_URL")返回空；flag.String("port", "8080", "")永远是默认值（因为flag.Parse()在main里才执行） - 绝对不该做：
http.ListenAndServe（永久阻塞）、sql.Open（可能超时/认证失败）、os.ReadFile（路径错或权限不足时静默失败） - 更隐蔽的坑：
init里调其他包的导出函数（如log.SetOutput），而该函数内部又依赖它自己包的未初始化变量
真正安全可控的初始化该怎么做？
把初始化逻辑从隐式的 init 拆出来，变成显式的、可测试、可控制顺序的函数调用。
- 每个子包提供
func Init() error或func Setup() error，内部用sync.Once保证幂等 - 在
main()中按需顺序调用：config.Init()→db.Init()→router.Init() - 这样能明确控制依赖链、方便注入 mock、支持失败重试、避免测试时 init 执行两遍的问题
复杂点在于：一旦用了显式初始化，就得同步维护调用顺序和错误传播路径；容易被忽略的是——那些被 import _ 触发的包（比如 net/http/pprof）仍会悄悄提前执行，得确认它们不干扰你的主流程。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
