Go 的 chan 阻塞是将 goroutine 置为 gopark 状态并交出 M 控制权，开销主要来自 park/unpark 引起的调度切换；无缓冲 channel 阻塞概率最高，带缓冲需按吞吐节奏合理设置大小；make(chan int, 0) 与 make(chan int, 1) 性能相近但语义不同；select + default 仅适用于有明确 fallback 的非阻塞场景。

channel 阻塞时到底在做什么

Go 的 chan 阻塞不是“空转轮询”，而是将 goroutine 置为 gopark 状态，交出 M（OS 线程）控制权。真正开销来自调度切换：goroutine 被 park 后唤醒时需重新入调度队列、抢 M、恢复栈上下文。频繁阻塞 → 频繁 park/unpark → 调度器压力上升，尤其在高并发小消息场景下，runtime.schedule 和 findrunnable 耗时明显上涨。

用带缓冲 channel 替代无缓冲 channel 的条件

无缓冲 chan int 每次收发都需双方 goroutine 同时就绪，阻塞概率最高。但加缓冲不是万能解——缓冲区大小必须匹配实际吞吐节奏，否则只是把阻塞延迟到缓冲满/空时爆发。

• 若生产者速率稳定、消费者能持续跟上，缓冲大小设为 2–4 × 平均单批处理量（如批量写日志，每秒 100 条，处理耗时 10ms，则缓冲 20–40 足够）
• 若消费者偶发卡顿（如依赖外部 RPC），缓冲应覆盖「最差延迟窗口」内的产出量，而非峰值；否则缓冲溢出仍会阻塞，且内存占用陡增
• make(chan int, 0) 和 make(chan int, 1) 性能差异极小，但语义不同：后者允许一次“免同步”写入，适合信号通知类场景（如 done chan struct{} 改用 make(chan struct{}, 1) 可避免首次关闭时的竞态）

select + default 避免死等的适用边界

select 中加 default 是非阻塞尝试，但滥用会导致 CPU 空转或消息积压。

• 仅在「有明确 fallback 行为」时使用：比如发消息失败就降级打本地日志，或改走 HTTP 备用通道
• 不要用 for { select { case ch 这种伪非阻塞——sleep 时间难调，太短伤 CPU，太长拖延迟
• 对超时控制，优先用 select { case ch ，但注意 time.After 会启新 timer，高频调用建议复用 time.NewTimer 并 Reset

用 sync.Pool 缓存 channel 本身？别这么做

有人想复用 chan 对象减少 gc 压力，但 chan 是运行时管理的引用类型，底层包含锁、队列指针、等待 goroutine 列表等状态。从 sync.Pool 取出的 channel 若之前被 close 或已满/空，行为不可预测，极易引发 panic 或死锁。

• channel 创建开销极低（约几十 ns），远低于一次 goroutine 调度或内存分配
• 真正该池化的，是 channel 里传递的结构体指针（如 *Request），而非 channel 本身
• 若 channel 生命周期与某对象强绑定（如每个 TCP 连接独占一个 in chan []byte），直接在连接 struct 里定义字段即可，无需池化

channel 的性能问题，八成出在模型设计而非语法调优：是否真需要实时同步？能否合并小消息为批次？消费者是否在 channel 上做了耗时操作（比如在 case 后立刻调 http.Do）？先理清数据流再动 channel 参数，比盲目调 cap 或加 default 有效得多。