go channel环形缓冲区由buf、dataqsiz、sendx、recvx四个字段协同模拟：buf为线性数组指针，dataqsiz为容量，sendx/recvx为回绕游标，qcount为辅助计数器避免模运算。
Go 的 channel 缓冲区不是硬件或内存层面的“环形”，而是靠 sendx、recvx、qcount 和 buf 四个字段在普通线性数组上模拟出来的。
环形缓冲区靠哪几个字段协同工作
真正撑起“环形”语义的只有四个字段：buf（底层数组指针）、dataqsiz（容量）、sendx（写位置）、recvx（读位置）。qcount 是辅助计数器，避免每次判空满都做模运算。
-
buf指向堆上一块连续内存，本质就是make(chan int, N)分配的N个元素大小的数组，本身完全线性 -
sendx和recvx始终在[0, dataqsiz)范围内递增，到头就回绕归零——这才是“环”的来源 -
qcount记录当前已存元素数，比如qcount == 0就是空，qcount == dataqsiz就是满，不用算(sendx - recvx) % dataqsiz - 当
dataqsiz == 0（即无缓冲 channel），buf为nil，sendx/recvx不再参与数据搬运，直接走 goroutine 阻塞/唤醒路径
为什么不用真实环形内存而用游标模拟
Go 运行时不依赖特殊内存布局，所有字段都是普通结构体成员，好处是 GC 友好、分配简单、跨平台一致。真实环形内存（如某些嵌入式 ring buffer）需要定制分配器或 mmap 对齐，对 Go 的内存模型和垃圾回收器反而是个负担。
- 游标方式让
send和recv操作都能做到 O(1) 时间复杂度，且无锁路径下也能安全更新qcount - 如果真用物理环形内存，每次读写都要处理地址跳变，GC 在扫描
buf时也得理解“逻辑连续但物理断开”，实现成本高 -
qcount是关键优化：高并发场景下，频繁判断 channel 是否可读/可写，靠它省掉大量模运算，实测能降低约 8% 的调度开销
sendx/recvx 回绕时的数据搬运逻辑
回绕不是靠 memcpy 移动数据，而是靠索引计算把新数据“覆盖”到旧位置，整个过程不搬动已有元素。
- 假设
dataqsiz == 4，初始sendx == 0,recvx == 0，写入 4 个值后：sendx == 0（回绕），qcount == 4 - 此时再读一个，
recvx从 0 → 1，qcount从 4 → 3；再写一个，sendx从 0 → 1，新值直接写入索引 1 位置，覆盖掉最早那个值（FIFO 语义） - 注意：这种覆盖只发生在有缓冲 channel 且
qcount == dataqsiz时；无缓冲 channel 或未满的有缓冲 channel，永远不覆盖，只追加 - 如果 channel 已满且没有 receiver，sender 会挂到
sendq等待，而不是强行覆盖——覆盖行为仅由接收者推进recvx触发
真正容易被忽略的是：sendx 和 recvx 的更新不是原子操作，它们受 hchan.lock 保护；但 qcount 在 fast-path 上会先用原子操作试探，失败才加锁——这个细节决定了高争用下 channel 的吞吐表现。
