init函数在main前执行，但晚于包级变量初始化；顺序为：包级变量→依赖包init→当前包init→main；同一包内按文件名字典序执行init函数。
init函数执行时机：比main早，但晚于包级变量
init 函数在 Go 程序启动时自动执行，严格发生在 main 函数之前，但它**不是初始化的第一步**。真实顺序是：包级变量初始化 → 所有依赖包的 <code>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 工具中容易踩坑。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
-
读取未就绪的环境变量或命令行参数：比如在
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 在本地跑十次都过，压测时才随机崩溃。
