匿名导入（import _ “pkg”）会触发包的init()函数执行，因其虽不引入导出符号，但仍参与初始化流程；典型用于数据库驱动、图像解码等注册型包。
为什么 import _ “database/sql” 会触发 init 函数
go 的匿名导入（_ 前缀）不引入包的导出符号，但会强制执行该包的 init() 函数。这是 Go 初始化机制的一部分：只要包被“导入”（无论是否匿名），且其代码被编译进最终二进制，它的 init() 就会被调用，顺序由依赖图决定。
常见错误现象：import "database/sql" 单独写却不报错，但后续调用 sql.Open("mysql", ...) 却 panic: sql: unknown driver "mysql" —— 这说明驱动没注册，而注册逻辑就藏在驱动包的 init() 里。
- 必须用
import _ "github.com/go-sql-driver/mysql"（或对应驱动）才能激活注册逻辑 -
import "database/sql"是必需的，但它本身不注册任何驱动；它只是提供接口和通用操作 - 匿名导入不会污染当前命名空间，也不会让
mysql.SomeFunc可见 —— 它只做一件事：跑init
哪些包必须用匿名导入才能生效
典型场景是“注册型包”，它们不提供可调用函数，只靠 init() 向全局注册器写入信息。最常见的是数据库驱动、编码格式、日志钩子等。
使用场景举例：
立即学习“go语言免费学习笔记（深入）”；
- 数据库驱动：
_ "github.com/lib/pq"（postgresql）、_ "github.com/mattn/go-sqlite3" - 图像解码：
_ "image/jpeg"、_ "image/png"—— 否则image.Decode无法识别对应格式 - http 路由扩展：
_ "net/http/pprof"（自动注册 /debug/pprof 路由）
注意：pprof 是个特例：它注册的是 http.DefaultServeMux 的 handler，所以即使没显式启动 HTTP server，只要导入了，后续启用时就能响应路径 —— 但前提是 http.DefaultServeMux 确实被用了。
init 执行时机与隐式依赖风险
init() 在 main() 之前运行，且按导入依赖顺序执行。如果 A 包匿名导入 B，B 的 init() 就会在 A 的 init() 之前跑。这容易引发“谁先初始化”的问题。
容易踩的坑：
- 驱动包的
init()依赖某个全局变量（比如 logger 实例），但该变量在更上层的init()中才初始化 → panic 或空指针 - 多个驱动包都注册同名方言（如两个包都调用
sql.register("sqlite3", ...)）→ 后注册的覆盖前一个，运行时报driver: registered driver not found - 测试时忘记匿名导入驱动，导致单元测试通过，集成环境失败 —— 因为测试文件可能没显式 import 驱动
性能影响几乎为零：注册动作通常只是往 map 写一个函数指针，耗时纳秒级；但过度使用（比如几十个匿名导入）会让构建依赖图变复杂，调试初始化顺序更困难。
如何验证驱动是否真的注册成功
不能只看编译是否通过，得确认注册行为确实发生。最直接的方式是在运行时查注册表。
例如检查 SQL 驱动：
for _, name := range sql.Drivers() { fmt.Println(name) // 输出类似 "mysql", "sqlite3" }如果目标驱动名不在输出中，说明匿名导入没生效，或拼写错误（比如 import _ "github.com/go-sql-driver/mysql" 写成 mysql-driver）。
其他方式：
- 加断点或日志到驱动包的
init()函数（需本地 vendor 或 replace 到可编辑路径） - 用
go list -f '{{.Deps}}' .看构建是否包含该驱动包（但不保证init被调用） - 在
main()开头立刻调用sql.Open并捕获 Error —— 这是最贴近真实使用的验证
最容易被忽略的一点：模块路径变更（比如驱动升级到 v2）可能导致 import path 不再匹配，init() 根本不会执行，而 Go 不报错 —— 它只是默默忽略未被引用的包。