goroutine 传参需避免循环变量共享，正确做法是将循环变量作为参数传入匿名函数，而非在闭包中直接引用，否则所有 goroutine 会共享同一变量值。
go 关键字启动 goroutine 很简单，但不加控制地乱用，轻则结果错乱，重则内存泄漏、程序卡死。它不是“加个 go 就并发了”，而是要配合同步机制、传参方式、生命周期管理一起用。
goroutine 启动时怎么传参才安全？别让循环变量被所有 goroutine 共享
最常见错误：在 for 循环里直接启 goroutine 并引用循环变量，比如：
for i := 0; i < 3; i++ {
go func() {
fmt.Println(i) // 几乎总是输出 3 3 3
}()
}原因：i 是同一个地址上的变量，所有匿名函数闭包都捕获了它的地址，等 goroutine 真正执行时，循环早已结束，i == 3。
- ✅ 正确做法一（推荐）：把
i当参数显式传进去
for i := 0; i < 3; i++ {
go func(val int) {
fmt.Println(val)
}(i) // 立即传值，栈隔离明确
}- ✅ 正确做法二：在循环内定义新变量绑定当前值
for i := 0; i < 3; i++ {
i := i // 创建新变量，遮蔽外层 i
go func() {
fmt.Println(i)
}()
}怎么等 goroutine 执行完？别用 time.Sleep，它既不准也不可靠
time.Sleep 是调试玩具，生产环境必须换掉——CPU 忙时调度延迟大，可能还没执行完就跳过了；空闲时又白白多等。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- ✅ 场景一：只关心“是否完成”，不关心返回值 → 用
sync.WaitGroup
var wg sync.WaitGroup
for i := 0; i < 5; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
fmt.Printf("worker %d done\n", id)
}(i)
}
wg.Wait() // 阻塞直到所有 Done() 被调用- ✅ 场景二：要拿结果、做聚合、或控制执行顺序 → 用
chan
c := make(chan int, 2)
go func() { c <- 10 }()
go func() { c <- 20 }()
a, b := <-c, <-c // 顺序接收，自动同步channel 收发数据时有哪些硬性规则？漏 close 或类型不匹配会卡死
无缓冲 channel 默认是同步的：发送方会阻塞，直到有接收方准备好；反过来也一样。这是它能做同步的底层原理。
- ⚠️ 常见卡死：用
for range ch读 channel，但没人关它 → 永远等下一个值 - ✅ 解法：发送方全部完成后，调用
close(ch)，接收方range自动退出 - ⚠️ 类型必须严格一致：
chan int不能当chan interface{}用，也不能和混传 - ✅ 缓冲 channel（如
make(chan int, 10)）可缓解阻塞，但不解决逻辑同步问题——它只是“多存几个”，不是“不用等”
goroutine 泄漏怎么发现和避免？没回收的 goroutine 会一直占内存
goroutine 不会自动销毁，只要还在运行（比如卡在 channel 接收、死循环、没收到 context 取消信号），它就一直活着。跑着跑着几百上千个 goroutine 堆积，内存就爆了。
- ✅ 必做：所有长期运行的 goroutine 都要监听
context.Context的Done()通道 - ✅ 必做：用
sync.WaitGroup或 channel 明确标记“任务已结束”，尤其在循环启多个时 - ⚠️ 危险模式：启 goroutine 去读一个可能永远不写入的 channel；或启了却忘了
defer wg.Done() - ? 快速检查：程序运行中访问
/debug/pprof/goroutine?debug=2（需导入net/http/pprof）看 goroutine 数量是否异常增长
真正难的从来不是“怎么启 goroutine”，而是“怎么让它准时开始、正确协作、干净退出”。传参、同步、关闭、取消——这四个环节漏掉任何一个，都可能让并发变成并行灾难。
