用 slice 和两个 int 指针可高效实现环形队列：底层数组长度为逻辑容量+1，head 指向队首，tail 指向下一插入位；判空为 head==tail，判满为 (tail+1)%cap==head；所有数组访问前必须取模，长度计算用 (tail-head+cap)%cap。
用 slice + 两个 int 指针就能实现，不需要额外结构体封装
Go 里没有内置的环形队列，但用固定长度的 []T 配合头尾索引就能高效模拟。核心是把数组当“环”用：当指针走到末尾时，用取模运算绕回开头。
常见错误是直接写 head = (head + 1) % cap 却没处理空/满状态判断逻辑——这会导致无法区分队列空和满（因为两者都是 head == tail）。必须预留一个空位，或额外记录长度。
- 推荐预留空位法：容量为
n的底层数组，最多存n-1个元素 -
head指向队首元素，tail指向下一个可插入位置（初始都为 0） - 入队前检查
(tail+1)%cap == head，即“再加一个就撞上 head” - 出队后更新
head = (head + 1) % cap，无需移动数据
Enqueue 和 Dequeue 的边界条件怎么写才不越界
越界不是因为索引算错，而是没统一好“是否已取模”。所有对数组的访问，索引必须先取模再使用；而判断逻辑里用的是原始差值（比如 size = (tail - head + cap) % cap），不能直接用 tail - head。
典型错误现象：panic: runtime error: index out of range，往往出现在 arr[tail] 或 arr[head] 这类访问时，tail 或 head 已经超过底层数组长度但还没取模。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次读写前都做
idx := index % cap，别图省事只在增减时取模 - 计算当前长度用
(tail - head + cap) % cap，加cap是为避免负数取模结果异常（Go 中-1 % 5 == -1） - 判空用
head == tail，判满用(tail+1)%cap == head
为什么不用 container/list 或 channel 替代
container/list 是双向链表，每个元素带两个指针，内存开销大、缓存不友好；channel 虽然底层有环形缓冲，但它是并发安全的，带锁和调度开销，且不支持随机访问或手动控制扩容逻辑。
如果你只是需要低延迟、零分配的固定大小缓冲（比如日志批量暂存、滑动窗口计数），自己写的数组+双指针版本性能更可控。
- 无 GC 压力：只要底层数组复用，
Enqueue/Dequeue都是纯数值运算 - 兼容性高：Go 1.0 就能跑，不依赖任何新特性
- 注意：它本身不并发安全，如需多 goroutine 使用，得外层加
sync.Mutex或改用atomic操作
示例代码里 cap 和 len 容易混淆的地方
底层数组用 make([]T, n) 创建，它的 len 和 cap 相等；但环形队列的“逻辑容量”是 n-1。很多人误把 len(q.data) 当作可用空间，结果导致满判定失效。
错误写法：if len(q.data) == q.size { ... } —— 这里 q.size 如果是按逻辑容量设的，就会漏判。
- 始终用一个常量表示底层数组长度，比如
const capacity = 1024 - 所有取模运算都基于这个常量，不是
len(q.data) - 初始化时明确：底层数组长度 = 逻辑容量 + 1，例如要存最多 100 个元素，就
make([]int, 101)
事情说清了就结束
