\_ 不会覆盖上一轮值，每次迭代都是全新声明的不可寻址占位符；它不保存值、不参与捕获，仅作编译期忽略信号，误用可能掩盖变量复用等真正问题。
for range 中的匿名变量 _ 会覆盖上一轮值吗
不会。每次迭代时 _ 都是全新声明的、不可寻址的临时占位符，它不保存任何值，也不参与变量捕获。你看到的“复用”只是编译器优化后的表象，实际行为完全隔离。
常见错误现象：go func() { fmt.Println(i) }() 闭包里打印出全都是最后一个 i 值——但这和 _ 无关，是循环变量复用导致的；一旦你把 i 换成 _，反而更危险：你以为丢弃了，其实可能误删了本该保留的变量名。
- 使用场景：只关心索引或只关心元素值之一，比如遍历 map 只取 key、遍历切片只处理下标
- 参数差异：
for i := range s和for _, v := range s语义不同，后者明确放弃索引，前者仍绑定i - 性能影响：无额外开销，
_不分配内存，也不生成指令
在 goroutine 闭包中用 _ 接收 range 值会引发并发 bug 吗
不会直接引发，但会掩盖真正的问题。匿名变量本身不参与闭包捕获，问题根源永远是「循环变量被复用」，而不是你写没写 _。
典型错误示例：
for _, v := range items {
go func() {
fmt.Println(v) // 这里 v 是外部变量，所有 goroutine 共享同一个 v
}()
} 这段代码无论前面是 v 还是 _，只要闭包里引用了 v，就会出错。
- 正确做法：显式传参，
go func(val string) { fmt.Println(val) }(v) - 或者用局部变量复制：
val := v; go func() { fmt.Println(val) }() - 别指望
_能帮你“断开引用”，它只影响左侧绑定，不影响右侧表达式求值
map 遍历时用 _ 忽略 value 是否影响性能或内存布局
完全不影响。Go 编译器在 for k := range m 或 for k, _ := range m 场景下，都会跳过 value 的加载和拷贝，底层调用的是仅遍历 key 的哈希表迭代路径。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：有人以为 for k, _ := range m 比 for k := range m 更“安全”，其实后者更简洁、意图更清晰；加个 _ 反而容易让人误以为你在刻意忽略什么，引发不必要的审查成本。
- 兼容性：所有 Go 版本行为一致，从 1.0 到 1.22 都如此
- 注意边界：如果 map value 是大结构体，不用
_却又不读 value，会导致无意义拷贝（虽然编译器会尝试优化，但不保证） - 真实建议：优先用
for k := range m，除非你需要同时声明两个变量但只用其中一个
defer 中引用 _ 绑定的变量会发生什么
会报错：cannot use _ as value。因为 _ 不是变量，它没有地址、不能取值、不能传递、不能出现在 defer 表达式中。
常见错误现象：想在 defer 里记录某次循环的某个字段，顺手写了 defer log.Printf("done: %v", _)，结果编译失败。
- 必须用具名变量：
id := item.ID; defer log.Printf("done: %d", id) - 不能靠
_“省事”，它只存在于赋值左侧，右侧出现就是语法错误 - 这个限制其实是好事——强迫你思考：这个值到底要不要命名？要不要保留？
