hchan是Go运行时管理channel的内部结构体，无法直接声明或访问；qcount对应len(ch)，dataqsiz决定cap(ch)，buf为环形缓冲区起始地址（仅dataqsiz>0时非nil），sendq/recvq挂阻塞goroutine，lock保证所有操作串行化。
hchan 是 Go 运行时内部结构，你无法直接声明、访问或修改它；所有 make(chan T, N) 调用背后都由 runtime 分配并初始化一个 hchan 实例，挂载在堆上。
hchan 的关键字段对应哪些运行时行为
看懂这几个字段，就能预判 channel 是否阻塞、len(ch) 为什么不准、close 后还能读到什么：
-
qcount就是len(ch)返回的值，表示当前缓冲区中实际存放的元素个数；它不统计正在 sendq/recvq 中等待交接的数据 -
dataqsiz决定cap(ch)：为 0 → 无缓冲 channel；>0 → 有缓冲，buf 数组长度即为此值 -
buf是unsafe.Pointer，只在dataqsiz > 0时非 nil；它不是 slice，而是原始内存块起始地址，读写靠sendx/recvx偏移计算 -
sendq和recvq是双向链表，节点是sudog（封装 goroutine 指针、待传值地址、唤醒状态等），不是数据本身；goroutine 阻塞时挂入对应队列，被唤醒时由goready触发，非轮询 -
lock是真实互斥锁，所有收发、close 操作都必须持锁；哪怕无缓冲 channel，也逃不开这把锁 —— 它保护整个hchan结构及关联的sudog字段
无缓冲 channel 的 buf 为什么是 nil
因为无缓冲 channel 不需要存储中间数据，收发必须同步完成：发送方 goroutine 直接把值交给接收方 goroutine 的栈帧，绕过 buf。此时 dataqsiz == 0，runtime 不分配 buf 内存，buf 恒为 nil。
- 这种“直接交接”不拷贝数据到堆，但会拷贝值本身（如
int拷 8 字节，*int拷指针值） - 若发送方在
ch 后立刻修改 <code>x所指向的内容（比如是*int或[]byte），接收方看到的可能是脏数据 —— 这不是 bug，是值拷贝语义下的正常行为 -
len(ch)在无缓冲 channel 上永远是 0，cap(ch)也是 0；别用cap(ch) - len(ch)算“剩余空间”，它在无缓冲场景下毫无意义
为什么 hchan 必须分配在堆上
channel 变量（如 ch := make(chan int, 10)）本身是个指针，它在栈上，但所指向的 hchan 实例一定在堆上。
- 多个 goroutine 可能同时访问同一个 channel，而 goroutine 栈生命周期不可控；堆分配保证
hchan生命周期独立于任意单个 goroutine -
sendq/recvq中挂的sudog也要跨 goroutine 存活，它们也分配在堆上 - 即使你把 channel 作为参数传给函数，传的是指针副本，底层仍指向同一块堆内存中的
hchan
真正容易被忽略的是：sendx 和 recvx 是环形偏移索引，不是线性数组下标；当它们走到 dataqsiz 边界时会回绕，但 runtime 不做边界检查 —— 错误的 unsafe 操作可能越界读写 buf 内存，且不会 panic，只会引发静默数据损坏。
