无缓冲 channel 一写就阻塞，因为其底层 dataqsiz 为 0、buf 为 nil，无缓冲区存数据，发送必须与接收实时配对完成，否则 goroutine 被挂起入 sendq 队列等待。
无缓冲 channel 为什么一写就阻塞
因为它的底层调度逻辑是「配对即走」：发送方必须等到有接收方在读队列里等着，才能把数据直接交给对方，不经过缓冲区。没有接收者时，ch 就卡住，goroutine 进入 waiting 状态，直到另一个 goroutine 执行 <code>。
常见错误现象：
- main 函数里只
ch ，没启 goroutine 去读，直接 panic: "fatal error: all goroutines are asleep - deadlock" - select 里漏写
default或超时分支，导致在无数据可读时永久等待
真正起作用的不是「channel 本身」，而是 Go 运行时在 M:N 调度器中为它维护的两个队列：sendq（写阻塞的 goroutine）和 recvq（读阻塞的 goroutine）。只要任一队列非空，调度器就会尝试唤醒配对双方。
带缓冲 channel 的缓冲区到底存哪了
缓冲区是 hchan 结构体的一部分，分配在堆上，类型为循环数组（circular queue），长度由 make(chan int, 3) 中的 3 决定。它不共享栈，也不复用 goroutine 栈空间。
立即学习“go语言免费学习笔记（深入）”；
关键事实：
- 缓冲满时，
ch 会把当前 goroutine 推入 <code>sendq队列并挂起；缓冲空时，同理推入 <code>recvq - 从缓冲区读取数据后，
recvx指针前移；写入后，sendx前移；两者相等表示空，相差等于 len 表示满 - 哪怕缓冲大小为 1，也足以打破「必须同步配对」的约束——这是微服务中解耦生产/消费节奏最常用的手法
channel 关闭后还能读几次
可以无限次读，但每次都会立即返回零值 + false。例如 v, ok := ，关闭后 <code>ok 恒为 false，v 是对应类型的零值（0、""、nil 等）。
容易踩的坑：
- 用
for range ch读取已关闭 channel 是安全的，但若 channel 从未关闭，且无其他退出条件，就会死循环 - 重复
close(ch)会 panic，错误信息是panic: close of closed channel - 向已关闭的 channel 发送数据会 panic：
panic: send on closed channel - nil channel 的读写操作永远阻塞，不会 panic —— 这常被误用来做“禁用通道”，但实际极难调试
微服务里 channel 泄漏的真实原因
不是 channel 本身泄漏，而是持有它的 goroutine 因无法退出而持续驻留内存。典型场景是：启动一个 goroutine 往 channel 写数据，但没控制好生命周期，上游已停发，下游又没关 channel，写 goroutine 就卡在 ch 上永远睡着。
实操建议：
- 凡涉及长期运行的 goroutine，必须绑定
context.Context，用select监听ctx.Done() - channel 作为函数返回值时，务必配套提供关闭机制（如返回
func()或要求调用方传入ctx） - 避免用
for range ch处理可能永不关闭的 channel；改用for { select { case v, ok := - 监控手段：定期打点
runtime.NumGoroutine()，突增往往意味着泄漏
缓冲大小选 1 还是 100，不取决于直觉，而取决于你能否准确预估「最大背压差」——也就是生产端比消费端快多少个单位。错估会导致要么频繁阻塞，要么内存悄悄涨上去。
