无缓冲 channel 的发送和接收必然同步阻塞：因无内部存储空间，发送操作需等待对应接收操作就绪，反之亦然，二者必须成对、同步完成。
无缓冲 channel 的发送和接收必然同步阻塞
无缓冲 channel（make(chan int)）没有内部存储空间，所以每次 或 ch 都必须“对面有人等”，否则当前 goroutine 立刻挂起。这不是调度策略，是语言级语义：发送方会一直卡在 ch ，直到另一个 goroutine 执行到 v := ；反过来也一样。
常见错误是只启动发送 goroutine，但主协程没写接收逻辑，或接收逻辑被 if 条件跳过，结果程序 panic: all goroutines are asleep - deadlock。
实操建议：
- 调试时加
fmt.Println("before send")和fmt.Println("after send")，如果只看到前者，基本确定卡在发送阻塞 - 避免在单个 goroutine 里既发又收同一个无缓冲 channel（除非用
select配超时或默认分支） - 测试阶段可临时加
time.Sleep(100 * time.Millisecond)看是否缓解——但这只是掩盖问题，不是解法
有缓冲 channel 的“异步”其实是带条件的非阻塞
有缓冲 channel（make(chan int, N)）本质是个环形队列，发送仅在缓冲区满时阻塞，接收仅在空时阻塞。它不保证“一定不阻塞”，只降低阻塞概率。比如 ch := make(chan int, 1)，连续两次 ch ，第二次必卡住。
容易误以为“开了缓冲就等于完全异步”，结果在高并发压测时突然卡死。真实场景中，缓冲大小要按峰值吞吐预估，不能拍脑袋设 100 就完事。
实操建议：
- 缓冲大小 ≠ 并发数，而是「最大未处理消息积压量」。例如每秒 100 请求、下游处理耗时 50ms，理论积压上限是 5 条，缓冲设 10 更稳妥
- 用
len(ch)查当前已存数据量，cap(ch)查容量，二者差值就是还能写几条而不阻塞 - 别依赖缓冲“兜底”来掩盖设计缺陷——该用 worker pool 控制并发，就别靠加大 buffer 硬扛
用 select + time.After 实现可控唤醒
channel 等待若不加超时，就是无限期挂起。线上服务里，一个没超时的 可能导致整个 HTTP handler 卡死，连接堆积，最后 OOM。
标准做法是用 select 分支配合 time.After，让等待变成“最多等 X 秒”。注意：time.After 返回的是 ，不能直接赋给变量再塞进 select，必须原样写在 case 后。
示例片段：
select {
case result := <p>实操要点：</p>
- 别用
timer := time.NewTimer(...); select { case ，除非你要复用 timer；否则time.After更简洁且无泄漏风险 - 超时后，原 goroutine 可能还在跑。若需主动终止（比如取消 HTTP 请求），得配合
context.WithTimeout传入下游 - 如果 channel 是带缓冲的，
可能立刻返回零值（如int返回 0），记得结合业务判断这个 0 是有效数据还是“没等到”的占位符
goroutine 完成通知该用 chan struct{} 而不是 chan bool
用 channel 做完成信号时，chan struct{} 是事实标准。它零内存占用（unsafe.Sizeof(struct{}{}) == 0），语义清晰——只表“事件发生”，不传数据。而 chan bool 多占 1 字节，还容易让人误以为要读取 true/false 含义。
典型结构是主协程先声明 done := make(chan struct{})，启动 goroutine 时传进去，goroutine 结尾写 done ，主协程用 等待。
容易踩的坑：
- 忘记 close(channel)，或者重复 close，都会 panic
- goroutine panic 了但没发信号，主协程永远卡住。正确做法是在 goroutine 内部加
defer func() { recover(); done - 多个 goroutine 共用一个
donechannel，但只发一次信号——这没问题；但如果期望“每个都通知”，就得每人一个 channel 或改用sync.WaitGroup
真正难的不是写对语法，而是判断某个 channel 该不该缓冲、缓冲多大、等不等超时、信号要不要 recover 补发——这些都得贴着业务 SLA 和失败模式去推演，没法套模板。
