hchan中真正影响行为的字段是qcount、dataqsiz、buf、sendx、recvx、sendq、recvq和closed：qcount即len(ch)，dataqsiz即cap(ch)，buf为环形缓冲区起始地址（dataqsiz>0时非nil），sendx/recvx为环形索引，sendq/recvq挂sudog链表，closed标识关闭状态。
hchan 结构体里哪些字段真正影响行为
面试时别只背“hchan 是结构体”，得说清每个字段在 runtime 中干了什么。真正参与逻辑判断的就这几个：qcount、dataqsiz、buf、sendx、recvx、sendq、recvq 和 closed。其他如 elemsize、elemtype 主要用于内存拷贝和类型安全，不参与流程控制。
qcount 是当前缓冲区中元素个数，len(ch) 就直接返回它；dataqsiz 是 make 时传的缓冲大小，cap(ch) 返回它；buf 仅当 dataqsiz > 0 时非 nil，指向一块堆上分配的原始内存（不是 slice）；sendx/recvx 是环形索引，只在有缓冲时推进，取值范围固定在 [0, dataqsiz)；sendq 和 recvq 是双向链表，节点是 sudog，封装了 goroutine 指针和待传数据地址；closed 是 uint32，0 表示未关闭，close 后设为 1——这是判断 channel 是否真正关闭的唯一权威依据。
容易踩的坑：
- 误以为
sendx == recvx表示空或满：错，只看qcount，环形索引可能绕圈后重合 - 以为
buf是 slice：错，它是 raw memory，避免逃逸和 GC 压力 - 忽略
closed字段的原子性：它被 runtime 用 atomic.Store/Load 操作，不能靠if ch == nil或if len(ch) == 0推断关闭状态
无缓冲 channel 为什么收发必然阻塞
因为 dataqsiz == 0，所以 buf == nil，整个通信路径完全绕过缓冲区。发送时，chansend 会立刻检查 recvq.first：如果为空，且 block == true（即普通 ch ），就调用 <code>gopark 把当前 goroutine 挂起，并把它的 sudog 插入 recvq；接收同理，查 sendq.first，空则挂起进 sendq。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：无缓冲 channel 的 send/recv 操作不拷贝数据到 buf，而是直接交换指针和唤醒状态。数据从 sender 栈 → receiver 栈，中间不落地。
常见错误理解：
- “无缓冲 = 立即返回”：错，必须配对 goroutine 存在才能完成交接
- “阻塞是因为锁没释放”：错，锁只保护 hchan 字段访问，goroutine 挂起后锁已释放
- “可以靠 select default 避免阻塞”：对，但那是非阻塞语义，不是“无缓冲不阻塞”
有缓冲 channel 的三种发送路径
向有缓冲 channel 发送时，chansend 会按优先级尝试三条路径：
- 配对转发：若
recvq.first != nil，跳过buf，直接把数据从 sender 栈拷贝到 receiver 栈，然后唤醒 receiver —— 这是最高效路径，不占缓冲也不触发调度 - 缓冲入队：若
qcount ，把数据拷贝到 <code>buf[sendx]，更新sendx和qcount - 阻塞等待：若
qcount == dataqsiz且recvq.first == nil，才挂起 sender 到sendq
注意：full(c) 函数的实现就是先判 dataqsiz == 0（走 recvq 路径），再判 qcount == dataqsiz && recvq.first == nil。很多人误以为“缓冲有空位就不阻塞”，其实只要此刻有 goroutine 在 recvq 上等着，就会走配对转发，根本不动缓冲区。
close 后还能读到零值？关键看 qcount 和 closed
channel 关闭后，closed 被设为 1，但读操作是否返回零值，取决于两个条件：
- 若
qcount > 0：仍从buf[recvx]拷贝数据，qcount减 1，recvx加 1 —— 此时v, ok := 中 <code>ok == true - 若
qcount == 0：立刻返回对应类型的零值，v, ok := 中 <code>ok == false
典型错误是只写 v := 去读一个可能已关闭的 channel，结果持续拿到 <code>0、nil 或 ""，逻辑静默失败。更隐蔽的是：你 close 之后立刻 len(ch) 可能还是非零，因为 qcount 没清零，只是不能再写了。
最后提醒一句：hchan 总是分配在堆上（哪怕 ch 变量在栈上），因为要被多个 goroutine 共享访问；而 sendq/recvq 用双向链表不用 slice，就是为了规避 realloc 和 GC 干扰——这点常被忽略，但恰恰是 runtime 层面做性能取舍的关键证据。
