Go channel 底层用 hchan 结构体实现，含环形缓冲区、sendq/recvq 双向链表（节点为 sudog）、互斥锁及计数器；有缓冲时分配 buf 内存，无缓冲则直接 goroutine 阻塞交接。
Go channel 底层用什么数据结构实现
channel 不是简单的队列或锁包装，它底层是 hchan 结构体，包含环形缓冲区（buf）、等待队列（sendq/recvq）、互斥锁（lock）和计数器（qcount, dataqsiz）。有缓冲 channel 的 buf 是 malloc 出来的数组；无缓冲 channel 的 buf 为 nil，收发直接走 goroutine 阻塞交接。
关键点：环形缓冲区不是 slice，而是固定大小的原始内存块，避免逃逸和 GC 压力；sendq 和 recvq 是双向链表，节点是 sudog —— 封装了 goroutine 指针、待传值指针、唤醒状态等信息。
- 无缓冲 channel 的 send/recv 操作必然导致 goroutine 挂起（除非配对 goroutine 正在等待），此时不拷贝数据，只交换指针和状态
- 有缓冲 channel 在缓冲未满/未空时，只操作
buf和qcount，不涉及 goroutine 调度 -
hchan本身分配在堆上（哪怕 channel 变量在栈上），因为要被多个 goroutine 共享访问
close(chan) 后还能读不能写，但为什么读完零值还能继续读
关闭 channel 只是把 closed 标志置为 1，并唤醒所有阻塞在 recvq 上的 goroutine。后续读操作会立刻返回：若缓冲区还有数据，先取数据；缓冲区空了，就返回元素类型的零值（如 0、nil、""），且 ok == false。
常见错误现象：for range c 能安全遍历完再退出，但手动 <-c 忘记检查 ok，就会持续拿到零值，逻辑出错。
立即学习“go语言免费学习笔记（深入）”；
- 写已关闭的 channel 触发 panic:
send on closed channel - 读已关闭且空的 channel 不 panic，但返回零值 +
false，必须显式检查第二个返回值 - close(nil channel) 直接 panic，和 map 类似，操作前务必判空（虽然一般不会 nil）
select + channel 阻塞时，case 的执行顺序有保证吗
没有。当多个 case 都 ready（比如多个 channel 都有数据可读、或都未满可写），Go 运行时会**伪随机选择一个**，不是按代码顺序，也不是按优先级。这是为了防止隐式依赖顺序引发的竞态或死锁。
这意味着：不能靠 case 位置来“兜底”或“降级”，比如把 default 放最后并不等于“最后才执行”。
-
select中所有 channel 操作都是非阻塞检测，一旦有任意一个可执行，就立即执行对应分支，其余不评估 -
default分支存在时，select 永远不会阻塞；不存在时，才会挂起当前 goroutine 等待任一 case 就绪 - 如果需要确定顺序（比如优先读 A，A 没数据再读 B），得用两次单独的 select + default，或加锁协调
大量小 buffer channel 会不会吃光内存
会，但不是因为 channel 本身，而是缓冲区分配 + goroutine 阻塞链表累积。每个有缓冲的 channel 至少占用 dataqsiz * sizeof(T) 字节的 buf 内存；而每个阻塞的 sender/receiver 会生成一个 sudog（约 300+ 字节），还带栈快照引用。
典型踩坑场景：启动成百上千 goroutine 往一个容量小但无消费者 channel 里发数据，结果 buf 满了，所有 sender 挂在 sendq 上，sudog 和关联栈内存不断增长，OOM。
- 无缓冲 channel 不分配
buf，但高并发下sudog链表一样可能堆积 - channel 容量设为 1 并不比 0 更“轻量”，只要存在缓冲，就要分配内存；真正省内存的是“不用”或“用完即关”
- 用
runtime.ReadMemStats观察Mallocs和HeapInuse，比凭感觉更准
channel 的复杂性不在语法，而在它把内存管理、调度、同步全耦合进一个类型里。很多人调通了逻辑就以为懂了，其实连为啥 close 后还能读、select 为何不按顺序执行都没意识到——这些才是真正在 runtime 里咬住你的时间和内存的地方。
