闭包引用循环变量会导致所有goroutine操作同一变量副本，因for range复用变量地址；应显式传参切断隐式引用，如go func(v T) { ... }(v)。
select 里闭包引用循环变量会出什么问题
闭包在 select 的 case 分支中捕获循环变量（比如 for range 的 v 或索引 i），大概率导致所有 goroutine 都操作同一个变量副本——不是你预期的那个“当前轮次”的值。
典型现象：启动多个 goroutine 处理不同 channel，结果全发到了最后一个 channel；或者日志打印全是同一份数据；甚至 panic：send on closed channel 因为关掉的其实是最后一个。
- 根本原因：Go 中
for range复用变量地址，每次迭代只更新值，不新建变量；闭包捕获的是变量地址，不是值 - 闭包在
select里常出现在go func() { ... }()内部，而这个函数体又引用了循环变量 - 哪怕你在
case里写了go func(v T) { ... }(v)，如果外面没及时传参，还是捕获外部变量
怎么安全地在 select 循环中启动 goroutine
必须切断闭包对循环变量的隐式引用，让每个 goroutine 拿到自己那一份独立拷贝。
- 显式传参：在
go func()启动时，把当前轮次的变量作为参数传进去，例如go func(ch chan - 用局部变量绑定：在循环体内先声明新变量，再闭包引用它，例如
val := v; go func() { select { case ch - 避免在
select外层直接写go func() { ... }()并引用i、v等循环变量 - 如果用
gorilla/websocket或net/http的 handler 做类似事，同样适用——闭包捕获的是栈上复用的变量，不是快照
为什么 defer + select + 闭包也容易翻车
defer 在函数返回前执行，但它捕获的仍是循环变量的最终值，尤其当 defer 被放在循环内、又依赖 select 状态时，行为极难预测。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 常见错误：在
for里写defer close(ch)，结果只关了最后一个ch - 更隐蔽的是
defer func() { select { case —— 如果 <code>done是循环变量，defer 实际监听的可能是已被覆盖的 channel - 解决方法统一：要么提前复制变量（
chCopy := ch; defer close(chCopy)），要么把 defer 拆到独立函数里并传参 - 注意：
defer不是“注册回调”，它是把语句压入栈，执行时取的是当时变量的当前值
调试这类问题的实用技巧
这类 bug 不报错、不 crash，只逻辑错，靠 print 很难定位——因为 print 本身会改变调度顺序，掩盖竞态。
- 加
-race编译运行，虽然它不一定报闭包捕获问题，但能暴露变量被并发读写的情况 - 在闭包内打日志时，强制打印变量地址：
fmt.Printf("val=%p, value=%d\n", &v, v)，看是不是所有 goroutine 打印同一个地址 - 用
pprof查 goroutine stack，确认哪些 goroutine 共享了同一段闭包代码路径 - 把疑似有问题的循环提取成独立函数，参数显式声明，强迫自己面对“谁传进来、谁被闭包捕获”这个问题
最麻烦的地方在于：代码看着完全合法，编译通过，运行也不 panic，只是结果不对。这种“静默错”比 crash 更耗时间——因为你会先怀疑业务逻辑，而不是语言机制。
