channel容量设为0还是正数取决于是否需要缓冲：零容量用于同步和强一致性场景，非零容量用于解耦生产消费节奏但需防内存暴涨；关闭前须确保所有发送者退出，避免panic。
channel 容量设为 0 还是正数？关键看是否需要缓冲
零容量 channel（make(chan int)）是同步的，发送方必须等到有 goroutine 在另一端接收才能继续；非零容量 channel（如 make(chan int, 10)）可暂存数据，但会增加内存占用和调度复杂度。是否加缓冲，取决于你是否想解耦生产与消费节奏。
常见误用：为“避免阻塞”盲目设大缓冲，结果掩盖了消费者滞后问题，最终导致内存暴涨或消息积压。
- 日志采集、监控打点等允许少量丢失的场景 → 用带缓冲 channel（如
make(chan []byte, 100)），并配合select+default非阻塞写入 - 状态同步、任务分发等强一致性要求场景 → 用无缓冲 channel，靠 goroutine 协作保证时序
- 缓冲大小 ≠ 并发数，应基于平均处理延迟和峰值吞吐预估，而非拍脑袋设 1024 或 65536
关闭 channel 前必须确认所有发送者已退出
对已关闭的 channel 执行发送操作会 panic：panic: send on closed channel；而从已关闭 channel 接收会立即返回零值 + false。但很多人只记得“关闭要由发送方做”，却忽略多 goroutine 并发发送时的竞态。
典型错误模式：多个 worker 同时向同一 channel 发送结果，主 goroutine 在启动后直接 close(ch) —— 此时部分 worker 可能尚未完成发送。
立即学习“go语言免费学习笔记（深入）”；
- 用
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。
