关闭一个channel确实能让所有接收方通过ok==false感知结束，但无法解决多生产者协同关闭的竞态问题：任一生产者提前close会引发其余生产者panic，且消费者无法区分“已关闭”和“暂无数据”，故需context.withcancel等信号机制协调。
直接说结论：用 context.WithCancel 配合 select 监听 ctx.Done()，比手动 close 通道更可靠、更易维护；但若只是两个协程点对点通知，close(ch) 简单有效，别硬套 context。
为什么不能只靠 close(ch) 通知多个协程？
关闭一个 channel 确实能让所有 操作立即返回零值，但问题在于：<strong>它无法区分“关闭”和“还没发数据”</strong>。比如：
- 多个协程同时从同一
chan struct{}接收，close(ch)后它们都退出——看似 OK，但一旦有协程漏掉select或写成if ch != nil就会 panic - 如果通道是带缓冲的，
close(ch)不会清空已存数据，后续接收仍能取到旧值，导致误判退出时机 - 无法传递取消原因（比如“超时”还是“用户中断”），只能靠额外 error channel 或全局变量补救
context.WithCancel 的正确监听姿势
不是查 ctx.Err()，也不是轮询，而是必须用 select 等待 ctx.Done() 关闭。常见错误写法：if ctx.Err() != nil { return } —— 这只能捕获已发生的错误，无法响应未来取消。
- 正确写法：
select { case - 如果 goroutine 正在做阻塞操作（如
http.Do），确保该操作支持 context（例如用http.NewRequestWithContext） - 如果操作不支持 context（如
os.ReadFile），需在循环中主动检查ctx.Err()，但仅限非阻塞场景；阻塞调用必须配合select+time.After或改用支持 context 的替代 API
什么时候该用 close(ch)？
只适用于明确的一对一或一对固定数量协程通信，且不需要超时、取消原因、嵌套传播等能力。典型场景：
- 主协程启动一个 worker，完成后发信号让它停——用
done chan struct{}，主协程close(done)，worker 中select { case - 多个协程共享一个资源（如文件句柄），最后一个使用者负责
close(file)并通过closed chan struct{}通知其他协程“别再用了” - 注意：
close(ch)只能调用一次，重复 close 会 panic；而cancel()可多次调用，后续无效但安全
嵌套 cancel 和子 context 的陷阱
子 context 的取消完全依赖父 context：父被 cancel，所有子自动 cancel；但子调用自己的 cancel() 不会影响父或其他兄弟 context。这意味着你可以为每个 HTTP handler 分配独立 context.WithTimeout，互不干扰。
- 别把不同来源的 context 混着传（比如一个来自 HTTP request，一个来自定时器），应统一以
context.Background()或context.TODO()为根派生 -
context.WithValue不影响取消链，仅用于传参；取消能力只来自WithCancel及其衍生函数（WithTimeout、WithDeadline） -
WithTimeout底层也调用WithCancel并启 timer；提前手动cancel()会停掉 timer——这是设计行为，不是 bug
真正容易被忽略的是：ctx.Done() 是一个只读 channel，关闭后所有监听者立刻收到通知，但你必须用 select 去接，而不是靠轮询或事后检查 Err()。任何没配 select 的地方，都是 goroutine 泄漏的潜在入口。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
