无缓冲 channel 表现为同步行为，因其发送和接收必须同时就绪才能完成，任一方未就绪即阻塞，形成 goroutine 间严格的“握手”式同步；本质是 rendezvous 机制，非数据管道。
go 语言中 channel 本身没有“同步/异步”类型，只有“有缓冲”和“无缓冲”之分；所谓同步或异步，是使用方式带来的行为差异，不是 channel 的固有属性。
无缓冲 channel 为什么表现为同步行为
无缓冲 channel 的 make(chan int) 或 make(chan int, 0) 创建后，每次 发送或接收都会立即阻塞，直到对端准备好。这不是“设计成同步”，而是底层没有存储空间，数据必须“面对面交接”。
- 发送方调用
c 后，若无人接收，goroutine 被挂起，进入 <code>chan send等待状态 - 接收方调用
后，若无人发送，goroutine 被挂起，进入 <code>chan receive等待状态 - 这种双向等待强制两个 goroutine 在同一时刻“碰头”，天然形成同步点
- 典型用途：信号通知（如
done := make(chan struct{})）、等待某个操作完成、实现锁语义
有缓冲 channel 如何产生异步效果
缓冲区大小决定了“异步窗口”的宽度。只要缓冲未满，发送不阻塞；只要缓冲非空，接收不阻塞。这带来了时间解耦，但不是无限异步——它只是把阻塞点从“立刻”推迟到了“缓冲耗尽”或“缓冲为空”时。
-
make(chan int, 1)：可缓存 1 个值，发送一次不阻塞；第二次发送前必须有接收发生，否则阻塞 -
len(c)返回当前缓冲中待取数据个数，cap(c)是创建时指定的容量，二者都只对有缓冲 channel 有意义 - 缓冲区过小（如 1）容易掩盖背压问题，过大（如 10000）可能掩盖生产者过快、消费者滞后的隐患
- 注意：
close(c)后仍可读取缓冲中剩余数据，但不能再写；读完后继续读会得到零值 +false
常见误判：nil channel 和 closed channel 的阻塞行为
很多人混淆了“channel 不工作”和“channel 同步/异步”的关系。真正影响阻塞的，是 channel 的当前状态，而非创建方式。
-
var c chan int声明但未make→c是nil；对nilchannel 的任何收发操作都会永久阻塞（不是 panic） -
close(c)后：仍可读取缓冲内容，读完后返回零值和 <code>false；c 会 panic（<code>send on closed channel） - 在
select中，case 对 <code>nilchannel 永远不会就绪；对已关闭且缓冲为空的 channel 会立即就绪（返回零值 + false）
真正难处理的，从来不是“选同步还是异步”，而是“缓冲大小设多少才合理”以及“谁负责关闭、何时关闭、关闭后怎么清理”。这些决策一旦出错，阻塞、panic、goroutine 泄漏会同时出现，而且很难复现。
