热路径中for循环内直接用go func(){use(i)}()必然出错：输出全为终值、数据竞争、内存泄漏；应改用go func(idx int){use(idx)}(i)传参，避免变量复用和共享问题。
热路径里直接用 go func() { use(i) }() 必然出错
所有在 for 循环中启动 goroutine 且闭包内直接引用 i 或 v 的写法，在热路径（高频、低延迟、高并发）下会立刻暴露问题：输出全为终值、数据竞争、内存泄漏。这不是“概率低”，而是语言机制决定的必然结果——i 在整个循环中复用同一内存地址，所有闭包捕获的都是这个地址，等 goroutine 调度执行时，i 早就是 len(items) 了。
传参比变量重声明更适合热路径
虽然 i := i 和 go func(idx int) { use(idx) }(i) 都能解决问题，但在热路径中推荐后者：
-
go func(idx int) { use(idx) }(i)：参数在go语句执行瞬间求值，idx是独立栈变量，无逃逸，无额外指针间接访问，CPU cache 友好 -
i := i; go func() { use(i) }()：虽经编译器优化，但语义上仍引入新绑定，对 register allocator 和内联判断有轻微干扰；若i是大结构体，复制开销更明显 - 当需传多个值（如
i,v,ctx）时，传参天然支持，而重声明需逐个写，易漏、难维护
切片/指针/映射类变量必须显式传值或取元素地址
别信“v 是副本就安全”——只要 v 是 []byte、map[string]int、*T，闭包捕获的仍是底层共享数据：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误：
for _, v := range items { go func() { process(v) }() }→ 若v是[]byte，多个 goroutine 并发append(v, x)可能 panic - 正确：
go func(val []byte) { process(val) }(v)→ 显式传值，底层数组引用被复制，但不会意外共享修改权 - 更精确（只传必要部分）：
go func(item Item) { process(item.Name) }(items[i])→ 避免把整个大结构体拖进 goroutine 生命周期
defer 在热路径循环中要特别小心
热路径里频繁 defer 不仅可能堆积调用栈，还会因变量捕获延长资源生命周期：
立即学习“go语言免费学习笔记（深入）”；
- 错误：
for i := range files { f, _ := os.Open(files[i]); defer f.Close() }→ 所有f延迟到函数末尾才关，文件句柄堆积 - 正确：
for i := range files { f, _ := os.Open(files[i]); defer func(f *os.File) { f.Close() }(f) }→ 每次 defer 绑定当前f，且立即求值 - 更优：
for i := range files { if f, err := os.Open(files[i]); err == nil { defer f.Close(); ... } }→ 把 defer 放在资源创建后立刻写，不塞进大循环体
真正危险的不是语法写错，而是你以为“这次只是读一下 v.Name，应该没事”——只要闭包里出现任何对循环变量的引用，它就在热路径里埋了竞态和泄漏的引信。
