本文详解单 chan bool 在多 goroutine 协作场景下引发死锁的根本原因，并提供基于通道关闭、goroutine 分离与同步控制的健壮解决方案。
本文详解单 chan bool 在多 goroutine 协作场景下引发死锁的根本原因，并提供基于通道关闭、goroutine 分离与同步控制的健壮解决方案。
在 Go 并发编程中，使用无缓冲通道（如 chan bool）进行“信号通知”是一种常见模式，但若设计不当，极易触发 goroutine 死锁（deadlock）。你提供的代码正是典型反例：主 goroutine 在 select 中以非阻塞方式轮询
? 死锁根源分析
- 无缓冲通道要求收发双方同时就绪：found := make(chan bool) 创建的是无缓冲通道，found
- 主 goroutine 的 select + default 是“伪轮询”：default 分支使主 goroutine 不会等待通道，但它只在每次循环中尝试一次接收；若此时无 worker 发送，就跳过；而 worker 一旦开始发送却无人接收，即卡死。
- wg.Wait() 在 select 循环之后执行：这意味着主 goroutine 必须先完成整个 for 循环（可能已启动全部 worker），再等待它们结束——但部分 worker 已在 found
✅ 正确解法：分离接收逻辑 + 显式关闭通道
核心思路是：让接收行为由独立 goroutine 持续执行，避免主 goroutine 与发送方竞争时序；并通过关闭通道通知接收端退出，确保资源清理。
以下是推荐的生产级实现：
package main
import (
"sync"
"time"
)
func worker(found chan<h3>⚠️ 关键注意事项</h3>
- 永远不要对无缓冲通道做“单次非阻塞发送”：除非你能 100% 确保此刻有 goroutine 正在接收（实践中几乎不可能）。
- 用 close(ch) 替代“发送哨兵值”来终止接收循环：for range ch 会在通道关闭后自动退出，比 select + default 更可靠。
- 避免 wg.Wait() 前未关闭通道：否则 receiver 会永远阻塞在 for range found，导致 wg.Wait() 无法返回。
- 考虑上下文取消（Context）：真实项目中建议用 context.WithCancel 替代 done chan struct{}，便于传播取消信号并支持超时/截止时间。
- 注意并发安全：若需传递具体结果（不止 bool），应使用带结构体的通道（如 chan Result），并确保接收端及时消费，防止发送端阻塞。
通过将“信号接收”职责从主流程剥离至专用 goroutine，并配合通道关闭机制，即可彻底规避此类死锁，构建出响应及时、可终止、易维护的并发工作流。
