golang并发任务怎么做

直接甩一堆 go f() 去启动并发任务？大概率会出问题——语法上没错，但系统资源很容易失控。内存暴涨、下游服务返回429、runtime: out of memory 或者满屏的 context.DeadlineExceeded 错误，都是常见后果。更头疼的是，日志里往往找不到到底是哪批任务捅的篓子。

用 semaphore.Weighted 控制最大并发数

别自己手写计数器或者用 sync.Mutex 硬扛了。官方库 golang.org/x/sync/semaphore 提供的 Weighted 信号量，天然支持带 context 的获取和超时机制，用起来更安全可靠。

• sem := semaphore.NewWeighted(8) 这行代码，就限定了最多只能有8个任务同时执行。
• 每个 goroutine 在开始干活前，必须先调用 sem.Acquire(ctx, 1) 拿到“通行证”。如果获取失败（比如超时或被取消），任务就该跳过或安排重试。
• 对应的 defer sem.Release(1) 必须成对出现，而且务必放在 defer 里——这是确保即使任务 panic 了，资源也能被释放的唯一合理位置。
• 注意，Acquire 得放在 goroutine 内部调用。如果放在外面，那就退化成串行执行了，失去了并发的意义。
• 不过，信号量只管“放行”，不负责“排队”。如果任务耗时差异巨大（有的100ms，有的5秒），光靠信号量可能不够，这时候就需要引入缓冲队列来平滑处理了。

用 chan Task + worker pool 实现排队与复用

当突发流量远超系统的瞬时处理能力时，你需要一个缓冲区来暂存请求，避免调用方被阻塞或者请求被直接丢弃。这就是 worker pool 模式的用武之地。

• 可以定义一个任务结构体，比如 type Task struct { ID string; Fn func() }。任务输入通道建议带上缓冲：jobs := make(chan Task, 100)。
• 启动固定数量的 worker：for i := 0; i
• 提交任务时，使用 select 语句可以防止生产者被无限阻塞：select { case jobs
• Worker 内部必须时刻检查 ctx.Done()，尤其是在执行 HTTP 请求、数据库查询这类可能阻塞的操作时，以便及时响应取消信号。
• 最后别忘了，在所有任务提交完毕后，需要 close(jobs) 来通知 worker 们优雅退出，否则 for range jobs 这个循环会永远等下去。

用 errgroup.Group 统一处理错误与取消

sync.WaitGroup 只管等待任务完成，不处理错误。而 errgroup.Group 则更进一步，它天然支持“一个出错，全体取消”的语义，并且能自动与 context 进行集成。

• 初始化可以这样写：g, ctx := errgroup.WithContext(context.WithTimeout(context.Background(), 30*time.Second))，这样所有任务都共享一个带超时的上下文。
• 提交任务变得非常简单：g.Go(func() error { return process(ctx, task) })，无需再手动调用 wg.Add 和 wg.Done。
• 等待所有任务结束并获取错误：if err := g.Wait(); err != nil，它会返回第一个非 nil 的错误。
• 这里有个关键细节：任务函数内部必须主动去响应 ctx.Err()。例如，发起 HTTP 请求时应该使用 http.NewRequestWithContext(ctx, ...)。
• 注意，不要把 g.Go 再套进另一个裸的 go 语句里，因为它并不会递归地管理你内部启动的子 goroutine。

结果收集要保序、防竞态、不丢错

goroutine 的执行完成顺序是不确定的，所以不能指望它们按启动顺序把结果写进同一个 slice。另外，闭包捕获循环变量 i 是个经典的高频翻车点。

• 结果结构体最好包含原始索引：type Result struct { Index int; Data interface{}; Err error }。
• 用于收集结果的 channel 应该带缓冲：results := make(chan Result, len(tasks))。
• 每个 goroutine 结束后，向这个 channel 发送一次结果：results
• 主 goroutine 循环接收固定次数（len(tasks)），然后根据结果中的 Index 字段，将结果填回到最终的结果切片中，这样就保证了顺序。
• 传递参数时，要避免闭包共享变量：应该用 go func(idx int, task Task) { ... }(i, task)，而不是在闭包内部直接引用外部循环变量 i。

说到底，在 Go 里实现并发，真正难的不是“怎么让代码跑起来”，而是如何精细地控制“谁该先跑、能跑多久、失败了怎么通知队友、超时了如何优雅收尾”。这些细节，但凡漏掉一个，很可能就在某个凌晨三点的压测中，变成刺耳的告警铃声。