无缓冲通道仅保证一次发送与一次接收的严格配对阻塞，无法实现双向确认；所谓双向确认需两个独立无缓冲通道各司单向信号，单个chan struct{}在for循环中重复读写会因收发不同步导致死锁。
无缓冲通道本身不提供“强同步函数调用”或“双向确认”的抽象能力——它只保证一次发送与一次接收的严格配对阻塞。所谓“双向确认”，其实是两个独立的无缓冲通道配合使用，各自承担单向信号职责。
为什么不能用单个 chan struct{} 实现双向确认
单个无缓冲通道只能完成一次“手递手”交接：一方写、一方读，之后通道就空了。如果试图在同一个 ch 上反复写读（比如“你好了→我收到了→你开始→我完成了”），会立刻死锁——因为第二次写入时没有接收方就绪，而接收方又在等第二次写入才启动下一轮。
- 常见错误现象：
fatal error: all goroutines are asleep - deadlock - 典型误用：在 for 循环里重复
ch ，但只有一处 <code> - 根本原因：无缓冲通道不是队列，不保存历史；每次操作都要求实时、一对一配对
用两个 chan struct{} 搭建双向确认流程
真正的双向确认必须拆成两个独立信号流：一个用于“发起方通知执行方可以开始”，另一个用于“执行方通知发起方已完成”。两者不可复用，也不可省略任意一端。
- 场景示例：主 goroutine 启动 worker，要求 worker 初始化后返回句柄，再发任务；worker 处理完任务后需显式确认已退出
- 必须声明两个通道：
ready := make(chan struct{})和done := make(chan struct{}) - worker 内部必须按序执行：
ready （通知就绪）→ 等待任务 → <code>done （通知结束） - 主 goroutine 必须严格分步：
（等就绪）→ 发送任务 → <code>（等退出）
func main() {
ready := make(chan struct{})
done := make(chan struct{})
<pre class="brush:php;toolbar:false;">go func() {
fmt.Println("worker: initializing...")
time.Sleep(100 * time.Millisecond)
ready <- struct{}{} // 第一阶段：通知就绪
fmt.Println("worker: waiting for task...")
<-taskCh // 假设 taskCh 是另一个通道
fmt.Println("worker: done")
done <- struct{}{} // 第二阶段：通知完成
}()
<-ready // 主 goroutine 阻塞在此，直到 worker 就绪
fmt.Println("main: sending task")
taskCh <- "work"
<-done // 主 goroutine 阻塞在此，直到 worker 明确完成
fmt.Println("main: all confirmed")}
立即学习“go语言免费学习笔记（深入）”；
容易被忽略的泄漏与 panic 风险
双向确认流程中，任一环节中断都会导致永久阻塞，且无法自动恢复——这不是 bug，而是无缓冲通道的设计本质。你必须主动防御。
- 若 worker 可能 panic（如初始化失败），必须包裹
recover，并在 defer 中发done或关闭通道，否则主 goroutine 卡死 - 主 goroutine 不能提前退出（比如没等
就 return），否则 worker 在 <code>done 时永远阻塞，造成 goroutine 泄漏 - 不要用
close(ch)替代发送：接收方用会 panic，用 <code>v, ok := 则 <code>ok为 false，但语义已偏离“确认”，变成“可能已结束”，失去强同步意义
真正难的不是写出两个 chan struct{}，而是确保每个发送都有且仅有一个对应接收，并覆盖所有异常路径。一旦漏掉某条路径，整个流程就从“强同步”退化为“不确定挂起”。
