无缓冲 channel 的阻塞行为由收发双方是否就绪决定：发送方阻塞直到有接收方，接收方阻塞直到有发送方；同一 goroutine 中收发必然死锁，因无法满足“跨协程接力”前提。
无缓冲 channel 的阻塞行为怎么判断？
Go 里 make(chan int) 创建的就是无缓冲 channel，它不存数据，只做“接力交接”——发送方必须等到有接收方在等，才会继续执行。反过来也一样：接收方会卡住，直到有人往里发。
常见错误现象：fatal error: all goroutines are asleep - deadlock
这基本就是你写了 ch <- 1 或 <-ch，但另一端没人配合，程序直接死锁。
使用场景：
- 需要严格同步两个 goroutine 的执行节奏（比如“等 A 完成后再启动 B”）
- 实现信号通知（如
done := make(chan struct{})，只用来关闭，不传数据） - 避免竞态时做简单协调（比 mutex 更轻量，但适用范围窄）
注意：无缓冲 channel 的容量是 0，cap(ch) 返回 0，len(ch) 永远是 0 —— 别想用 len 判断“有没有人等着”，它没意义。
为什么不能在同一个 goroutine 里 send 和 receive？
因为无缓冲 channel 的收发必须跨 goroutine 才能完成。写成这样必死锁：
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan int) ch <- 1 // 卡在这儿，永远等不到接收者 <-ch
正确做法永远是至少一方跑在另一个 goroutine：
- 发送放 goroutine 里：
go func() { ch - 接收放主 goroutine：
<-ch - 或者反过来，只要不写在同一执行流里
容易踩的坑：误以为 select + default 能绕过阻塞 —— 其实不能。select 对无缓冲 channel 的 case 依然要等配对操作，default 只是让 select 不阻塞，不代表 channel 本身不阻塞。
和有缓冲 channel 在性能/语义上差在哪？
无缓冲 channel 是同步原语，每次收发都涉及 goroutine 切换（唤醒+调度），本质是“握手协议”。有缓冲的（比如 make(chan int, 1)）则可能直接拷贝进缓冲区，不触发调度。
所以：
- 如果你只是想“丢个消息就走”，别用无缓冲 —— 容易卡住调用方，也拖慢吞吐
- 如果你需要确保“对方真的收到了”，才用无缓冲；否则用带缓冲的更稳
- 缓冲大小为 1 时，
len(ch)可能是 0 或 1，cap(ch)是 1；无缓冲时二者都是 0，这是最直接的区分方式
另外，无缓冲 channel 无法被 close 后再读取（会 panic：`panic: send on closed channel` 或 `deadlock`），而有缓冲的 close 后还能读完剩余数据 —— 这点常被忽略。
如何安全地关闭无缓冲 channel？
无缓冲 channel 一般不该被 close，除非你明确只用它做“单次通知”。例如：
done := make(chan struct{})
go func() {
defer close(done) // 通知完成
heavyWork()
}()
<-done // 等它关掉但要注意：
- 不能对无缓冲 channel 多次
close，会 panic：panic: close of closed channel - 不能在发送端 close 后还试图
ch ，同样 panic - 如果 channel 可能被多个 goroutine 写，得用
sync.Once或额外标志位控制 close，不能靠 channel 自身保证线程安全
真正难处理的是“双向等待”场景：比如两个 goroutine 都要等对方先发再回，又都不肯先动 —— 这时候无缓冲 channel 会立刻死锁，得靠超时、select + time.After 或改用其他同步机制。
