Go中_仅用于赋值、import和range等特定上下文，可忽略明确类型且无副作用的返回值（如非error值），但error不可丢弃；import _仅限依赖init()的包；_非标识符，不能用于变量/结构体/参数声明，过度使用会掩盖错误。
Go里用_忽略返回值，但不是所有地方都能随便写
函数返回多个值时，_确实能帮你跳过不想用的那些，但编译器只允许你“忽略”**明确声明了类型且可被安全丢弃**的值。比如strconv.Atoi返回(int, error)，你可以写_, err := strconv.Atoi("123")；但如果函数返回的是(string, string)，两个都是string，你写_, s := f()就合法，写_, _ := f()也合法——但一旦其中一个是error或接口类型，而你又没接住它，Go 就会报error must be handled这类错。
常见错误现象：_, _ = someFunc()看似省事，实际触发assignment to blank identifier警告（某些版本直接报错）；更隐蔽的是if _, err := doSomething(); err != nil { ... }——这里_绑定了第一个返回值，但如果你本意是检查第二个，却误以为第一个是error，逻辑就反了。
- 只在明确知道被忽略的值不参与错误处理、资源释放或状态流转时才用
_ - 多返回值中含
error时，_只能用于非error位置；error本身不能被_吞掉（除非你真不需要它，且函数文档确认无副作用） - 别用
_代替注释，比如_, statusCode := http.Get(...)不如写成resp, _ := http.Get(...)再取resp.StatusCode，语义更清
导入包只为了执行init()，必须用_前缀
像database/sql注册驱动、net/http/pprof启用调试端点，这些包本身没导出函数，全靠init()完成注册。这时候你不能写import "net/http/pprof"，Go 会报imported and not used；必须写成import _ "net/http/pprof"，告诉编译器：“我知道这包没显式调用，但我需要它的初始化副作用。”
使用场景很窄：仅限那些设计上就只靠init()生效的包。不是所有包都适用，比如fmt、os这种有导出函数的，加_反而让你没法用它们的API。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 确认该包文档是否明确写了“import for side effects”或类似提示
- 别对
go.mod里已存在的依赖包盲目加_前缀，可能破坏构建链（例如某些工具链依赖包名推导） - 如果一个包同时提供API和
init()副作用（如github.com/gorilla/handlers），加_会彻底屏蔽其导出符号，得不偿失
_不能用于变量重声明，也不能在结构体字段里出现
Go 不允许把_当普通标识符用。你不能写var _ int = 42，也不能在结构体定义里写type T struct { _ int }——这两者都会触发blank identifier in declaration错误。因为_在语法层面不是“变量名”，而是专门用于匹配和丢弃的占位符，只出现在赋值左侧、range、import这些特定上下文中。
容易踩的坑是复制粘贴代码时顺手把变量名改成了_，比如原本for i, v := range xs { use(i, v) }改成for _, v := range xs { use(v) }没问题，但要是写成for _, _ := range xs，虽然语法通过，可读性归零，而且掩盖了你其实想用索引做点什么的意图。
-
range里双_虽合法，但应避免——除非你真的一行都不需要，连长度都不关心 - 函数参数列表里不能用
_占位，比如func f(_, _ int) {}是非法的；必须写真实参数名或直接删掉参数 - 接收者声明也不支持
_，func (_ T) M() {}会报错，哪怕你只是想忽略接收者名字
性能和兼容性上，_几乎没开销，但过度使用会让静态分析失效
编译器对_的处理非常轻量，不会生成任何运行时代码，也不会影响二进制大小。但它会影响工具链行为：比如go vet默认会警告未使用的变量，但遇到_就直接跳过；staticcheck也不会对_绑定的值做空指针/越界等检查。
这意味着，如果你用_接住一个可能为nil的接口或指针，然后在后续逻辑里直接解引用，工具根本不会提醒你——错误要等到运行时才暴露。
- 别用
_掩盖潜在问题，比如_, data := json.Marshal(obj); _ = data，这等于主动放弃序列化失败的感知 - CI流程中若启用了
errcheck，它会强制要求所有error被显式检查，此时_不能用于error位置（除非你用errcheck -ignore ...白名单绕过） - Go 1.21+ 对
_在type alias中的限制更严，比如type _ = int现在直接非法
真正麻烦的从来不是_本身，而是人看到它就松懈——以为“反正不重要”，结果漏掉关键路径上的状态判断或资源清理。
