结论：面试考察channel底层重在串联hchan结构、阻塞逻辑、关闭行为与并发安全四点；buf仅在dataqsiz>0时有效，sendx/recvx仅用于有缓冲channel，无缓冲channel依赖sendq/recvq直接配对唤醒，closed需通过close()变更且重复调用panic。
直接说结论：面试问 channel 底层，不是考你背源码，而是看你能不能把 hchan 结构、阻塞逻辑、关闭行为和并发安全这四点串成一条线——漏掉任意一环，就容易被追问到卡壳。
hchan 结构里哪些字段真影响行为？
别一上来就列全字段。面试官想听的是「哪个字段决定我写代码时会不会卡住」。
-
buf是unsafe.Pointer，但只有dataqsiz > 0时才真正分配内存；dataqsiz == 0（无缓冲）时，buf可能非 nil，但完全不参与数据暂存 -
sendx和recvx是环形缓冲区的游标，只在有缓冲 channel 中有效；无缓冲 channel 的通信靠sendq/recvq直接配对唤醒 -
closed是 uint32，但判断是否关闭不能靠读它——必须用close()触发状态变更，且重复 close 会 panic:close of closed channel
为什么无缓冲 channel 写操作会阻塞？
因为底层根本没地方存数据。发送方 goroutine 必须等到接收方 goroutine 准备好，才能完成一次原子交接。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 写
ch 时，runtime 先尝试从 <code>recvq取一个等待接收的 sudog；取到了，直接拷贝数据 + 唤醒 receiver，不进 buf - 没取到，就把当前 goroutine 包装成 sudog 挂到
sendq尾部，然后 park —— 这就是阻塞的实质 - 注意：
len(ch)对无缓冲 channel 永远是 0，不能用来判断“能否写”，这是常见误判点
close() 后还能读几次？
不是“立刻返回零值”，而是“读完缓冲区剩余数据后，再开始返回零值+false”。
- 有缓冲 channel：
close(ch)后仍可读qcount次，每次返回真实值；第qcount + 1次起才返回(T{}, false) - 无缓冲 channel：
close(ch)后若无人正在 send，下一次立即返回 <code>(T{}, false)；但如果 sendq 里还有等待的 sender，那些 goroutine 会被唤醒并 panic -
for range ch的退出时机 =closed == 1 && qcount == 0，二者缺一不可
select { case ch
不是。它只是跳过当前 select，并不保证后续 send 不阻塞，也不反映 channel 实际可写性。
- 这个写法只在「此刻 sendq 为空且缓冲区未满」时成功；但
select判定和真正 send 之间存在竞态窗口 - 如果 receiver 在
default分支执行后立刻退出，或缓冲区刚好被另一个 goroutine 填满，下次 send 依然会挂住 - 真正可控的非阻塞写只有两种：带超时的
select（case ch ），或对有缓冲 channel 配合 <code>len(ch) —— 但后者仍需加锁保护，实际很少单独用
最易被忽略的一点：所有对 hchan 字段的读写都受 lock 保护，但 lock 的粒度是整个 channel，不是 buf 或队列节点。这意味着高并发写同一 channel 时，sendq 唤醒和 recvq 唤醒可能串行化，吞吐瓶颈不在内存而在锁竞争。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
