空白导入（_ "path/to/pkg"）会触发包的init()函数执行，因其强制编译器加载并初始化该包；init()按依赖顺序且仅执行一次，多个时按文件字典序执行。
Blank import 为什么能触发 init 函数
空白导入（_ "path/to/pkg"）本身不引入任何标识符，但它会强制 Go 编译器加载并初始化该包——只要这个包里有 init() 函数，它就会被执行。这是 Go 初始化流程规定的：所有被直接或间接导入的包，其 init() 函数都会按依赖顺序执行一次，且仅一次。
常见错误现象：import _ "net/http/pprof" 写了却没看到 pprof 接口生效，其实是忘了启动 HTTP server；或者误以为 blank import 能“按需加载”，结果发现包初始化逻辑在 main 启动前就跑完了，导致资源提前占用、日志提前打印、甚至 panic。
- 只有包级
init()函数会被触发，不是所有函数都行 - 多个
init()函数在同一个包内，按源文件字典序执行（不是声明顺序） - 如果包从未被其他路径引用过，blank import 是唯一让它进初始化链的方式
哪些标准库靠 blank import 激活副作用
Go 标准库里明确依赖 blank import 的典型例子不多，但几个关键包确实靠它注册行为：
-
_ "net/http/pprof"：向http.DefaultServeMux注册/debug/pprof/路由，但不会自动起 server -
_ "database/sql"本身不干啥，但必须配合具体驱动如_ "github.com/mattn/go-sqlite3"才能让sql.Open("sqlite3", ...)工作 -
_ "image/png"、_ "image/jpeg"：向image.RegisterFormat注册解码器，否则image.Decode无法识别对应格式
注意：database/sql 包本身没有 init()，驱动包才有；image/* 包的 init() 只做注册，不加载文件也不解析数据。
立即学习“go语言免费学习笔记（深入）”；
自定义包中写 init() 的实际约束
自己写包时加 func init() 看似简单，但容易忽略初始化时机和并发安全问题：
- 不能在
init()里调用os.Exit()或 panic（除非你确定要让整个程序启动失败） - 不要在
init()里做耗时操作（比如读大文件、连远程服务），它会卡住整个程序启动流程 - 避免在
init()中修改全局变量的同时被其他包的init()并发读取——Go 的包初始化是单线程顺序执行的，但一旦 main 开始运行，就可能并发访问 - 如果包有可配置项（比如日志级别、超时时间），别硬编码在
init()里，应提供显式Setup()函数
示例：一个错误写法是 init() { log.SetPrefix("[mylib] "); config = loadConfig("config.yaml") } —— 文件不存在就 panic，且无法覆盖配置。
blank import 和 init() 在构建与测试中的表现差异
blank import 不代表代码一定被链接进最终二进制。如果整个包及其 init() 完全未被任何符号引用（包括反射、类型断言、接口实现检查），Go 1.20+ 的 linker 可能将其 dead code eliminate 掉。
- 单元测试中，若只测试某个子功能，且未触发相关包的 blank import 链，
init()就不会执行——这会导致测试通过但线上出问题 - 使用
//go:linkname或unsafe强制引用时，也可能绕过正常导入链，使init()被跳过 - 交叉编译或启用
-buildmode=plugin时，包初始化行为可能不一致，尤其涉及 cgo 的包
最稳妥的做法：把关键副作用逻辑从 init() 拆出来，暴露为显式函数，在 main 或测试 setup 中主动调用。
