无缓冲通道仅保证一次发送与一次接收的严格配对阻塞，无法实现双向确认；所谓双向确认需两个独立无缓冲通道各司单向信号，单个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 <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6460" title="Golang Naming"><img
src="https://img.php.cn/upload/skill/000/000/081/179094616043400.jpg" alt="Golang Naming" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="overflowclass">Golang Naming</a>
<p class="overflowclass">Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>容易被忽略的泄漏与 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{}，而是确保每个发送都有且仅有一个对应接收，并覆盖所有异常路径。一旦漏掉某条路径，整个流程就从“强同步”退化为“不确定挂起”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
