hchan结构体中buf、dataqsiz、sendx、recvx、qcount五个字段协同模拟环形缓冲区：buf为数组指针，dataqsiz是容量，sendx/recvx为回绕游标，qcount缓存元素数避免模运算。
hchan 结构体里哪几个字段撑起环形缓冲区
Go 的 channel 缓冲区不是靠特殊内存布局实现的，而是用五个普通字段协同模拟出来的： buf、dataqsiz、sendx、recvx、qcount。
其中：buf 是堆上一块连续内存（本质就是数组指针），dataqsiz 是你调用 make(chan int, N) 时传的 N；sendx 和 recvx 是两个游标，取值永远在 [0, dataqsiz) 范围内，写满自动回绕到 0；qcount 记当前元素个数，避免每次都要算 (sendx - recvx) % dataqsiz 判空满。
- 别误以为
buf本身是“环形”的——它只是普通线性内存，环形逻辑全靠sendx/recvx移动和qcount维护 -
qcount是关键优化点：无它就得频繁模运算，尤其在高并发场景下影响判断效率 - 如果
dataqsiz == 0（即无缓冲 channel），buf为 nil，sendx/recvx不再参与数据搬运，直接走 goroutine 阻塞唤醒路径
为什么 sendq 和 recvq 是 waitq 类型而非 slice
因为 channel 上阻塞的 goroutine 必须能被快速唤醒、安全移除，且不能依赖 GC 或栈逃逸——waitq 是一个由 *sudog 构成的链表结构，每个 sudog 封装了 goroutine 状态、待发送/接收的数据地址、关联的 channel 等元信息。
-
slice在扩容时会 realloc 内存，而阻塞中的 goroutine 可能正被调度器挂起，不能容忍底层指针突变 -
waitq的first/last指针允许 O(1) 入队、O(1) 唤醒首个等待者（如 recv 操作唤醒 sendq 头部的 goroutine） - 若用 slice 存 goroutine，还需额外锁保护长度和底层数组，反而增加竞争；
waitq配合hchan.lock已足够原子控制
关闭 channel 后，recv 和 send 行为怎么变
closed 字段是 uint32，close() 就是把它从 0 改成 1；但行为差异不在字段本身，而在 runtime 对它的检查时机和路径。
立即学习“go语言免费学习笔记（深入）”；
- 对已关闭的 channel 执行
ch ：立即 panic <code>"send on closed channel"，不进sendq，也不查buf - 对已关闭的 channel 执行
：若 <code>qcount > 0，照常取数据并返回 true；若qcount == 0，直接返回零值 + false（即v, ok := 中 <code>ok==false） - 注意：关闭后仍可安全读取剩余缓冲数据，这点常被误认为“关了就读不到”，其实只影响后续是否阻塞或返回 ok 标志
nil channel 在 select 中为什么永远不触发
因为 runtime 对 select 的每个 case 做静态判别时，发现 channel 指针为 nil，就直接跳过该分支——既不尝试加锁，也不入等待队列，相当于“永久不可就绪”。
- 这是有意设计，不是 bug：让开发者能用
ch = nil主动禁用某条通信路径（比如断连后停收消息） - 常见坑：把未初始化的
chan变量（值为 nil）直接扔进 select，结果该分支永远沉默，容易误判为逻辑卡死 - 调试技巧：打印
fmt.Printf("%p", ch)，nil channel 输出0x0，正常 channel 是非零地址
真正难啃的是 sendx/recvx 回绕与 qcount 更新之间的竞态边界，runtime 用单把 lock 串行化所有操作，但这也意味着高争用下会成为瓶颈——别指望靠增大 dataqsiz 来缓解锁竞争，它只影响缓冲能力，不减少锁持有时间。
