无缓冲 channel 必须用 make(chan t, 0)，它是同步点，要求发送与接收同时就绪，适用于通知、等待完成等场景，否则易导致死锁。
什么时候必须用 make(chan T, 0)（无缓冲）
无缓冲 channel 是同步点，发送和接收必须同时就绪才能通行。它天然适合“通知”“等待完成”这类场景，比如 goroutine 启动后等它真正开始工作、主协程等子任务结束再继续。
常见错误现象：fatal Error: all goroutines are asleep - deadlock——你只发不收，或只收不发，又没其他 goroutine 配合，立刻死锁。
- 需要严格顺序控制：比如 A 必须等 B 执行完某步才继续，用
done := make(chan Struct{})+done + <code> - 不关心数据内容，只关心“发生了”：如信号量、任务启动确认
- 配合
select做非阻塞探测时，default分支才有意义；有缓冲 channel 即使为空也可能误触发
有缓冲 channel 的大小不是“越大越好”，而是“够用且可控”
缓冲区本质是内存队列，设太大等于在 goroutine 间悄悄积累状态，容易掩盖背压问题，甚至拖垮内存。它的大小应该由你对“最大积压量”的明确预期决定，而不是拍脑袋填个 1024 或 65536。
使用场景举例：生产者速度波动大，但消费者能稳定处理，允许短暂排队；或批量写日志时先攒几条再刷盘。
- 设为
1：最轻量的解耦，避免发送端因接收端暂时卡住而阻塞，又不至于积太多 - 设为固定小整数（如
8、16）：适用于已知峰值并发数或批次大小，比如每批最多处理 8 个请求 - 避免用
math.MaxInt或超大常量：GC 压力、OOM 风险、调试困难——channel 内部用 slice 实现，扩容逻辑和 slice 一样 - 注意
len(ch)返回当前队列长度，cap(ch)才是缓冲区容量；别把二者混淆成“剩余可用空间”
close() 对有缓冲 channel 的影响比你想的更微妙
关闭一个有缓冲 channel 不会清空已有数据，只是让后续发送 panic（send on closed channel），而接收仍可取完缓冲中剩余值，之后才返回零值。
这导致一个典型坑：你以为 close(ch) 就等于“所有数据已送达”，其实可能还有几条卡在缓冲里没被消费——尤其当接收方用 for range ch 时，它会等缓冲耗尽才退出。
- 如果接收方依赖
for range自动退出，确保发送方关 channel 前，所有数据都已写入（包括缓冲区最后一格） - 不要靠
close()来“唤醒”接收方；要用额外的 done channel 或 context - 检查是否已关闭需用双返回值接收：
v, ok := ；仅用 <code>v := 无法区分是零值还是关闭后读到的零值
性能与调试线索：缓冲区大小如何影响调度行为
无缓冲 channel 的 send/receive 是原子性的同步操作，涉及 goroutine 切换和调度器介入；有缓冲 channel 的发送只要缓冲未满就不切换，接收只要缓冲非空也不切换——这看似快，但也意味着背压延迟暴露。
调试时若发现 goroutine 数暴涨或 CPU 空转，检查 channel 缓冲是否过大，导致生产者一路狂奔，消费者跟不上，积压越堆越多。
- 用
runtime.ReadMemStats或 pprof 查看 heap 中 slice 分配增长，间接推测 channel 缓冲膨胀 - 用
go tool trace观察 goroutine 在 channel 操作上的阻塞时间：无缓冲通常显示为“blocking send/receive”，有缓冲则可能长时间不出现阻塞标记 - 缓冲区大小为 0 和 1 在底层实现上差异极小，但语义完全不同；别为了“省一次调度”而把本该同步的逻辑改成带缓冲
实际选缓冲区大小时，最麻烦的不是算数字，是想清楚“谁在等谁，等多久，最多容许多少消息滞留”。这个判断一旦错了，后面加监控、调参数、改逻辑，全是在补最初那句 make(chan int, ?) 的漏洞。