quit 通道用于在 `same` 函数提前退出时，主动通知正在运行的 `walk` 协程停止遍历，避免资源浪费和死锁，是 go 并发编程中“协作式取消”的典型实践。
在 Go Tour 的 binarytrees_quit.go 示例中，quit 是一个 chan struct{} 类型的无缓冲通道，其核心作用并非简单“等待协程结束”，而是实现可中断的、协作式的遍历终止机制。
考虑这样一个场景：Same(t1, t2) 需要判断两棵二叉树是否具有完全相同的中序遍历序列。它通过并发启动两个 Walk 协程（分别向 ch1 和 ch2 发送节点值），然后逐个比较输出。一旦发现某次比较失败（如 v1 != v2）或某棵树提前结束而另一棵未结束（ok1 != ok2），Same 应立即返回 false —— 但此时两个 Walk 协程很可能仍在递归遍历子树，若不加干预，它们会继续执行直至完成整棵树的遍历，造成不必要的计算开销，甚至可能因通道未被消费而阻塞（尤其在非对称树结构下）。
quit 通道正是为此设计：
-
在 Walk 函数中，每次准备向输出通道 ch 发送一个节点值前，都使用 select 同时监听 ch 和 quit：
select { case ch <- t.Value: case <-quit: // 若 quit 被关闭，则此分支立即就绪，函数 return return }由于 chan struct{} 关闭后，对其接收操作会立即返回零值（struct{}{}）且 ok 为 false，因此
-
在 Same 函数中，quit 通道在函数退出时由 defer close(quit) 自动关闭：
func Same(t1, t2 *tree.Tree) bool { quit := make(chan struct{}) defer close(quit) // 函数返回前关闭 quit，触发所有监听它的 Walk 协程退出 w1, w2 := Walk(t1, quit), Walk(t2, quit) // ... 比较逻辑 }这一设计确保：无论 Same 因匹配失败、树结构不等还是其他原因提前返回，quit 的关闭都会像“广播信号”一样，瞬间唤醒并终止所有正在等待的 Walk 协程，实现轻量、确定性的清理。
⚠️ 注意事项：
- 不可用 panic 或强制 kill：Go 不提供终止 goroutine 的 API，这是有意为之的设计哲学——避免线程局部性，保障调度透明性与可组合性。
- 不能依赖未缓冲通道的“存在”来保活协程：未缓冲通道仅影响发送/接收的阻塞行为，不提供生命周期管理；若无 quit，Walk 协程可能永远阻塞在 ch
- struct{} 是最佳选择：零内存占用、语义清晰（仅作信号用途），符合 Go 通道通信的惯用模式。
总结来说，quit 通道是 Go “通过通信共享内存”理念的具象体现：它不控制协程，而是提供一种受控的、非侵入的退出协商机制。这种基于通道的协作取消模式，是构建健壮、可伸缩并发程序的基础范式。
