init函数不是程序启动时统一执行的脚本，而是包首次被import或符号被引用时触发的一次性加载临界点；其执行顺序由编译器静态决定：同一文件内按代码从上到下执行，同一包不同文件按文件名Unicode字典序执行（如01_config.go早于db.go），跨包则按依赖拓扑序（被依赖包先执行），但该顺序不可靠，强依赖应改用显式Init()函数。
init 函数不是“程序启动时统一跑一遍”的初始化脚本，而是包被首次 import（或符号被引用）时触发的、一次性的加载临界点。它执行顺序由编译器静态决定，不能靠写代码位置或 import 行顺序控制。
同一包内多个 init 函数怎么执行？
同一文件里的多个 func init() 按代码从上到下顺序执行；不同文件之间的 init() 则按文件名 Unicode 字典序执行（如 01_config.go 早于 db.go，而 z_router.go 很可能最晚）。这不是语言规范保证的行为，只是当前 Go 编译器实现细节。
- 常见翻车：a.go 的
init()读取 b.go 声明的全局变量dbConn，但 b.go 文件名字典序靠后 →dbConn还是零值，直接 panic - 同一文件中写两个
init()是合法的，但它们之间无法插入变量初始化逻辑 —— 所有包级变量早已初始化完毕 - 别用注释、空行或函数命名“假装控制顺序”，编译器不认这些
- 如果真要靠排序，可用数字前缀（如
01_init.go），但这只是 hack，重构时极易断裂
跨包 init 执行顺序为什么不能靠 import 行顺序判断？
Go 不按 import 语句出现顺序执行跨包 init()，而是构建包依赖图（DAG），按拓扑序执行：被依赖包的 init() 一定先于依赖它的包。这个“依赖”只看直接 import，不追踪间接依赖。
- 典型翻车：main 同时
import "pkg/db"和import "pkg/cache"，二者无相互 import → 它们的init()执行顺序未定义，每次 build 可能不同 -
import _ "github.com/lib/pq"必须出现在database/sql.Open("postgres", ...)之前，否则驱动未注册，报错sql: unknown driver "postgres" - 循环 import（哪怕 A→B→C→A）会导致编译失败，错误为
import cycle not allowed，根本不会走到init阶段 - 间接依赖（A→B→C）不会自动触发 C 的
init()，除非 C 被 A 或 B 显式 import
为什么在 init 里读环境变量或连数据库常失败？
因为 init() 是包加载阶段的临界区，所有操作必须无副作用、不阻塞、不依赖运行时输入 —— 但 os.Getenv()、sql.Open()、flag.String() 等全都不满足这个前提。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
os.Getenv("DB_URL")在init()里可能返回空字符串：环境变量加载时机晚于包初始化 -
flag.String("port", "8080", "")在init()里永远拿不到用户传入的值，因为flag.Parse()在main()里才执行 -
sql.Open()失败会 panic，且无法返回 error，连日志都难打全 - 测试时
go test可能多次初始化同一包（每个测试文件单独编译加载），导致端口冲突或连接复用失败
真正安全可控的初始化该怎么做？
把初始化逻辑从隐式的 init() 拆出来，变成显式的、可测试、可控制顺序的函数调用。Go 的 init() 设计初衷只是注册驱动、设置默认值这类不可跳过的一次性准备动作。
- 用
NewDB(cfg Config) (*sql.DB, error)替代全局var DB *sql.DB+init()赋值 - 把配置加载、日志初始化、HTTP server 启动等逻辑移到
main()或专用启动函数中 - 若需“自动注册”，可用函数变量注册表 + 显式
InitAll()，而非依赖init() - 测试时可通过参数或接口注入依赖，避免因
init()无法重入、无法 mock 导致测试 flaky
真正麻烦的不是顺序本身，而是把业务初始化塞进 init() 后，你失去了对错误传播路径、依赖生命周期和测试边界的控制。越早放弃用它做协调逻辑，后期维护成本越低。
