17370845950

init函数在main前执行，但晚于包级变量初始化；顺序为：包级变量→依赖包init→当前包init→main；同一包内按文件名字典序执行init函数。

init函数执行时机：比main早，但晚于包级变量

init 函数在 Go 程序启动时自动执行，严格发生在 main 函数之前，但它**不是初始化的第一步**。真实顺序是：包级变量初始化 → 所有依赖包的 init → 当前包的 init → main

• 变量初始化按依赖关系优先：比如 var a = b + 1 和 var b = 2，b 一定先初始化
• 同一包内多个 init 函数，按所在文件名**字典序**执行（如 a.go 先于 z.go），而非源码出现顺序
• 同个文件里多个 init，按定义顺序执行——但这属于“未定义行为”的灰色地带，Go 官方不保证，**别依赖它**

跨包初始化顺序：依赖链决定执行先后

如果你的 main 包导入了 lib，而 lib 又导入了 utils，那么初始化顺序固定为：utils → lib → main。每个包内部都遵循「变量 → init」两阶段。

• 循环导入（A 导入 B，B 又导入 A）会导致编译失败，Go 构建系统会直接报错：import cycle not allowed
• 第三方库（如 github.com/go-redis/redis/v9）的 init 也会被纳入该链条，在你自己的包执行前完成
• 即使某个包被多个地方重复导入（比如 A 和 B 都 import C），C 的 init 也只执行一次

常见误用和危险操作

很多线上问题源于对 init 的滥用，尤其在微服务或 CLI 工具中容易踩坑。

• 读取未就绪的环境变量或命令行参数：比如在 init 里调用 flag.Parse() 或 os.Getenv("DB_URL") —— 此时 main 还没开始，flag 未解析，环境可能未加载完毕
• 启动 goroutine 但没等资源就绪：例如在 init 中起一个后台定时器去轮询配置中心，但此时配置客户端还没初始化完成，导致 panic 或空指针
• 耗时操作阻塞启动：网络请求、文件读写、数据库连接池 warmup 放在 init 里，会让整个进程卡住几秒，影响健康检查和容器就绪探针
• 全局状态污染：多个 init 同时修改同一个全局 map 或 sync.Pool，又没加锁，引发竞态（Go race detector 能抓到，但上线后才暴露）

替代方案：什么情况下不该用init？

当初始化逻辑需要参数、错误处理、延迟触发或可测试性时，init 就是错的选择。

• 用 sync.Once 替代复杂初始化：它是懒加载、线程安全、可显式控制时机，比如 ReadConfig() 函数内部封装 once.Do(...)
• 把初始化收口到一个函数里（如 Setup()），在 main 开头显式调用，便于单元测试 mock 和注入依赖
• 驱动注册类场景（如 database/sql.Register）确实适合 init，因为它是纯副作用、无参数、只执行一次的标准模式
• 如果必须用 init，请确保它只做三件事：设默认值、注册回调、校验常量；所有 I/O、网络、外部依赖一律后移

最易被忽略的一点：包初始化全程运行在单个

goroutine 中，看似“安全”，但一旦你在 init 里启动 goroutine 并访问尚未初始化完成的全局变量，就会触发 data race —— 这种 bug 在本地跑十次都过，压测时才随机崩溃。