应节制使用goroutine，结合业务节奏限流；HTTP层用http.Server参数限流，子任务并发需设超时；WaitGroup适用于仅等待完成，channel适用于结果聚合，注意Add/Done配对和channel阻塞风险。
用 goroutine 启动并发任务，但别无脑加 go
新手常把每个请求都套一层 go handleRequest()，结果瞬间起几百个 goroutine，没控制、没回收、没超时，服务直接卡死或 OOM。goroutine 轻量不等于免费，它仍占栈内存（初始 2KB）、有调度开销，且大量并发会压垮下游依赖（比如数据库连接池）。
正确做法是结合业务节奏做节流：
- HTTP handler 中优先用
http.Server自带的连接数限制（MaxConnsPerHost、ReadTimeout）挡在最外层 - 真正需要并发执行子任务时（如同时查 3 个微服务），才用
go启动有限数量的 goroutine - 必须配
context.WithTimeout或context.WithCancel，防止子任务失控
sync.WaitGroup 和 chan 选哪个收集结果？
两者都能等并发任务结束，但语义和风险不同。WaitGroup 更适合“只等完成，不关心返回值”的场景；而需要汇总多个子任务结果（比如并行调三个 API 拿数据再合并），用 channel 更自然、更安全。
常见错误是 WaitGroup 使用前忘记 wg.Add(n)，或在 goroutine 里调 wg.Done() 前 panic 导致漏减 —— 这会让 wg.Wait() 永远阻塞。
立即学习“go语言免费学习笔记（深入）”；
channel 方案要注意：不带缓冲的 channel 写入会阻塞，如果某个 goroutine 失败没写入，其他成功者可能卡住。稳妥写法是配合 select + default 或带超时的 send：
results := make(chan string, 3)
for i := 0; i < 3; i++ {
go func(id int) {
result, err := fetchFromService(id)
if err != nil {
return // 不写入 channel
}
select {
case results <- result:
default: // 防止阻塞
}
}(i)
}HTTP 服务中如何避免并发导致的数据竞争？
典型坑：全局变量（如计数器 var reqCount int）被多个 goroutine 直接读写，出现脏数据或 panic。Go 编译器不会报错，但运行时行为不可预测。
解决路径很明确：
- 优先用局部变量 + 参数传递，把状态关进 goroutine 自己的 scope
- 必须共享状态时，用
sync.Mutex或sync.RWMutex（读多写少用后者） - 简单原子操作（如计数、开关）直接上
sync/atomic，比锁更快更轻量 - 绝对不要用
map作为并发写入的全局缓存 —— 即使加了锁，也要注意 map 的扩容机制不是线程安全的，建议换sync.Map或封装读写逻辑
为什么 for range 启动 goroutine 容易出 bug？
这是 Go 并发最经典的陷阱之一。写成这样：
for i := 0; i < 3; i++ {
go func() {
fmt.Println(i) // 总是输出 3 3 3
}()
}
}()
}问题在于所有 goroutine 共享同一个变量 i 的地址，循环结束时 i == 3，而 goroutine 执行时才去读 —— 读到的全是最终值。
修复方法只有两个有效解：
- 把变量作为参数传进 goroutine：
go func(val int) { fmt.Println(val) }(i) - 在循环内定义新变量：
for i := 0; i
别依赖 IDE 自动修复或“应该没问题”的直觉 —— 这类 bug 在压测时才暴露，且极难复现。
并发不是加几个 go 就完事，关键在边界控制、状态隔离和错误传播。越早把 context、channel、sync 工具用对，后期排查 CPU 爆高、连接堆积、数据错乱的成本就越低。
