Go的channel环形缓冲区是逻辑模拟而非物理环形，底层为普通堆分配数组，通过sendx、recvx和qcount三字段协同实现；满/空状态唯一由qcount判定，覆盖写入仅在接收推进时发生，且close后缓冲区仍有效直至qcount归零。
环形缓冲区不是内存层面的“环”，而是靠字段模拟出来的
go 的 channel 缓冲区没有使用 mmap 对齐、硬件环形内存或特殊地址布局——它底层就是一个普通堆分配的线性数组，buf 字段指向它，dataqsiz 记录长度。所谓“环形”，完全由 sendx、recvx 和 qcount 三个字段协同实现：
-
sendx和recvx是整数游标，取值范围始终在[0, dataqsiz)内；写到末尾时，sendx不做模运算，而是显式重置为0 -
qcount是当前已存元素个数，用于直接判断空/满：qcount == 0表示空，qcount == dataqsiz表示满 - 不依赖
(sendx - recvx) % dataqsiz判定状态，避免高频模运算开销（实测降低约 8% 调度开销）
也就是说，你用 make(chan int, 4) 创建的 channel，其 buf 就是 4 个 int 大小的连续内存块，逻辑上的“绕圈”只发生在索引计算阶段，物理上毫无特殊。
sendx 和 recvx 回绕时不会 memcpy 移动数据
常见误解是：回绕 = 把旧数据搬走、腾出空间。实际完全不是这样。当 qcount == dataqsiz（缓冲区已满），再有接收操作发生时，recvx 前进一位，qcount 减 1；此时新发送的数据直接写入 buf[sendx] 位置（sendx 随后也前进一步），覆盖掉最老的那个值——整个过程不挪动任何现存元素。
- 覆盖行为仅由接收者推进
recvx触发，不是发送方主动“挤掉”旧值 - 若 channel 已满且无 receiver，sender 会挂到
sendq等待，而不是强行覆盖 - 这种覆盖只适用于有缓冲 channel；无缓冲 channel 的
buf为nil，根本不存在缓冲区逻辑
判断满/空不能看 sendx == recvx
新手最容易踩的坑就是把环形缓冲区当成“头尾相接即满/空”的朴素队列。在 Go 的实现中：sendx == recvx 只表示“索引重合”，它既可能对应空（qcount == 0），也可能对应满（qcount == dataqsiz）。真正唯一可信的状态依据只有 qcount：
- 满：仅当
qcount == dataqsiz - 空：仅当
qcount == 0 - 例如：
dataqsiz == 8，sendx == 3，recvx == 3，但qcount == 8→ 实际已满
所有运行时路径（包括编译器生成的 fast-path 检查）都以 qcount 为准，sendx/recvx 只负责定位地址，不承载语义。
close 后环形缓冲区仍有效，直到 qcount 归零
关闭 channel 并不立即清空缓冲区。调用 close(c) 后：
-
c.closed标志置为 1，唤醒所有阻塞在recvq上的 goroutine -
sendq中等待的 sender 全部 panic：send on closed channel - 但
buf仍存在，recvx和sendx继续可用，只要qcount > 0，后续仍能读出剩余数据 - 只有当所有缓冲数据被读完（
qcount == 0），再次读取才会返回零值 +false
所以环形结构的生命期严格绑定于 qcount 和关闭状态，不是独立存在的对象。真正难啃的是：并发读写下，qcount、sendx、recvx 的更新必须在 hchan.lock 保护下原子完成，而它们本身又不是原子变量——这正是 runtime 层锁粒度设计的关键权衡点。
