17370845950

零容量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。这种场景，往往说明设计该重构了。