无缓冲channel在高并发下极易死锁：因要求发送与接收严格配对，一旦出现只发不收、只收不发或goroutine缺失（如未启collector），即导致永久阻塞；运行时检测到所有goroutine挂起，panic“all goroutines are asleep - deadlock”。
无缓冲 channel 在高并发下必然卡死
无缓冲 chan int 要求发送和接收严格配对，一旦某次调用没配好 goroutine（比如只发不收、或只收不发），整个 goroutine 就永久挂起。高并发场景下这种错配概率指数级上升，运行时检测到所有 goroutine 都在等对方，直接 panic “fatal error: all goroutines are asleep - deadlock”。
常见误用：
- 主 goroutine 启动一堆 worker，但忘了启动对应的 collector 或 dispatcher
- HTTP handler 里向无缓冲 channel 发送请求参数，却把接收逻辑写在另一个未启动的 goroutine 中
- select 里只有
ch 没有 default，而 ch 长期无人消费
解决思路不是“加超时”，而是“换结构”：高并发通信必须用带缓冲通道，缓冲大小按峰值 QPS × 平均处理延迟粗估，例如 10k QPS × 50ms = 500，设 make(chan Request, 1024) 更稳妥。
缓冲区大小设错引发隐性阻塞
缓冲区不是越大越好。过大的 dataqsiz 会导致 hchan.buf 占用大量连续堆内存，GC 压力陡增；更关键的是，当缓冲区长期满载，发送方会持续阻塞在 sendq 队列里等待空位，而接收方若因慢 SQL、远程调用卡住，就会形成“通道背压传导”——上游服务线程池耗尽、HTTP 连接堆积、最终触发熔断。
实操建议：
- 监控
runtime.ReadMemStats().Mallocs和 goroutine 数，若二者同步上涨，大概率是 channel 缓冲区撑开后没及时消费 - 用
pprof/goroutine查看阻塞点，若大量 goroutine 停在chan send或chan recv，说明缓冲区已成瓶颈 - 生产环境缓冲区上限建议 ≤ 4096，超过此值应拆分为多个 channel + 分片路由（如按 user_id % N）
close(nil) 和向 nil channel 发送导致静默阻塞
nil channel 不是“空通道”，而是未初始化的指针。向 nil 发送或接收会永远阻塞，且不会 panic，Go 运行时不报错也不唤醒——这是最危险的阻塞类型，因为程序看似正常运行，实则 goroutine 在后台持续泄漏。
典型触发场景：
- 用
make([]chan int, N)创建通道切片，忘记遍历初始化每个元素：for i := range chans { chans[i] = make(chan int, 16) } - 配置驱动的 channel 初始化逻辑中，环境变量缺失导致
ch := getChanFromConfig()返回 nil - defer close(ch) 放在未判空的函数末尾，ch 实际为 nil
防御手段只有一条：所有 channel 变量声明后必须显式初始化，禁止依赖零值。上线前用 go vet -shadow 和静态检查工具扫出未赋值的 channel 变量。
高并发写入时 lock 竞争拖垮吞吐
底层 hchan.lock 是全局互斥锁，所有对同一 channel 的 send/recv/close 操作都需抢占它。当多个 goroutine 高频写入同一个带缓冲 channel（如日志聚合、指标上报），CPU 大量时间花在锁调度上，runtime/pprof/block 会显示 sync.(*Mutex).Lock 占比异常高。
这不是代码写得烂，而是设计缺陷：单点 channel 天然无法水平扩展。根治方式是去中心化：
- 用
sync.Pool管理 per-goroutine 的小 buffer，攒够一批再批量写入 channel - 改用 fan-out 模式：一个入口 channel 接收原始事件，N 个 worker goroutine 各持一个独立 channel 消费，避免锁争抢
- 超大规模场景直接弃用 channel，改用 lock-free ring buffer（如
github.com/Workiva/go-datastructures）或消息队列中间件
真正难的不是写出能跑的并发代码，而是预判哪个 channel 会在 QPS 突增时成为单点瓶颈——这需要你读过 src/runtime/chan.go 里 send 和 recv 函数的锁路径，而不是只记住“channel 是协程通信管道”这句话。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
