无缓冲 channel 的 send 和 receive 操作必须配对发生：一方发送时必须有另一方同时接收，否则 goroutine 被挂起让出 m，由调度器调度其他 goroutine 运行。
go 中 channel 阻塞时，goroutine 不会“卡死”整个线程，而是被调度器挂起并让出 m（os 线程），由其他 goroutine 继续运行——这是 go 并发模型高效的关键。
无缓冲 channel 发送/接收为什么会阻塞
无缓冲 channel 的 send 和 receive 操作必须配对发生：一方发送时，必须有另一方同时在接收；反之亦然。若没有配对方就绪，当前 goroutine 就无法推进。
-
ch := make(chan int)创建后，ch 会立即阻塞，直到有 goroutine 执行 <code> - 同理，
在 channel 为空且无 sender 就绪时也会阻塞 - 这种同步语义本质是 goroutine 间的“握手”，不是轮询或超时重试
阻塞时 runtime 如何调度 goroutine
当 goroutine 因 channel 操作阻塞，Go 运行时会将其状态设为 waiting，从当前 M 上解绑，并放入该 channel 的等待队列（recvq 或 sendq）。此时 M 可立即执行其他 goroutine。
- 调度器不依赖 OS 级阻塞，全程在用户态完成 goroutine 切换
- 被挂起的 goroutine 不占用 M，也不会触发线程切换开销
- 一旦配对操作发生（如另一端开始接收），runtime 从等待队列中唤醒一个 goroutine，将其标记为
runnable并重新调度 - 唤醒顺序遵循 FIFO，但 select 多 case 场景下是伪随机选择
select 无 default 分支时的阻塞行为
select 本身不引入新阻塞逻辑，它只是多路 channel 操作的协调器；是否阻塞，完全取决于所有 case 是否可立即执行，以及是否存在 default。
- 所有
case的 channel 操作都不可立即进行（例如空 channel、满 buffer、无配对方）→ 若无default，整个 select 语句阻塞 - 阻塞期间，当前 goroutine 被挂起，M 去跑别的任务；不是忙等，也不消耗 CPU
- 注意：
select {}是经典死锁写法，会永久阻塞且无法被外部中断（除非 panic 或程序退出）
容易忽略的细节：nil channel 的特殊性
把 channel 设为 nil 后参与 select，该 case 永远不会就绪——这常被用来动态关闭某条通信路径，但需小心误判为“阻塞”。
-
var ch chan int（未 make）是 nil；ch := make(chan int); ch = nil也是 nil - 对 nil channel 的 send/receive 操作会永远阻塞（不是 panic）
- 在 select 中，nil channel 的 case 总是不可执行，相当于“被移除”，不影响其他 case 的判断逻辑
- 这个特性常用于条件性监听：比如连接断开后把
connCh置为 nil，后续 select 就自动跳过该分支
真正难调试的，往往不是“为什么阻塞”，而是“为什么没按预期唤醒”——比如 goroutine 提前退出、channel 被 close 后仍尝试发送、或多个 goroutine 竞争同一 channel 导致唤醒顺序不符合直觉。这些都需要结合 runtime.GoroutineProfile 或 pprof trace 来确认实际调度路径。
