Go 的 init 函数在 main 之前、且仅在包首次被导入时执行一次，按依赖图拓扑排序，同包内按文件名字典序执行；禁止 IO、阻塞、跨包变量访问等副作用操作。
init 函数到底什么时候执行？
Go 的 init 函数在 main 之前、且仅在包首次被导入时自动运行一次，但它**不是按 import 语句顺序执行的**，而是由编译器根据依赖图做拓扑排序：被依赖的包（比如 pkg/config）一定先于依赖它的包（比如 pkg/httpserver）执行 init。
- 同一文件里多个
init按代码从上到下顺序执行 - 同一包内不同文件的
init，按文件名**字典序**执行（01_db.go先于02_router.go），但这是当前编译器实现行为，不是语言规范保证 - 空白导入
import _ "net/http/pprof"会触发目标包的init，且它发生在当前包所有变量声明和init之前 - 循环 import（哪怕间接，如 A→B→C→A）会导致初始化环 panic，错误类似
runtime: goroutine stack exceeds 1000000000-byte limit
为什么 init 里访问其他包变量会 panic？
因为跨包访问没保障——你写的 config.Port 看似是个全局变量，但它所属包的 init 可能还没跑，变量还是零值。常见错误现象是 panic: runtime error: invalid memory address or nil pointer dereference，尤其出现在日志、数据库连接、HTTP handler 注册等场景。
- 别在
init中调用其他包的导出函数（如log.SetOutput），除非你确认它不依赖未初始化的内部状态 - 同一包内跨文件访问也危险：如果
a.go的init引用了b.go声明的变量，而b.go字典序靠后，那变量还没初始化 - 变量初始化表达式（如
var port = os.Getenv("PORT")）在同文件init之前执行，但如果它调了别的包函数，照样可能 panic
哪些事绝对不该在 init 里做？
init 是包加载阶段的“临界区”，阻塞、IO、锁、网络请求都会卡死整个程序启动流程，而且无法 recover。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动 HTTP server：
http.ListenAndServe会永久阻塞，导致依赖该包的其他init永远等不到返回 - 连接数据库或 Redis：超时、认证失败、网络不可达都会让程序卡在初始化阶段，且无日志可查
- 读取大文件或解析复杂配置：可能耗时长，拖慢启动，且错误难以定位
- 调用
time.Sleep或任何同步等待逻辑：违背init的轻量初始化本意
真正安全可控的初始化怎么做？
把初始化逻辑从隐式的 init 拆出来，变成显式的、可测试、可控制顺序的函数调用。这是大型项目里最稳定的做法。
- 每个子包提供
func Init() error（或Setup()），内部用sync.Once保证幂等 - 在
main()里按需顺序调用：config.Init()→db.Init()→router.Init() - 测试时可跳过某步（比如用内存 DB 替代真实连接），或提前注入 mock 配置
- 若只是读环境变量或设默认值（如
debugMode = os.Getenv("DEBUG") == "true"），init仍可接受，但别掺杂副作用
最容易被忽略的是：第三方包（比如 MySQL 驱动、Zap 日志封装）的 init 会悄悄执行一堆操作，你没写 import _，它就不动；一旦引入，就等于把它的初始化时机交给了 Go 编译器调度——这点在容器冷启动或 CI 环境中特别容易暴露问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
