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 或死锁。
立即学习“go语言免费学习笔记（深入）”；
- channel 创建开销极低（约几十 ns），远低于一次 goroutine 调度或内存分配
- 真正该池化的，是 channel 里传递的结构体指针（如
*Request），而非 channel 本身 - 若 channel 生命周期与某对象强绑定（如每个 TCP 连接独占一个
in chan []byte），直接在连接 struct 里定义字段即可，无需池化
channel 的性能问题，八成出在模型设计而非语法调优：是否真需要实时同步？能否合并小消息为批次？消费者是否在 channel 上做了耗时操作（比如在 case 后立刻调 http.Do）？先理清数据流再动 channel 参数，比盲目调 cap 或加 default 有效得多。
