零容量channel（make(chan int)）用于同步通信，需收发配对；非零容量才具缓冲能力，应按实际节奏设定，避免盲目设大导致OOM或逻辑错乱。
channel 容量设为 0 还是正数？关键看是否需要缓冲
零容量 channel（make(chan int)）是同步的，发送和接收必须配对阻塞等待；非零容量（如 make(chan int, 10)）才具备缓冲能力。盲目设大缓冲（比如 10000）看似“防堵”，实则掩盖背压问题、增加内存占用、延迟问题暴露——尤其在消费者慢于生产者时，缓冲区会持续积压，最终 OOM 或逻辑错乱。
建议按实际节奏设缓冲：
- 纯事件通知、信号传递 → 用
make(chan struct{}, 1)，够发一次且不阻塞发送方 - 批量写日志、上报指标 → 按典型批次大小设缓冲（如
make(chan []byte, 128)），避免频繁 goroutine 切换 - 不确定速率差 → 先用无缓冲调试，观察
select超时或 goroutine 堆积，再按需加缓冲
用 select + default 避免 goroutine 无限阻塞
直接读写无缓冲 channel 或满缓冲 channel，若无人收/发，goroutine 会永久挂起。常见于后台 worker 模式中“忘记处理退出信号”或“生产者已停但消费者还在等”。
正确做法是始终为 channel 操作兜底：
立即学习“go语言免费学习笔记（深入）”；
select {
case data := <-ch:
process(data)
default:
// 非阻塞检查，立刻返回
runtime.Gosched() // 主动让出时间片，防忙等
}注意：default 分支不能空跑循环，否则 CPU 100%；配合 time.Sleep 或 runtime.Gosched() 控制节奏。若需等待但又怕死锁，改用带超时的 select：
select {
case data := <-ch:
process(data)
case <-time.After(100 * time.Millisecond):
// 超时处理，比如记录告警或重试
}别把 channel 当共享内存用：避免多个 goroutine 同时读/写同一 channel
channel 本身是并发安全的，但“多对多”使用极易引发逻辑混乱。典型反模式：
- 多个 goroutine 向同一个
chan int发送，却不关 channel → 接收方永远不知道是否结束 - 多个 goroutine 从同一 channel 接收，但没做任务分片 → 数据被随机抢走，无法保证顺序或归属
正确设计原则：
- 发送端唯一：由单一 goroutine 负责 send，其他协程通过函数参数或消息结构体传递数据
- 接收端可多，但需明确生命周期：用
close()通知结束，并在接收侧用for range或ok判断 - 需要扇出（fan-out）？显式启动多个 receiver goroutine，共用一个只读 channel；扇入（fan-in）？用单独的 merge goroutine 汇总多个输入 channel
关闭 channel 的时机和方式直接影响下游行为
关闭未关闭的 channel 会 panic；向已关闭的 channel 发送也会 panic。最常踩的坑是：在多个 goroutine 中竞态调用 close(ch)。
安全关闭的唯一推荐方式：
- 仅由发送方（且仅一个 goroutine）负责关闭，遵循 “send-only goroutine owns close” 原则
- 接收方绝不要尝试关闭 channel
- 关闭前确保所有发送已完成（比如用
sync.WaitGroup等待所有 sender 结束）
判断 channel 是否关闭，靠接收的第二个返回值：
if data, ok := <-ch; !ok {
// ch 已关闭且无剩余数据
break
}注意：for range ch 内部就是靠这个机制自动退出，但前提是 channel 必须被发送方关闭——这点常被忽略，导致 range 永不结束。
复杂点在于：当 channel 是多个 sender 共享时，必须引入额外协调机制（如 sync.Once 包裹 close()），否则仍可能 panic。这种场景，往往说明设计该重构了。
