Go匿名函数捕获的是变量引用而非值，for循环中所有goroutine共享同一变量地址，导致输出终值；正确做法是每次迭代传参（go func(val int){}(i)）或创建局部副本（i := i）。
为什么不能直接用 go func() {...}() 启动匿名 Goroutine
看似最简写法，但常因变量捕获问题导致意料外行为。比如循环中启动多个 Goroutine 时，i 变量被所有闭包共享，最终可能全部打印同一个值。
根本原因是 Go 的匿名函数捕获的是变量的引用，不是值 —— 尤其在 for 循环中，i 是单个变量，每次迭代只是改它的值。
实操建议：
- 循环内启动 Goroutine 时，显式传参：用
go func(val int) { ... }(i)把当前值拷贝进去 - 避免在闭包里直接读取循环变量（如
go func() { fmt.Println(i) }()） - 如果必须用闭包捕获，确保该变量生命周期与 Goroutine 匹配，否则可能访问已失效内存（虽不常见，但在指针或切片操作中需警惕）
如何安全地在 HTTP handler 中启动匿名 Goroutine 处理耗时任务
HTTP handler 函数返回即响应结束，若 Goroutine 依赖 http.ResponseWriter 或 *http.Request，会 panic：http: response.WriteHeader on hijacked connection 或 use of closed network connection。
实操建议：
- 只传入与请求无关的数据（如日志 ID、数据库记录 ID），不要传
w或r - 需要记录状态？用独立 channel 或 sync.Map 记录结果，由主协程/定时任务消费
- 若必须反馈结果，改用异步回调（如发消息到 Kafka）或轮询接口，而非尝试写回原响应
- 示例：
go func(id string, payload []byte) { processAsync(id, payload) }(reqID, data)
go func() {...}() 和 go func(x T) {...}(x) 的性能差异在哪
两者编译后生成的代码几乎一致，性能差别可忽略。真正影响性能的是闭包捕获的内容大小和逃逸分析结果。
实操建议：
- 捕获大结构体或切片（尤其是未限定长度的
[]byte）会导致堆分配，增加 GC 压力 - 用
go tool compile -S检查是否逃逸：若看到main.func1 STEXT size...后有MOVQ AX, (SP)类堆写入，说明闭包变量逃逸 - 优先按需传参，而不是“为了简洁”捕获整个 struct；例如传
user.ID而非user - 注意：即使只捕获一个 int，只要闭包本身被长期持有（如注册到全局 map），该 int 也会随闭包一起留在堆上
匿名 Goroutine 中 panic 了怎么办
默认情况下，Goroutine 内 panic 不会传播到主 goroutine，也不会终止程序，但会丢失错误信息 —— 这是生产环境最隐蔽的故障源之一。
实操建议：
- 永远为关键匿名 Goroutine 加 recover：用
defer func() { if r := recover(); r != nil { log.Printf("panic in goroutine: %v", r) } }() - 不要裸写
go func() { ... }()，尤其在核心业务路径中 - 若需向调用方传递错误，改用 channel 返回 error（如
errCh ），并确保接收方有超时或 select 处理 - 第三方库如
errgroup.Group可统一管理多个 Goroutine 的 panic 和 cancel，比手写更可靠
匿名 Goroutine 看似轻量，但变量捕获、生命周期、错误处理这三点一旦疏忽，调试成本远高于多写两行传参代码。
