init()函数不能依赖执行顺序，因为Go不保证不同包间init()的调用顺序，仅保证同包内按源码顺序执行；跨包依赖易因构建环境或模块变化而失败，应改用显式Init函数、sync.Once懒初始化等方式控制。
为什么 init() 函数不能依赖执行顺序
Go 的 init() 函数在包导入时自动执行，但 Go 规范明确不保证不同包间 init() 的执行顺序——只保证同一个包内多个 init() 按源码出现顺序执行。这意味着：如果你在 pkgA 和 pkgB 中各自用 init() 初始化全局变量，且 pkgB 依赖 pkgA 初始化后的状态，这种依赖大概率会失败，尤其在跨模块（replace、多级依赖）或并行构建时更不可靠。
用显式 Init 函数替代隐式 init()
把初始化逻辑从 init() 拆出来，封装成带返回值的导出函数（如 Init() 或 Setup()），由主程序统一调用。这是最可控、最易测试的方式。
-
Init()应返回error，便于链式校验和提前退出 - 所有依赖项（如配置加载、DB 连接、日志实例）必须作为参数传入，避免隐式全局依赖
- 不要在
Init()内部再次调用其他包的init()—— 那等于退回原问题
示例：
// config/config.go
var Config *ConfigStruct
<p>func Init(cfgPath string) error {
c, err := loadFromYAML(cfgPath)
if err != nil {
return err
}
Config = c
return nil
}</p><p>// main.go
func main() {
if err := config.Init("./config.yaml"); err != nil {
log.Fatal(err)
}
if err := db.Init(config.Config.DB); err != nil {
log.Fatal(err)
}
// ... 其他初始化
}
用 sync.Once + lazy init 控制单次初始化时机
对真正需要“首次访问才初始化”的全局变量（比如 HTTP client、缓存实例），用 sync.Once 封装，而不是在包级变量声明时直接初始化。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免程序启动时无谓开销（例如未用到 DB 却连了库）
- 规避初始化顺序争用：只要首次调用者完成初始化，后续并发调用都安全等待
- 注意：不能用于有强依赖关系的初始化链（比如必须先读配置再建 client），这类仍需显式顺序调用
示例：
var (
httpClient *http.Client
once sync.Once
)
<p>func GetHTTPClient() <em>http.Client {
once.Do(func() {
httpClient = &http.Client{
Timeout: 30 </em> time.Second,
}
})
return httpClient
}
模块初始化顺序被破坏的典型信号
以下现象往往说明你已掉进隐式初始化顺序陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 本地运行正常，CI 构建或 Docker 镜像中 panic：nil pointer dereference（某全局变量未初始化）
- 加了
go mod graph发现依赖路径变化后行为异常 - 单元测试单独跑通过，但集成测试失败，且错误出现在某个包的
init()里 - 使用
go run main.go和go build && ./binary行为不一致
遇到这些，别猜，直接 grep 所有 func init()，逐个替换为显式初始化函数，并在 main() 或应用启动器里按 DAG 顺序排列调用——顺序不是靠运气，是靠人写清楚的。
