不能直接 for range channel 拉消息因为其只检测通道关闭而不等待 worker 完成主 goroutine 退出会导致正在处理的 worker 被强制终止引发数据丢失或 panic必须用 sync.WaitGroup 显式管理生命周期并配合 context 控制长连接退出。为什么不能直接 for range channel 拉消息就完事因为 RabbitMQ 或 Redis 消费者拉到的消息是流式的for range 只管“通道关了没”不管“worker 是否还在处理”。主 goroutine 一退出所有正在 time.Sleep、DB 写入、HTTP 调用的 worker 全被杀掉日志只打印一半消息看似“消费了”实则丢了。常见错误现象Worker 2 processing task 7: data-7 打到一半程序静默退出或者 panic: send on closed channel 来自某个 worker 想写结果回 channel 时发现已被关闭。必须用 sync.WaitGroup 显式计数每个 worker 启动前 wg.Add(1)结束前 defer wg.Done()生产者比如 RabbitMQ 的 msgs 接收循环负责单点 close(ch)消费者只读绝不关若消费者是长连接如监听 Kafka topic就不能依赖 close得换 context.Context 控制退出batchProcessor 怎么写才不丢数据、不爆内存批量处理的核心不是“攒够 N 条就发”而是“要么全成功要么全重试”否则 ES 写一半失败、MySQL 插一半回滚状态就撕裂了。Golang 里最稳的方式是让每个 batch 在单个 goroutine 内串行执行天然避免锁竞争。使用场景RabbitMQ 消费后批量写 Elasticsearch、Redis Stream 消费后批量更新缓存、Kafka 消息聚合后触发风控规则。立即学习“go语言免费学习笔记深入”BatchSize 别硬设成 100 —— 实际要看下游吞吐ES bulk 推荐 5–20MB / request换算下来常是 500–2000 条/批MySQL 批量 INSERT 则建议 ≤ 1000 行超时控制必须用 time.Timer别用 time.After后者在 select 循环里会持续创建新 timer导致 goroutine 和内存泄露每批处理完要手动 AckRabbitMQ或 XAckRedis Stream不能靠自动确认——否则处理失败时消息已丢prefetch count 和 Workers 数怎么配才不堆积RabbitMQ 的 prefetch count 和 Golang 里的 Workers 数量不是一回事但协同不好就会一边疯狂积压 Ready 消息一边 Unacked 卡死一堆。 Tellers AI Tellers是一款自动视频编辑工具可以将文本、文章或故事转换为视频。