channel容量设为0还是正数取决于是否需要缓冲：零容量用于同步和强一致性场景，非零容量用于解耦生产消费节奏但需防内存暴涨；关闭前须确保所有发送者退出，避免panic。

channel 容量设为 0 还是正数？关键看是否需要缓冲

零容量 channel（make(chan int)）是同步的，发送方必须等到有 goroutine 在另一端接收才能继续；非零容量 channel（如 make(chan int, 10)）可暂存数据，但会增加内存占用和调度复杂度。是否加缓冲，取决于你是否想解耦生产与消费节奏。

常见误用：为“避免阻塞”盲目设大缓冲，结果掩盖了消费者滞后问题，最终导致内存暴涨或消息积压。

• 日志采集、监控打点等允许少量丢失的场景 → 用带缓冲 channel（如 make(chan []byte, 100)），并配合 select + default 非阻塞写入
• 状态同步、任务分发等强一致性要求场景 → 用无缓冲 channel，靠 gor

  

  outine 协作保证时序
• 缓冲大小 ≠ 并发数，应基于平均处理延迟和峰值吞吐预估，而非拍脑袋设 1024 或 65536

关闭 channel 前必须确认所有发送者已退出

对已关闭的 channel 执行发送操作会 panic：panic: send on closed channel；而从已关闭 channel 接收会立即返回零值 + false。但很多人只记得“关闭要由发送方做”，却忽略多 goroutine 并发发送时的竞态。

典型错误模式：多个 worker 同时向同一 channel 发送结果，主 goroutine 在启动后直接 close(ch) —— 此时部分 worker 可能尚未完成发送。

• 用 sync.WaitGroup 等待所有发送 goroutine 结束后再关闭
• 改用 errgroup.Group 管理一组 goroutine，并在其 Wait() 返回后关闭 channel
• 避免在 defer 中关闭 channel，除非你能 100% 确保该 goroutine 是唯一发送者且不会被重复启动

用 select + default 避免 goroutine 永久阻塞

单个 ch 或 在 channel 无缓冲且无人收/发时会永久挂起，导致 goroutine 泄漏。真实服务中，下游可能临时不可用、超时或重启，不能假设 channel 总是 ready。

正确做法是把通信包裹进 select，并加入 default 分支做降级或重试，或用 time.After 控制超时。

select {
case ch <- data:
    // 发送成功
default:
    // 缓冲满或无人接收，记录告警或丢弃
    log.Warn("channel full, dropping message")
}

• 永远不要在热路径上写裸 ch ，尤其在 HTTP handler 或定时任务中
• 如果必须等待，用带超时的 select，例如 case
• default 不是“兜底”，而是你主动选择的策略 —— 是丢弃、重试、还是切到本地队列？得明确

别用 channel 传大数据，拷贝开销远超预期

Go 的 channel 传递的是值拷贝。若发送 struct{ data [1024 * 1024]byte }，每次发送都会复制 1MB 内存；更隐蔽的是传递大 slice，虽然 header 很小，但底层数组仍可能被多个 goroutine 共享，引发意外修改或 GC 延迟。

观察 runtime.ReadMemStats 会发现 Mallocs 和 HeapAlloc 异常升高，往往就是 channel 在悄悄搬运大对象。

• 传大对象一律用指针：chan *HeavyStruct，但需确保接收方不长期持有或并发读写同一实例
• 对只读大块数据（如配置、模板），考虑用 sync.Map 或全局变量 + 初始化一次性加载
• 用 go tool trace 查看 goroutine 阻塞和内存分配热点，比凭感觉调优更可靠

实际项目里，channel 的“优雅”常来自克制——少用、用对、及时关、不传重物。最容易被忽略的是：关闭时机和大数据拷贝，这两处一出问题，轻则毛刺，重则 OOM。