goroutine数量需依任务类型而定：CPU密集型任务应控制在runtime.NumCPU()附近，避免调度开销；IO密集型任务可设几十至数百，但须配超时与连接池。
goroutine 数量不是越多越好，得看任务类型
CPU 密集型任务（比如图像缩放、加密计算）盲目增加 goroutine 不仅不提速，反而因调度开销和上下文切换拖慢整体吞吐。IO 密集型任务（如 HTTP 请求、数据库查询、文件读写）才真正受益于并发——大部分时间在等响应，goroutine 可让出 P，让其他任务运行。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.NumCPU()作为 CPU 密集任务的 goroutine 上限参考，再结合压测微调 - IO 密集任务可设为几十到几百个，但必须配合超时控制和连接池（如
http.Client.Transport.MaxIdleConns） - 避免用
for i := 0; i 启动裸 goroutine，i 变量易被闭包捕获成相同值 → 改用go f(i)前显式传参或用let i = i方式捕获
任务拆分要匹配数据边界，别切碎了再拼
把一个大数组按索引均分给多个 goroutine 处理很常见，但若每个子任务仍需访问全局状态（如共享 map、计数器），就会引入锁竞争，吞吐反而下降。真正的“可并行”是数据无依赖、结果可合并。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先按数据域拆分：比如处理 10 万条日志，按
log.Level或log.ServiceName分组，每组独立聚合，最后 merge 结果 - 避免“为并发而并发”：若原始任务是单次 DB
INSERT INTO ... VALUES (...), (...), (...)，拆成 100 个单行INSERT并发执行，大概率比批量插入慢 3–5 倍 - 用
sync.Pool缓存高频分配的小对象（如 JSON 解析用的bytes.Buffer），减少 GC 压力对吞吐的隐性影响
用 errgroup.Group 统一管控并发生命周期
手动写 sync.WaitGroup + chan error 容易漏 wg.Done() 或没处理 panic，导致主 goroutine 永久阻塞或错误静默丢失。标准库 errgroup.Group 自动处理取消、错误传播和等待，更贴近生产需求。
示例：并发拉取多个 API 并保证任一失败即中止
g := new(errgroup.Group)
g.SetLimit(10) // 限制最大并发数
for _, url := range urls {
url := url // 避免闭包引用
g.Go(func() error {
resp, err := http.Get(url)
if err != nil {
return err
}
defer resp.Body.Close()
// 处理 resp...
return nil
})
}
if err := g.Wait(); err != nil {
log.Fatal(err) // 任意一个 goroutine 返回 error，Wait 就返回它
}
注意：g.SetLimit(n) 是软限制，适合 IO 任务控流；CPU 密集任务应靠 worker pool 控制实际并行度，而非单纯限 goroutine 数。
别忽略 context 超时与取消的穿透性
并发任务里某个 goroutine 卡住（比如下游服务 hang 住），若没透传 context.Context，整个流程就无法响应超时或外部中断，变成“幽灵 goroutine”。所有阻塞操作（http.Do、time.Sleep、channel receive）都该支持 cancel。
实操要点：
- 启动 goroutine 时传入带 timeout 的
ctx：如ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second) - HTTP 请求必须用
http.NewRequestWithContext(ctx, ...)，不能只靠client.Timeout，后者不中断 DNS 查询或 TLS 握手 - 自定义 channel 操作可用
select { case v := - worker pool 场景下，
ctx.Done()应能快速通知所有空闲 worker 退出，避免新任务被丢弃却无人感知
最常被忽略的是：在 goroutine 内部调用了第三方库函数，而该函数不接受 context.Context —— 这时候要么换库，要么用 time.AfterFunc + panic 强制中断（不推荐），或重构为可中断的轮询逻辑。
