channel 缓存容量设为 0 和设为 N 的行为差异
零缓存 channel（make(chan int)）是同步的：发送必须等到有 goroutine 在另一端接收，否则阻塞；非零缓存 channel（make(chan int, N)）是异步的：只要缓冲未满就能发，未空就能收，不立即阻塞。
这不是“快慢”问题，而是“是否引入等待”问题。比如在日志采集场景中，用 make(chan []byte, 100) 能让写日志的 goroutine 快速返回，避免拖慢主逻辑；但若缓存设太大（如 10000），可能掩盖消费者处理慢的问题，导致内存积压或延迟不可控。
- 缓存为 0：适合需要严格顺序、强耦合协作的场景（如信号通知、状态同步）
- 缓存 > 0：适合解耦生产者和消费者节奏，但必须配合超时或背压策略（如
select+default或time.After） - 缓存过大（> 数千）：GC 压力上升，channel 内部的环形缓冲区占用连续堆内存，可能触发提前扩容和复制
如何观测 channel 积压导致的实际延迟升高
Go 运行时不会主动暴露 channel 队列长度变化对 P99 延迟的影响，得靠自己埋点。关键不是看 len(ch)，而是看“消息从 send 到 receive 经历了多久”。
典型错误是只监控 len(ch)，但它只反映瞬时积压，无法关联到业务延迟。真正有用的是在发送前打时间戳，在接收后计算差值，再聚合（如直方图）。例如：
立即学习“go语言免费学习笔记（深入）”；
ts := time.Now()
ch <- &logEntry{ts: ts, data: ...}接收端：
entry := <-ch latency := time.Since(entry.ts)
- 不要用
time.Now().UnixNano()手动算差——精度低且易出错，直接用time.Since() - 避免在 hot path 中频繁调用
time.Now()：可考虑每 N 次采样一次，或用runtime.nanotime()（需转成time.Duration） - 如果发现 latency 分布突然右移，且
len(ch)持续 > 0.8 * cap(ch)，基本能确定是消费者吞吐跟不上
channel 缓存容量与 GC 和调度器的隐性交互
channel 缓冲区本质是一段堆分配的 slice，元素类型越重（比如含指针的大 struct），GC 扫描开销越大。更隐蔽的是：当 channel 缓存长期不满，但 cap 很大，Go 调度器仍会为该 channel 的 send/recv 操作预留 runtime.g 结构体资源，间接影响 goroutine 复用率。
一个常被忽略的事实：make(chan struct{}, N) 的内存开销远小于 make(chan *bytes.Buffer, N)，因为前者无指针，GC 不扫描；后者每个元素都是指针，GC 必须遍历整个缓冲区。
- 优先用
chan struct{}做信号通道，而非chan bool或chan int（虽小但带额外字段） - 缓存大小建议按「峰值流量 × 平均处理耗时」粗略估算，而不是拍脑袋设 1024 或 4096
- 上线后用
go tool trace查看Proc status和Goroutine analysis，观察是否有大量 goroutine 卡在chan send或chan recv状态
用 select + default 避免无限阻塞，但别误用为“丢弃策略”
很多人用 select { case ch 来防阻塞，这本身没问题；但若业务语义不允许丢数据（比如金融指令），这种写法等于把可靠性交给了运气。
更危险的是：default 分支里不做任何补偿（如重试、落盘、告警），等于静默失败。而 channel 缓存只是临时容器，不是持久化层。
- default 分支必须明确处理后果：记录 metric、触发告警、降级写本地文件，或退化为同步调用
- 不要在循环里反复尝试 send 而不 sleep —— 可能引发 busy-loop，吃光 P
- 如果必须丢，确保丢的是可重放、幂等的数据；否则宁可阻塞或 panic，也别让系统处于未知状态
实际调优时，最常被跳过的一步是：确认延迟毛刺是否真的来自 channel 缓冲区，而不是下游 DB 查询变慢、网络抖动、或 GC STW。先用 go tool pprof -http 看 CPU 和 goroutine 阻塞分布，再决定要不要动 cap。
