Go channel 适合流式任务分发和信号通知，但非通用队列；需动态扩容、遍历等场景应使用 sync.Mutex 封装的 slice 实现并发安全队列，避免用 channel 模拟队列行为，复杂需求优先选用成熟库。
channel 是并发队列的默认选择，但不是万能队列
Go 原生 channel 天然支持 goroutine 安全的生产/消费模型，适合做“流式任务分发”或“信号通知”，但它不是通用队列：容量固定、无法随机访问、不能遍历、关掉后无法重用。如果你需要带优先级、延迟投递、持久化或批量出队，channel 就得让位给自定义结构。
用 slice + sync.Mutex 实现可伸缩的并发安全队列
当需要动态扩容、查看长度、清空或按索引取值时，基于 []interface{} 的 slice 配合 sync.Mutex 更灵活。注意别直接暴露底层 slice——必须封装方法，否则外部仍可能并发读写引发 panic。
type ConcurrentQueue struct {
mu sync.Mutex
items []interface{}
}
func (q *ConcurrentQueue) Push(item interface{}) {
q.mu.Lock()
q.items = append(q.items, item)
q.mu.Unlock()
}
func (q *ConcurrentQueue) Pop() (interface{}, bool) {
q.mu.Lock()
defer q.mu.Unlock()
if len(q.items) == 0 {
return nil, false
}
item := q.items[0]
q.items = q.items[1:]
return item, true
}
-
Pop()用defer q.mu.Unlock()确保锁一定释放 - 避免在锁内做耗时操作（比如网络调用），否则会阻塞其他 goroutine
- 如果队列读多写少，可考虑
sync.RWMutex提升并发读性能
不要用 channel 模拟 slice 行为
有人试图用 chan interface{} 加缓冲区来“模拟队列”，再用 len(ch) 获取长度、用 for range ch 遍历——这是错的：len(ch) 只返回当前缓冲区剩余容量，不是队列长度；for range 会消费并关闭 channel，且无法重入。
- 错误示例：
len(myChan)≠ 当前待处理任务数 - 错误示例：
for v := range myChan会永久阻塞或 panic，除非明确 close - channel 的设计目标是“通信即同步”，不是“存储即队列”
复杂场景下优先选成熟库而非手写
如需支持 TTL、优先级、批量 ACK、磁盘落盘或分布式协调，别硬套 channel 或裸写 mutex 队列。像 github.com/panjf2000/ants/v2（协程池内置任务队列）或 github.com/RoaringBitmap/roaring（配合位图做去重队列）更可靠。自己实现容易漏掉边界：比如 Pop() 在空队列时未加超时、panic 恢复缺失、GC 压力未评估。
立即学习“go语言免费学习笔记（深入）”；
真正难的不是“怎么放进去”，而是“怎么不丢、不错、不卡、不爆内存”。这些细节往往藏在压测和长周期运行里，不是写完就能验证的。
