send 操作在缓冲区满且无就绪接收者时阻塞，因 goroutine 被 gopark 挂起并入 sendq；接收方完成数据拷贝后检查 sendq 并用 goready 唤醒队首 sender，唤醒时机紧耦合于 recv 执行路径。
channel 缓冲区满时，send 操作为什么会阻塞
因为 Go 的 channel 是带同步语义的通信原语，send 在缓冲区满时不会丢弃数据或返回错误，而是直接挂起当前 goroutine，直到有接收方腾出空间。这背后不是轮询或定时器，而是通过 gopark 将 goroutine 置为 waiting 状态，并将其入队到该 channel 的 sendq（一个 waitq 类型的双向链表）中。
关键点在于：挂起不消耗 CPU，也不依赖系统线程调度；goroutine 被 park 后，M 可以立即去执行其他 G，调度开销极小。
- 仅当 channel 未关闭、缓冲区满、且无就绪接收者时，
send才会走 park 路径 - 如果此时有 goroutine 正在
recv并已入recvq，则 send 会跳过缓冲区，直接“配对”并拷贝数据，不入sendq - 使用
select带default分支可避免阻塞，但那是非阻塞写法，不属于挂起逻辑范畴
接收方唤醒发送方的具体时机和条件
唤醒不是由接收方“主动找”，而是在 chanrecv 函数执行过程中，检查 sendq 是否非空。一旦发现有等待的 sender，就从队头取出一个 goroutine，用 goready 将其标记为 runnable，并插入当前 P 的本地运行队列。
这个过程发生在接收操作完成数据拷贝之后、返回之前。也就是说：接收方自己还没完全退出 recv，就已触发了 sender 的唤醒。
- 唤醒只发生在成功 recv 且
sendq非空时；channel 关闭或 recv 超时不会唤醒 sender - 唤醒顺序是 FIFO，但不保证严格——若多个 P 并发调用 recv，可能有竞争，不过 runtime 已用原子操作和锁保护
sendq - 被唤醒的 sender 不会立刻执行，要等调度器下次调度到它；它恢复后会从
send的 park 点继续，完成数据入缓冲或直传
缓冲区大小如何影响挂起/唤醒行为
缓冲区大小（make(chan T, N) 中的 N）只决定“能缓存多少个未被消费的值”，不改变挂起唤醒机制本身。但实际表现差异明显：
-
N == 0（无缓冲 channel）：每次send都必须等待接收方就绪，即“同步握手”，挂起更频繁 -
N > 0：sender 最多可连续N次不阻塞；第N+1次才挂起；接收方每消费一次，就可能唤醒至多一个 sender -
N过大可能掩盖背压问题，导致内存堆积；过小则 goroutine 频繁挂起/唤醒，增加调度抖动
注意：len(ch) 返回当前缓冲中元素个数，cap(ch) 返回 N；二者都快，但它们不反映 sendq 或 recvq 中等待的 goroutine 数量。
调试和观测挂起中的 goroutine
无法用 fmt.Println 或日志直接捕获“正在挂起”的瞬间，但可通过 runtime 接口间接确认：
- 用
runtime.Stack(buf, true)获取所有 goroutine 状态，搜索包含chan send或chan receive的 stack trace 行 - pprof 的
goroutineprofile（/debug/pprof/goroutine?debug=2）会显示 blocking on chan send/receive 的 goroutine - 在
select中混用time.After或context.WithTimeout可暴露隐藏的挂起，比如超时后打印 “still waiting to send”
真正容易被忽略的是：channel 的挂起/唤醒是协作式的，完全依赖 Go 调度器，不涉及操作系统级的 sleep/wake 系统调用。这意味着你在 strace 或 perf 中看不到对应的 syscall，也别想用 gdb 断点打在“唤醒那一刻”——那发生在 runtime 的 C 代码里，且时机紧耦合于 recv 的执行路径。
