Go Channel 深入解析
很多人写 Go 后端时都会用 channel。
任务分发要用它，worker pool 要用它，超时控制要配合 select，优雅退出常常是 done chan struct{}，限流时又会拿 buffered channel 当信号量。
但真的遇到的时候，很多人一碰到下面这些问题就开始发虚：
nil channel为什么会永远阻塞？close之后到底还能不能继续读？v, ok := <-ch里的ok=false到底什么时候出现？- 无缓冲 channel 和有缓冲 channel，差别真的只是'一个有容量一个没容量'吗？
select为什么看起来简单，runtime 实现却明显更复杂？
如果面对这些问题时并不是胸有成竹，说明你对 channel 的理解，大概率还停留在'会用语法'这一步。
这篇文章我不打算只讲语法糖，而是顺着一条更实用的线讲清楚：
- 语言层，channel 到底承诺了什么语义。
- 同步层，它为什么不只是'传值工具'。
- runtime 层，
hchan、等待队列、唤醒逻辑到底怎么配合。 - 工程层，什么时候该用 channel，什么时候别硬上。
1. 为何不能只停留在 语法层
只会写下面这种代码，其实不算真正理解 channel：
ch := make(chan int, 10)
ch <- 1
v := <-ch
_ = v
真正的难点从来不是'怎么写'，而是'它在什么状态下会阻塞、什么时候会 panic、为什么 close 可以做广播、为什么有些 goroutine 会莫名其妙泄漏'。
Go 后端里，channel 一般出现在这几类地方：
- 任务投递和 worker 协作。
- 请求超时与取消控制。
- 多 goroutine 之间的结果汇聚。
- 服务关闭时的广播通知。
- 有界并发控制。
这些场景背后，其实都不是'单纯传个值'那么简单，而是在依赖 channel 的同步语义和调度行为。
所以如果你只记住
