关键字段是qcount、dataqsiz、buf、sendx、recvx：qcount为当前缓冲元素数，dataqsiz决定是否带缓冲（>0则有缓冲），buf仅在有缓冲时非nil并指向环形内存，sendx/recvx为环形索引，仅在有缓冲时有效。
hchan结构体字段到底哪些是关键
直接看 runtime/chan.go 里的 hchan 定义，真正影响行为的字段就五个：qcount、dataqsiz、buf、sendx、recvx。其余如 closed、lock、recvq、sendq 是支撑机制，但不决定 channel 是“无缓冲”还是“有缓冲”。
判断一个 channel 是否带缓冲，只看 dataqsiz > 0；buf 在无缓冲时为 nil，有缓冲时指向一块连续内存；sendx 和 recvx 只在有缓冲时有效，它们构成环形队列的读写指针；qcount 是当前 buf 中实际元素个数，不是 sendx - recvx（因为要模运算），它是唯一能直接反映“满/空”状态的字段。
无缓冲 channel 的发送接收为什么必然阻塞
无缓冲 channel 的 buf == nil，dataqsiz == 0，所以任何发送或接收操作都无法落进缓冲区，必须立刻配对成功——即 sender 和 receiver 同时就绪，才能完成一次通信。否则 sender 会进入 sendq 等待，receiver 进入 recvq 等待。
- 调用
ch 时，runtime 调用 <code>chansend，发现dataqsiz == 0且recvq.first == nil（没人等着收），就把自己挂进sendq并休眠 - 调用
时同理，若 <code>sendq.first == nil，就挂进recvq - 一旦有 goroutine 唤醒对方，数据拷贝是直接从 sender 栈 → receiver 栈，不经过 buf
环形缓冲区怎么用 sendx/recvx 管理
有缓冲 channel 的 buf 是一块大小为 dataqsiz 的数组，sendx 和 recvx 都是 uint 类型索引，取值范围 [0, dataqsiz)，每次操作后自增并取模：sendx = (sendx + 1) % dataqsiz。
qcount 不是靠指针差算出来的，而是显式维护：发送成功时 qcount++，接收成功时 qcount--。这避免了负数模运算和边界判断开销。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 当
qcount == 0，channel 为空；qcount == dataqsiz，channel 为满 - 数据存放位置是
buf[sendx * elemsize]，读取位置是buf[recvx * elemsize] - 注意：
sendx和recvx永远不会相等（除非空），相等只出现在空状态（此时两者都为 0）或满状态（此时(sendx + 1) % dataqsiz == recvx）
select 语句里 nil channel 的行为怎么来的
select 编译时会对每个 case 的 channel 做静态检查：如果 channel 表达式求值结果为 nil，该分支被标记为“永远不可就绪”，运行时直接跳过，不参与轮询。
这不是 hchan 自身的逻辑，而是 selectgo 函数的调度策略——它只遍历非 nil 的 channel，对 nil channel 不调用 block 或 send 等底层函数，自然也不会触发 sendq/recvq 操作。
所以 ch = nil 后再 select { case ，这个 case 永远不会执行，哪怕 ch 曾经有数据也没用。这点容易误判，尤其在动态关闭 channel 场景下。
真正难调试的是 goroutine 泄漏：往已关闭的 channel 发送会 panic，但往 nil channel 发送只是永久阻塞，且不会报错，stack trace 里也看不到明显线索。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
