Worker Pool模式
Worker Pool 模式通过固定数量的工作者（Worker Goroutines）来消费任务通道中的任务，从而达到控制并发数的目的。
Worker Pool 模式适用场景：
| 应用类型 | 示例 |
|---|---|
| 网络服务 | HTTP 请求处理、代理服务器 |
| 批量任务 | 图片处理、数据转码 |
| 消息消费 | Kafka、RabbitMQ 消费者池 |
| 异步处理 | 日志收集、邮件发送 |
优点：
- 限制并发数，防止系统资源耗尽；
- 提高任务执行效率与稳定性；
- •结构清晰，便于扩展与维护。
注意事项：
- 注意关闭通道的时机，避免死锁；
- 如果任务较重，可配合
context实现取消； - 防止 Worker 泄漏或 panic 未捕获导致崩溃；
- 可加入错误通道收集失败任务。
Pipeline模式
Pipeline模式模拟了流水线的工作方式，数据像流水一样经过多个阶段的处理，每个阶段可能由不同的goroutine负责，从而实现高效的并行处理。
Pipeline 本质上是多个任务的串联，每个任务在独立的协程中运行，并通过 channel 将数据传递给下一个阶段。好处是：
- 易于解耦，每个阶段职责单一；
- 利用并发，提高处理效率；
- 易于扩展，插拔式维护。
Pipeline模式适用场景：
- 流式数据处理（如日志解析、文件读取）
- 批量任务拆分（如多任务异步处理）
- 数据转换（如JSON解析→数据清洗→存储）
优点：
- 易于解耦，每个阶段职责单一；
- 利用并发，提高处理效率；
- 易于扩展，插拔式维护。
注意事项：
- 尽可能保持职责单一；
- 注意关闭通道避免资源泄漏；
- 避免重复读取一个 channel（可以用广播或缓存）；
- 使用
context加入取消机制，控制生命周期。
Fan-out/Fan-in模式
Fan-out将一个输入通道分发给多个goroutine处理，Fan-in将多个通道合并为一个。
- Fan-out（扇出）：将任务从一个入口分发给多个 worker 并发执行。
- Fan-in（扇入）：将多个 worker 的结果汇聚到一个通道中进行统一处理。
Fan-out / Fan-in 非常适合如下场景：
- 应用场景
- 示例
- 并发抓取网页多个 URL 同时请求并聚合结果
- 批量图像处理多图片缩放或加水印
- 数据清洗与计算并发处理 CSV/日志数据
- 大量任务排队处理多任务分发并收集结果
优点：
- 利用多核并发，显著提高处理效率；
- 模块清晰，生产者-工作者-聚合器分离；
- 易于扩展和监控。
注意事项：
- 输入通道必须是“广播型”，即可被多个 worker 消费；
- 合并函数 merge 要注意关闭输出通道；
- worker 中如有异常（如 panic）应提前恢复；
- 可加 context 实现取消控制；
并发模式对比
| 模式 | 适用场景 | 优点 | 注意事项 |
|---|---|---|---|
| Worker Pool | 大量任务需要限制并发数 | 资源可控、简单高效 | 需要合理设置worker数量 |
| Pipeline | 多阶段数据处理 | 解耦、可扩展 | 注意通道关闭顺序 |
| Fan-out | 并行处理提高吞吐 | 充分利用CPU | 需要配合Fan-in使用 |
| Fan-in | 合并多个数据源 | 统一处理结果 | 注意goroutine泄漏 |
- Worker Pool：控制并发数量，适合处理大量任务
- Pipeline：多阶段流水线处理，解耦各个处理环节
- Fan-out/Fan-in：并行处理和结果汇总
- 超时控制：避免任务无限等待