import _ "xxx" 是为触发包的 init() 函数执行而非使用其导出符号，典型用于数据库驱动注册和 pprof 路由注册等副作用场景，不加下划线会因未使用报错，加下划线后无法访问导出名但确保 init 仅执行一次。
import _ "xxx" 是在触发包的 init() 函数
Go 中 import _ "net/http/pprof" 这种写法，不是为了引用包里的任何导出符号，纯粹是为了让编译器加载该包、执行它的 init() 函数。比如 pprof 包的 init() 会自动注册 HTTP 路由，sql 驱动包（如 _ "github.com/lib/pq"）会调用 sql.Register() 把驱动注册进全局 registry。
- 不加下划线直接
import "net/http/pprof"会被 Go 工具链判定为“未使用”，报错imported and not used - 加下划线后，包仍会被编译进二进制，但无法访问其任何导出名（
pprof.Handler这类会报 undefined） - 多个
init()按导入顺序执行，但同一包多次import _不会重复执行（Go 保证每个包的init()只运行一次）
哪些包必须用 import _ 才能生效
典型场景是“副作用注册型”包：它们不提供接口，只靠 init() 完成关键绑定。最常见的是数据库驱动和调试工具。
-
database/sql本身不实现驱动，依赖第三方包在init()中调用sql.Register("postgres", &Driver{})；没import _ "github.com/lib/pq"，sql.Open("postgres", ...)会 panic：sql: unknown driver "postgres" -
net/http/pprof的init()自动调用http.HandleFunc("/debug/pprof/", ...)；不带下划线导入，路由不会注册 - 自定义日志钩子、全局中间件注册器等内部包，也常设计成靠
init()注入行为
import _ 的常见错误和排查方法
现象往往是“功能没起作用”，但编译通过、运行无报错，容易卡住很久。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 拼写错误：比如
import _ "githib.com/lib/pq"（少了个 u），包根本没加载，sql.Open直接失败，但错误信息里不会提示“驱动未注册”，只会说 driver name 不存在 - 版本不匹配：新旧版驱动包的
init()注册逻辑可能不同，比如pgx/v5推荐用import "github.com/jackc/pgx/v5/pgxpool"而非import _ "github.com/jackc/pgx/v5"，后者可能不注册驱动 - 条件编译干扰：如果包里有
//go:build !windows，而你在 Windows 下import _，该包实际不会被编译，init()自然不执行
替代方案与什么时候不该用 import _
不是所有“想执行 init”都该用下划线。它本质是隐藏依赖，可读性和可维护性较差。
立即学习“go语言免费学习笔记（深入）”；
- 显式调用更清晰：比如
pprof功能，可以不用import _，改用http.HandleFunc("/debug/pprof/", pprof.Index)手动注册，控制力更强 - 测试时易出问题：某些包的
init()会启动后台 goroutine 或监听端口，导致单元测试并发失败或端口冲突；这时应避免import _，改用按需初始化 - 构建体积：即使只用下划线导入，整个包及其依赖都会打进二进制，对嵌入式或 CLI 工具可能是冗余开销
真正需要 import _ 的地方其实不多，核心就两条：一是标准库约定（如 SQL 驱动、pprof），二是你明确知道某个包的设计意图就是靠 init() 注入全局行为。其他时候，优先考虑显式初始化——毕竟代码是写给人看的，顺便给机器执行。
