直接用 sync.mutex 包裹切片操作仍不安全，因 append 可能扩容并替换底层数组指针，导致其他 goroutine 读到旧指针引发脏读、长度突变或 panic；须将切片与锁封装为不可分割单元，所有操作通过方法串行化。
为什么直接用 sync.Mutex 包裹切片操作还不够安全？
因为切片底层是三元组（ptr、len、cap），append 可能触发底层数组扩容并替换 ptr，此时即使加锁，旧指针仍可能被其他 goroutine 读到脏数据。常见现象是队列长度突变、元素丢失或 panic：「concurrent map read and map write」（虽然没用 map，但类似竞态逻辑）。
实操建议：
- 锁必须覆盖所有访问切片的路径——包括
len()、cap()、索引读写、append、copy - 避免在锁内做耗时操作（如网络调用、文件读写），否则阻塞整个队列
- 不要把切片本身作为字段暴露出去（如返回
[]func()），否则锁失效
如何封装一个带锁的函数队列结构体？
核心是把切片和互斥锁绑定为一个不可分割的单元，所有操作都通过方法暴露。典型结构如下：
type FuncQueue struct {
mu sync.Mutex
tasks []func()
}
<p>func (q *FuncQueue) Push(f func()) {
q.mu.Lock()
defer q.mu.Unlock()
q.tasks = append(q.tasks, f)
}</p><p>func (q *FuncQueue) Pop() (f func(), ok bool) {
q.mu.Lock()
defer q.mu.Unlock()
if len(q.tasks) == 0 {
return nil, false
}
f, q.tasks = q.tasks[0], q.tasks[1:]
return f, true
}</p><p>func (q *FuncQueue) Len() int {
q.mu.Lock()
defer q.mu.Unlock()
return len(q.tasks)
}</p>
注意点：
-
Pop用q.tasks[0]+q.tasks[1:]实现 FIFO，不是pop末尾（那是栈） - 返回
(f func(), ok bool)是 Go 惯用法，避免 nil 函数被误执行 - 不要在
Push或Pop中调用用户传入的f()——那是使用者的责任，否则锁粒度失控
用 channel 替代切片是否更简单？
是，但有隐含代价。例如：chan func() 天然线程安全，无需显式锁：
queue := make(chan func(), 100)
go func() {
for f := range queue {
f()
}
}()
// 生产端
queue <p>问题在于：</p>
- channel 容量固定，满时
queue 会阻塞，除非用 <code>select+default做非阻塞写，但会丢任务 - 无法随机访问、无法遍历、无法获取当前长度（
len(ch)只返回已缓冲数量，不反映待处理数） - 关闭 channel 后再写会 panic，需额外状态管理
所以 channel 适合「纯生产-消费」场景；若需查询长度、批量清空、暂停调度，还是得回到带锁切片。
性能敏感时怎么优化锁竞争？
当队列频繁被多 goroutine 读写，sync.Mutex 可能成为瓶颈。可考虑：
- 用
sync.RWMutex：如果读远多于写（比如监控系统定期查队列长度），Len()改用RLock()，Push/Pop仍用Lock() - 分段锁（sharding）：把一个队列拆成 N 个子队列，哈希路由任务，降低单锁争用——但破坏 FIFO 顺序，慎用
- 无锁方案（如
atomic.Value存切片指针）：可行但复杂，且 Go 切片不可原子更新，实际仍需配合 CAS 循环，易出错，普通业务不推荐
真正容易被忽略的是：别过早优化。先用 sync.Mutex 实现，压测确认锁是瓶颈后，再考虑升级。多数服务每秒几百次队列操作，Mutex 完全够用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
