无缓冲 channel 在发送时若无 goroutine 接收即阻塞，导致死锁；有缓冲 channel 容量应据峰值写入速率与消费延迟估算；关闭后发送 panic，接收返回零值和 false。
无缓冲 channel 什么时候会卡住？
无缓冲 chan int 的发送操作必须等到有 goroutine 在另一端接收，否则阻塞。这不是“慢”，是同步等待——它天然强制了生产者与消费者的时间耦合。
常见错误现象：fatal error: all goroutines are asleep - deadlock，尤其在单 goroutine 中写完就忘读，或读写顺序错乱时高频出现。
适用场景：
- 需要严格同步点，比如初始化完成通知、信号量式协调
- 跨 goroutine 传递控制权（如
done通道关闭即退出） - 不关心吞吐，只关心“这件事确实发生了”
性能影响：零内存分配，但上下文切换开销真实存在；高并发下若配对不及时，容易堆积 goroutine 等待队列。
立即学习“go语言免费学习笔记（深入）”；
有缓冲 channel 的容量设多少才不浪费也不卡死？
缓冲大小不是越大越好。设为 1 和设为 1000 的行为差异极大：前者接近无缓冲（仅避免瞬间竞态），后者可能掩盖背压缺失，让生产者一路狂奔直到内存吃紧。
关键判断依据是「峰值写入速率」和「平均消费延迟」的比值。简单估算公式：buffer_size ≈ peak_writes_per_second × max_consumption_latency_in_seconds。
实操建议：
- 日志采集类场景常用
chan string+ 缓冲128或256，够撑住短时 burst - HTTP handler 向后台投递任务，缓冲
1就够——因为 handler 本就不该等结果 - 避免用
make(chan T, math.MaxInt)，Go 运行时不会报错，但会悄悄 OOM
注意：len(ch) 返回当前已存元素数，cap(ch) 才是缓冲上限；两者都非原子操作，不能靠它们做条件判断。
channel 关闭后继续 send 会 panic，但 receive 不会
向已关闭的 chan int 发送数据会立即触发 panic: send on closed channel；而从已关闭的 channel 接收，会立刻返回零值 + false（第二个返回值）。
典型误用：
- 多个 goroutine 共同关闭同一 channel（竞态）
- 用
close(ch)当作“清空”操作（无效，已缓冲的数据还在） - 关闭后还调用
ch ，尤其在 defer 里没加防护
安全做法：
- 只由“唯一生产者”关闭 channel（常见于启动 goroutine 写入，结束后 close）
- receiver 侧用
v, ok := 判断是否关闭，而非依赖range（range 自动处理关闭，但无法捕获中间错误） - 不要在 select 的 default 分支里盲目 send，容易撞上已关闭状态
用 benchmark 测 channel 性能要注意什么？
go test -bench 跑出来的数字，很容易误导。因为默认情况下，channel 操作被编译器优化掉（尤其是空循环里的 send/receive），结果接近 0ns/op。
必须做两件事才能测出真实开销：
- 用
runtime.KeepAlive()阻止优化（例如在 send 后 keepalive 变量） - 确保 channel 两端都有实际 goroutine 在跑，否则测的是“单线程同步开销”，不是并发调度成本
一个可靠的小例子：
func BenchmarkUnbufferedSend(b *testing.B) {
for i := 0; i < b.N; i++ {
ch := make(chan int)
go func() { <-ch }()
ch <- 1
runtime.KeepAlive(ch)
}
}真正影响性能的从来不是 channel 本身，而是它引发的 goroutine 唤醒、调度器介入、缓存行竞争这些底层动作。测出来快，不代表架构合理；测出来慢，大概率是你用错了场景。
