协程池控制并发数量防goroutine泛滥，推荐ants等库；池大小设CPU核数×2～4并压测调优；耗时操作异步入池；独立子任务用errgroup并发调用并设超时；channel+select实现非阻塞结果聚合；sync.Pool复用对象减GC；异步任务必传context、打点监控、重试+死信。
用协程池控制并发数量，避免 goroutine 泛滥
Go 的 goroutine 轻量，但不加限制地大量启动（比如每请求起一个）会导致调度开销上升、内存占用激增，甚至触发 GC 频繁，反而拖慢响应。协程池本质是复用一组固定数量的 worker，把任务排队交由它们处理，既保吞吐又稳延迟。
- 推荐使用成熟的库如 panjf2000/ants 或 v2ray/go-syncpool，避免手写易出错的调度逻辑
- 池大小不是越大越好：通常设为 CPU 核数 × 2～4，再结合压测调整；若任务含 I/O 等待，可适当放宽
- 对耗时长、非关键路径的操作（
如日志上报、埋点写入）优先丢进池中异步执行，主请求流不等待
把真正可并行的子任务拆出来，并发调用
单个 HTTP 请求常需查多个后端服务（DB、Redis、其他 API），串行调用是延迟累加器。只要这些调用相互独立，就该用 goroutine + waitgroup 或 errgroup 并发发起。
- 用 errgroup.WithContext 替代裸写 wg，自动传播取消信号和首个错误，防止 goroutine 泄漏
- 为每个子调用设独立超时（如 context.WithTimeout），避免一个慢依赖拖垮整条链路
- 注意数据竞争：并发读写同一变量必须加锁或改用 channel 通信，别依赖“它应该不会同时写”
用 channel + select 实现非阻塞任务分发与结果聚合
当需要组合多个异步来源（如缓存、DB、远程服务）的结果，且允许部分失败或降级时，channel 是比单纯等全部完成更灵活的选择。
- 为每个子任务启一个 goroutine，写结果到同一 channel；主协程用 select + timeout 控制最大等待时间
- 配合 default 分支实现“有就取，没就跳过”，适合做兜底或快速响应
- 用 sync.Pool 复用 channel 或结构体实例，减少高频分配带来的 GC 压力
异步任务要带上下文传递和可观测性
一旦任务脱离主请求生命周期，就容易变成黑盒：谁触发的？超时了吗？失败了有没有告警？这些问题不解决，延迟优化会变成“看不见的坑”。
- 所有异步任务必须接收 context.Context，并在任务开始时用 ctx.Value 或显式字段传入 traceID、userID 等关键标识
- 记录异步任务的启动时间、耗时、错误类型，打点到 metrics（如 Prometheus）或日志系统，便于定位慢任务源头
- 对重要异步操作（如扣库存、发消息）考虑加简单重试 + 指数退避，失败后投递到死信队列供人工干预
基本上就这些。协程池管数量，并发调用省时间，channel 选策略，context 和监控保可观测——四者配合，Web 接口 P95 延迟通常能稳稳往下压一截。
如日志上报、埋点写入）优先丢进池中异步执行，主请求流不等待