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