panic: init()函数失败表示程序在执行main()前因某包init()中panic或os.Exit()而终止，常见于配置打开失败、数据库连接错误等；需用GODEBUG=inittrace=1定位问题包。
panic: init() function failed 是什么信号
这行错误不是运行时异常，而是程序根本没开始执行 main() 就卡死了。Go 在启动时会按导入顺序执行所有包的 init() 函数，只要其中任意一个 panic 或调用 os.Exit()，整个进程立刻终止，连 defer 都不会触发。
常见诱因包括：os.Open() 打开配置文件失败没处理、sql.Open() 连接字符串写错、flag.Parse() 前就访问未解析的 flag 变量、第三方库初始化时依赖环境变量但实际缺失。
关键判断：如果日志里看不到任何你写的 log.Print 或 fmt.Println 输出，十有八九是 init() 阶段崩了。
怎么快速定位哪个包的 init() 出问题
Go 不会默认打印 panic 发生在哪个包的 init() 里，得靠编译器和运行时配合排查：
立即学习“go语言免费学习笔记（深入）”；
- 加
-gcflags="all=-l"编译（禁用内联），让 panic 栈更清晰 - 运行时加
GODEBUG=inittrace=1环境变量，它会输出每个包初始化的耗时和顺序，崩溃前最后打印的那个包就是嫌疑对象 - 如果用了
go run，直接加-work看临时构建目录，再用go tool compile -S检查可疑包的汇编（极少需要，但能确认是否真进了init）
示例命令：GODEBUG=inittrace=1 ./your-binary，输出中类似 init 这样的最后一行，就是雷区。github.com/foo/bar [12ms]
init() 里哪些操作特别危险
init() 函数表面简单，实则限制极多，很多看似合理的写法都会埋雷：
- 调用可能 panic 的函数，比如
json.Unmarshal(nil, &v)、regexp.Compile(`[`)（正则语法错）
- 依赖尚未初始化的全局变量（Go 中包级变量初始化顺序严格按源码顺序，跨包不可控）
- 做阻塞 I/O：如
http.Get()、time.Sleep()—— 不仅慢，还可能因超时 panic 或死锁 - 启动 goroutine 但没做 recover：一旦 goroutine 内 panic，主进程照样挂，且栈追踪极难定位
真正安全的操作只有：纯计算、赋值常量、注册回调（如 database/sql.Register）、预编译正则（用 MustCompile 并确保字面量合法）。
如何把易错逻辑从 init() 挪出来
最稳妥的方式是“懒初始化”：把初始化逻辑封装成函数，在第一次使用时才执行，并加锁保证只跑一次。标准库的 sync.Once 就是为此设计的：
var (
db *sql.DB
once sync.Once
)
func GetDB() (*sql.DB, error) {
once.Do(func() {
var err error
db, err = sql.Open("mysql", os.Getenv("DSN"))
if err != nil {
// 这里 panic 会传播到调用方，可控
panic(err)
}
})
return db, nil
}
这样做的好处：init() 干净了；错误时机明确（谁调用谁负责）；可单元测试；支持重试或 fallback。
注意：不要在 init() 里 new 一个 sync.Once 并立即 Do——那又绕回去了。
复杂点在于，有些第三方库强制你在 init() 里注册驱动或中间件，这时只能检查它的文档，确认它内部是否做了 I/O 或是否允许延迟注册。忽略这点，迟早掉坑里。
