必须用 for range 是因为单次接收无法感知任务结束，而 for range 会持续接收直到 channel 关闭，确保所有任务被消费完；若仅单次读取，则剩余任务将滞留且无机制通知消费者已无新任务。
goroutine 从同一 channel 并发读取任务时，为什么必须用 for range 而不是单次
因为 channel 是共享资源，多个 goroutine 同时用 尝试读取会引发竞态——但实际不会 panic，而是出现「部分 goroutine 永久阻塞」或「任务被重复消费」。根本原因在于：未关闭的 channel 上单次读取无法判断是否还有后续数据；而 <code>for range ch 会在 channel 关闭且所有已发送值被接收后自动退出循环。
常见错误现象：
- 只写
val := ，结果只有第一个 goroutine 拿到值，其余全部卡住 - 误以为「多个 goroutine 同时
就能轮询」，实则 Go 不保证公平调度，可能某一个 goroutine 持续抢到读权限
正确做法是让每个 worker 都运行一个 for range 循环，由 Go 运行时内部机制确保每个接收到的任务只被一个 goroutine 消费一次。
如何安全关闭任务 channel 并等待所有 worker 完成
关闭 taskCh 的时机和方式直接决定程序会不会死锁。关键点不是“能不能关”，而是“谁来关、什么时候关、关完怎么通知主 goroutine”。
立即学习“go语言免费学习笔记（深入）”；
- 必须由生产者（通常是 main 或提交任务的逻辑）调用
close(taskCh)，不能由 worker 调用 - worker 必须用
for task := range taskCh，而不是for { task := ，否则关 channel 后会 panic - 要用
sync.WaitGroup记录 worker 数量，并在每个 worker 的defer wg.Done()后才能保证wg.Wait()真正等待完成 - 如果还向
resultCh发送结果，记得在所有 worker 退出后再close(resultCh)，否则主 goroutinefor range resultCh会永远等不到关闭信号
带缓冲 vs 无缓冲 taskCh 对并发行为的影响
缓冲区大小不改变「任务分发的正确性」，但显著影响吞吐、内存占用和背压表现。
-
make(chan int, 0)（无缓冲）：每次taskCh 都要等到有 worker 正在 <code> 才能返回，天然限流，适合 IO 密集型任务（如 HTTP 请求），避免瞬间积压 -
make(chan int, N)（带缓冲）：发送端不会阻塞，适合 CPU 密集型预加载场景；但若N过大（比如 10000），等于把所有任务一次性 load 到内存，失去流式控制能力 - 典型折中：设为 worker 数的 2–5 倍（例如 3 个 worker 配 10 容量），既缓解生产者抖动，又不至于撑爆内存
为什么不能省略 sync.WaitGroup 直接用 for range resultCh 等待
因为 for range resultCh 只有在 resultCh 被关闭后才会退出；而关闭 resultCh 的时机必须依赖所有 worker 已经退出——这个依赖关系无法靠 channel 自身表达，必须靠外部同步原语打破循环。
- 如果只靠
for range resultCh，主 goroutine 会一直等，而 worker 因为没收到关闭信号或没被等待，可能提前退出或卡住 - 常见反模式：
go func() { wg.Wait(); close(resultCh) }()—— 这看似合理，但如果 worker 内部有 panic 或逻辑错误提前 return，wg.Wait()就永远不会返回，resultCh永远不关闭 - 真正健壮的做法：worker 全部用
defer wg.Done()，主 goroutine 调用wg.Wait()后再close(resultCh)，最后才for range resultCh
最易被忽略的一点：worker 函数签名里必须接收 *sync.WaitGroup 并显式调用 Done()；漏掉 defer 或传错指针，wg.Wait() 就永远阻塞。
