ch
channel 发送时什么时候会阻塞
发送操作 ch 阻塞，只取决于当前 channel 的状态和缓冲区，跟接收方是否“准备好”无关——它只看有没有地方放数据。
- 如果是无缓冲 channel（
make(chan int)），发送方永远会阻塞，直到有 goroutine 在同一时刻执行（即同步配对） - 如果是有缓冲 channel（
make(chan int, 5)），仅当缓冲区已满（len == cap）时才阻塞；否则直接拷贝进底层数组并返回 - 注意：即使接收方 goroutine 已启动但还没执行到
，只要缓冲区有空位，发送就不会卡住
常见错误现象：fatal error: all goroutines are asleep - deadlock，往往是因为发完没接收、或接收逻辑被条件跳过，导致发送端永久等待。
channel 接收时为什么有时不阻塞，有时 panic
接收行为 是否阻塞，取决于 channel 是否关闭 + 是否有可读数据：
- 未关闭且缓冲区为空（或无缓冲 channel 没人发）→ 阻塞，直到有数据或 channel 关闭
- 已关闭且缓冲区为空 → 立即返回零值，不阻塞
- 已关闭但缓冲区还有数据 → 先读完缓冲区，再返回零值
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
- 对已关闭的 channel 反复接收不会 panic，但可能拿到意料之外的零值（比如
0、nil、""），需配合 ok-idiom 判断：v, ok := - 向已关闭的 channel 发送会 panic：
panic: send on closed channel，这个检查在运行时由chan.send函数完成，不是编译期检查 - 不要依赖“接收返回 false 就代表关完了”，因为关闭后还能读缓冲区剩余数据，ok 为 false 仅表示“此后不会再有新数据”
底层 runtime.chansend 和 runtime.chanrecv 怎么决定是否挂起 goroutine
Go 运行时用一个循环队列（buf）+ 两个等待队列（sendq、recvq）管理 channel。
-
chansend先尝试：缓冲区有空位 → 拷贝数据 → 返回；否则检查recvq是否非空 → 有则直接配对唤醒接收者 → 返回；否则将当前 goroutine 加入sendq并调用gopark挂起 -
chanrecv类似：缓冲区有数据 → 直接取 → 返回；否则查sendq→ 有则配对唤醒发送者 → 返回；否则挂起进recvq
关键点：
- 所有判断和队列操作都在临界区（加锁）中完成，保证原子性
- 挂起前会把 goroutine 标记为 waiting on channel，并记录唤醒回调函数（
runtime.goready） - 唤醒不等于立即执行：只是从 waiting 状态变回 runnable，仍需等调度器分配 M
性能影响：频繁阻塞/唤醒会增加调度开销；若 channel 成为热点路径，建议用带缓冲 channel 或改用其他同步机制（如 sync.Mutex + slice）。
如何验证某个 channel 操作是否真的阻塞了
不能只靠日志或延时猜测，得看 goroutine 状态或运行时信息。
- 使用
runtime.Stack打印当前所有 goroutine 的栈，搜索chan send或chan receive字样，看到类似runtime.gopark就说明卡住了 - 在调试模式下用
dlvattach 进程，执行goroutines查看状态，再用goroutine看具体在哪一行阻塞bt - 更轻量的方式：在发送/接收前后打时间戳，如果耗时远超预期（比如几毫秒以上），大概率是阻塞了（注意排除 GC STW 影响）
容易被忽略的地方：channel 阻塞是 goroutine 级别的，不是线程级；一个 goroutine 卡住不影响其他 goroutine 调度，但若大量 goroutine 堆积在同一个 channel 上，可能拖慢整个程序响应——这时候问题不在 channel 语法，而在设计节奏没对齐。
