Go语言中init函数执行顺序确定：跨包按依赖拓扑序，同包按文件名Unicode字典序，同一文件内按源码自上而下顺序；该顺序由编译器静态分析确定，非import语句或书写位置决定。
init 函数的执行顺序是确定的，但容易被误认为“按文件顺序”或“按 import 顺序”——实际由 Go 编译器按包依赖图拓扑排序决定，且同一包内多个 init 按源码出现顺序执行。
同一个包里多个 init 函数怎么执行？
Go 允许一个包内定义多个 init 函数，它们按源文件中声明的**文本顺序**（即从上到下、从左到右）依次执行，不跨文件排序。但注意：同一文件里多个 init 必须都是函数声明，不能是变量初始化块或匿名函数调用。
- 如果
a.go和b.go都在main包里，a.go的init总是在b.go的init之前执行（前提是a.go字典序更小，如a.govsb.go；Go 编译器按文件名排序后加载） - 同一文件中，先写的
func init() { ... }先执行，后写的后执行 - 不要依赖跨文件的
init顺序做状态传递——这属于未定义行为，不同 Go 版本或构建方式可能变化
import 顺序会影响 init 执行吗？
会，但不是因为 import 语句本身，而是因为它触发了被导入包的初始化。Go 的初始化顺序本质是**依赖图的深度优先后序遍历**：子包 init 总在父包 init 之前完成。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
import "net/http"会让net/http及其所有依赖包（如net、crypto/tls）的init全部执行完，才继续当前包的初始化 - 循环 import 会导致编译失败，Go 不允许
- 如果两个包互相 import，编译器报错：
import cycle not allowed，根本不会走到init阶段 - 想控制初始化时机？别靠 import 顺序，改用显式初始化函数，比如
db.Init()或config.Load()
用 init 做依赖注入安全吗？
不安全。Go 的 init 是全局、隐式、不可测试、不可重入的——它无法接收参数、不能返回错误、也不能被跳过或重试。真实项目中，依赖注入应推迟到 main 或启动函数中显式完成。
立即学习“go语言免费学习笔记（深入）”；
-
init里调sql.Open并赋值给全局*sql.DB变量？一旦 DSN 错误，程序 panic 在init阶段，连日志都难打全 - 测试时无法替换依赖（比如 mock DB），因为
init在包导入时就已执行，测试代码无法干预 - 正确做法：把初始化逻辑封装成函数，例如
NewDB(cfg Config) (*sql.DB, error)，在main中调用并检查 error - 若必须“自动注册”，可用函数变量注册表 + 显式
InitAll()，而非依赖init
真正麻烦的不是顺序本身，而是把初始化逻辑塞进 init 后，你失去了对错误传播路径、依赖生命周期和测试边界的控制。越早放弃 init 做业务初始化，项目后期维护成本越低。
