匿名包导入（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 链。
立即学习“go语言免费学习笔记（深入）”；
- 不是所有框架都这样设计；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 _，而是当它没起作用时，你得翻三遍文档、两遍源码、再查一遍构建环境变量。
