匿名包导入与Side Effect，Go框架初始化详解

匿名包导入（import _）的真实作用是强制触发包的 init() 函数执行，确保其副作用（如驱动注册、全局状态修改）发生，而非简单“导入不用”。

什么是匿名包导入（import _）的真实作用

它不是“导入但不用”，而是强制触发包的 init() 函数执行，仅此而已。Go 编译器会跳过未被直接引用的包，但只要写了 import _ "xxx"，就保证该包的 init() 被调用——哪怕它没导出任何符号。

常见错误现象：database/sql 注册驱动时报 sql: unknown driver "mysql" (forgotten import?)，本质就是忘了用 import _ "github.com/go-sql-driver/mysql" 触发驱动注册逻辑。

• 必须在 main 包或某个被主程序实际引用的包中执行，否则编译器可能优化掉整个包
• 多个匿名导入顺序不确定，init() 执行顺序按包依赖拓扑排序，不按 import 行序
• 如果包的 init() 有副作用（比如改全局变量、启动 goroutine、打开文件），这些都会发生，且不可撤回

框架初始化为什么依赖 _import（如 Gin、Echo 的中间件注册）

某些框架或插件选择把初始化逻辑塞进 init()，靠匿名导入“自动激活”。典型例子是 github.com/gin-contrib/cors 的旧版用法，或一些日志钩子包。

使用场景：你不想在 main() 里手动调一堆 RegisterXXX()，希望“导入即生效”。但这其实是把控制权交给了导入顺序和 init 链。

• 不是所有框架都这样设计；Gin 本身不依赖 _import，但它的生态里有些扩展包会
• Go 1.21+ 对 init() 执行时机更严格，跨模块时若包未被显式引用，即使写了 import _ 也可能被 trim 掉（需确认 go.mod 依赖是否真正 reachable）
• 调试困难：出问题时很难定位是哪个包的 init() 搞坏了状态，尤其当多个包修改同一全局变量（比如 http.DefaultClient）

替代方案：显式初始化比 _import 更可控

把初始化从 init() 拆出来，变成普通函数，由你决定何时、如何调用。这是多数现代 Go 库推荐的做法。

例如，原写法：import _ "github.com/go-sql-driver/mysql" → 改为显式注册：sql.Register("mysql", &MySQLDriver{})（虽然 driver 本身仍需 init，但至少你能控制注册时机）。

• 测试友好：可跳过初始化、或替换 mock 实现
• 避免隐式依赖：别人读你的 main.go 就能看清哪些组件被启用了
• 参数可配：init() 无法传参，而函数可以接受配置 struct、context 或选项函数
• 错误可捕获：显式调用能返回 error，init() 出错只会 panic 或静默失败

容易被忽略的兼容性陷阱

import _ 看似简单，但跨 Go 版本、跨构建模式（如 GOOS=js、cgo 开关）、跨模块 vendor 时，行为可能不一致。

常见错误现象：本地跑得好，CI 构建失败，报错 undefined: sql.Register 或驱动未注册；或者启用 -buildmode=plugin 后匿名导入失效。

• 确保目标包确实包含 init() 且没有被 build tag 排除（比如 // +build !windows）
• 使用 go list -f '{{.Deps}}' . 检查该包是否真的出现在依赖图中
• 如果包同时提供 init() 和显式 Setup() 函数，优先用后者——前者往往是为兼容老代码保留的

真正麻烦的从来不是写一行 import _，而是当它没起作用时，你得翻三遍文档、两遍源码、再查一遍构建环境变量。