关闭channel能向所有阻塞接收者广播通知并立即唤醒，使ok=false明确标识流结束；而发特殊值需约定、易混淆、无法区分正常数据与终止信号，且不能唤醒全部阻塞goroutine。
为什么用 channel 关闭做广播，而不是发一个特殊值
因为 close(ch) 会向所有阻塞在 上的 goroutine 立即返回零值并解除阻塞，且这个行为是原子、无竞态、无需额外同步的。而发送一个“退出信号”值（比如 <code>-1 或 nil）需要所有接收方主动判断、约定语义，还容易漏判或误判——尤其在多个 goroutine 同时监听同一 channel 时。
更关键的是：关闭 channel 后，后续任何 都不会阻塞，而是立刻返回零值 + <code>false（如果用双赋值），这天然适合作为“终止通知”的统一出口。
如何安全地用 close() 广播退出信号
必须严格遵循“谁创建，谁关闭”原则。通常只有**单一生产者**或**协调者 goroutine** 负责关闭 channel；所有消费者只读、不关。否则会 panic：panic: close of closed channel 或 panic: send on closed channel。
- 正确做法：用一个独立的
done chan struct{}作为广播通道，所有 worker 都监听它，主逻辑在该关时调用close(done) - 错误做法：让多个 worker 都尝试
close(done)，或在for range ch循环里误调close(ch) - 注意：
struct{}类型零值不占内存，适合纯信号场景，避免传输冗余数据
select + done 是最常用的监听模式
worker 必须在循环中用 select 同时监听任务 channel 和 done channel，否则可能错过关闭信号——比如正在处理耗时任务时，done 关了，但 goroutine 还卡在 job := 上没响应。
示例结构：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
func worker(jobs <p>这里两个 <code>case</code> 是平等竞争的，只要 <code>done</code> 关闭，<code> 就立即就绪，goroutine 能即时退出，不会被任务 channel 卡住。</code></p><h3>广播后如何确保所有 worker 真正退出</h3><p>关闭 <code>done</code> 只是发信号，不等待 worker 结束。若需确认全部退出，得配合 <code>sync.WaitGroup</code>：</p>
- 启动 worker 前
wg.Add(1) - 每个 worker 在
return前调用wg.Done() - 主 goroutine 调用
close(done)后，再wg.Wait()
别用 time.Sleep 等待——它不可靠，既可能过长拖慢 shutdown，也可能过短导致 worker 还没退出就继续执行后续逻辑。
真正容易被忽略的点是：done channel 必须在所有 worker 启动**之后**才可能被关闭；如果提前关了，部分 worker 还没开始监听，就会直接跳过 case ，陷入无限等待任务 channel 的状态。
