17370845950

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 压力未评估。

真正难的不是“怎么放进去”，而是“怎么不丢、不错、不卡、不爆内存”。这些细节往往藏在压测和长周期运行里，不是写完就能验证的。