init函数执行顺序由编译器静态分析包依赖图与文件名字典序共同决定：跨包按拓扑序（被依赖包先于依赖包），同包按文件名unicode字典序，同一文件内按源码从上到下顺序。
init() 的执行顺序不是靠代码位置或 import 顺序决定的，而是由编译器静态分析包依赖图 + 文件名排序共同确定的；跨包按拓扑序，同包按文件名字典序，同一文件内按源码从上到下顺序。
同一包多个 .go 文件的 init 执行顺序
Go 编译器把同一包下的所有 .go 文件按文件名 Unicode 字典序（lexicographic order）排序后传入，init 函数就严格按这个顺序执行。比如 a.go、b.go、c.go → a.go 的 init 先跑，然后是 b.go，最后 c.go。
- 这个顺序不看
go build命令里参数怎么写（除非你显式列出文件名，如go build c.go a.go b.go），而是看构建工具最终传递给编译器的顺序 - 文件系统大小写敏感性差异（如 macOS vs Linux）理论上会影响字典序，但
go命令内部统一用strings.Compare，实际行为稳定 - 常见错误：在
a.go的init中直接使用b.go定义的全局变量dbConn，而b.go字典序靠后 →dbConn还是零值，dbConn.Ping()panic - 解决方案：用数字前缀强制排序（如
01_config.go、02_db.go），或更推荐——把强依赖逻辑合并进一个文件，或改用显式函数（如SetupDB()）并在main中调用
同一文件内多个 init 函数的执行顺序
一个 .go 文件里可以定义多个 func init()，它们按源码中出现的**文本顺序**从上到下执行，不是按函数名或声明位置。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不能互相调用（语法报错）
- 常见错误：后面定义的
init用了前面init才赋值的包级变量，但人眼扫代码时误以为“写在后面就后执行”，其实它先跑了 - 变量初始化表达式（如
var port = os.Getenv("PORT")）在该文件所有init之前执行，但如果它调了别的包函数，仍可能因依赖未就绪而 panic - 不推荐靠多个
init拆分逻辑——可读性差、调试困难；真要分步，用普通函数 + 显式调用更可控
跨包 init 的执行顺序怎么判断
编译器按导入依赖图的**拓扑序**执行：被依赖包的 init 一定在依赖它的包之前完成。比如 pkg/httpserver 导入了 pkg/config，那么 pkg/config.init 必然先于 pkg/httpserver.init。
-
import _ "net/http/pprof"会触发net/http/pprof的init，且它发生在当前包所有变量声明和init之前 - 间接依赖（A→B→C）不会自动触发 C 的
init，除非 C 被 A 或 B 显式import - 循环 import（哪怕只是
import _）会导致编译失败，根本走不到init阶段 - 常见错误：在
httpserver.init里直接用了config.Port，但config包只被import _触发，且没被其他符号引用 → Go 1.20+ 可能直接丢弃该包，config.Port是 0
init 里访问跨包变量为什么容易 panic
因为跨包变量初始化没有语言级保障。你写的 var Port = os.Getenv("PORT") 看似简单，但它依赖 os 包已就绪；而 os 自身的 init 是否已完成，取决于它是否被当前初始化链“需要”——这很容易漏掉。
- 典型现象：
panic: runtime error: invalid memory address or nil pointer dereference，堆栈指向日志打印或数据库连接语句，根源却是上游配置包的init没执行，log.Logger或sql.DB仍是nil - 别在
init中调用其他包的导出函数（如log.SetOutput），除非确认它不依赖未初始化的内部状态 - 用
go tool compile -S main.go | grep INIT可查看编译器生成的初始化调用序列，验证实际顺序 - 测试中要注意：每个包的
init在整个go test过程中只执行一次，但并行测试（-p=4）可能暴露竞态，尤其当init修改了环境变量或全局状态时
真正危险的不是顺序本身不可控，而是人误以为“写了就等于能用”。init 阶段没有同步机制、无法 recover、不能阻塞，一旦依赖断裂就是硬失败——所以最稳妥的做法，永远是把初始化逻辑收进显式函数，由 main 控制调用时机。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
