Go高并发队列常见竞态问题包括静默丢任务、重复消费、计数漂移和goroutine泄漏；根本原因在于wg.Add()误放goroutine内、多goroutine关闭同一chan导致panic，须确保Add在go前调用且channel仅由最后一个生产者或主goroutine关闭。
Go 高并发队列一旦出现竞态，往往不是 panic 报错，而是静默丢任务、重复消费、计数漂移或 goroutine 泄漏——这些问题在线上压测或大促时才集中爆发，但根因早在写 go process(task) 那一刻就埋下了。
为什么 sync.WaitGroup.Add() 放在 goroutine 里就出事
这是队列消费模型中最常踩的坑：主 goroutine 启动 worker 时，把 wg.Add(1) 写在 go func() { ... }() 内部。结果是 wg.Wait() 可能提前返回，部分 worker 还没真正开始执行，程序就退出了。
根本原因在于：Add() 和 goroutine 启动之间没有 happens-before 关系，调度器可能先跑 wg.Wait()，再调度新 goroutine。
- 必须在
go语句之前调用wg.Add(1)，哪怕要循环启动 100 个 worker，也得先wg.Add(100) - 如果 worker 数量动态决定（比如从配置读），用工厂函数封装：先
wg.Add(1)，再go worker(...)，确保顺序 - 绝不在 goroutine 内调用
wg.Add()，哪怕加了mu.Lock()也不行——WaitGroup 本身不是为并发调用Add()设计的
chan Task 被多个 goroutine close() 就 panic
当多个 worker 共享一个输入 channel，并各自判断“任务取完了”就去 close(tasksCh)，Go 会直接 panic：panic: close of closed channel。这不是竞态检测器能报出来的错误，而是运行时确定性崩溃。
立即学习“go语言免费学习笔记（深入）”；
典型场景：扇入模式中，多个生产者往同一 channel 发送，但没人明确负责关闭；或者 worker 错误地把“自己退出”等同于“队列结束”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- channel 关闭权必须唯一：只由**最后一个完成生产的 goroutine** 关闭，或由主 goroutine 统一控制
- worker 应该用
for task, ok := 消费，不主动 close - 如果要用 context 控制生命周期，用
select { case 退出，而非 close channel
用 go run -race 检测不到的队列竞态
go run -race 对纯 channel 通信路径覆盖有限。它能抓到对共享变量（如 counter）的并发读写，但抓不住以下三类真实队列问题：
- channel 缓冲区溢出导致的非阻塞写失败（
select { case ch 中 default 分支被误跳过） - 多个 goroutine 同时向同一个无缓冲 channel 发送，但接收端只有一个，造成部分发送永久阻塞（死锁前兆）
- worker 未处理
context.Canceled就继续从 channel 取任务，导致任务被重复分发或超时后仍执行
这类问题得靠结构化日志 + 指标监控：给每个任务打唯一 traceID，记录入队时间、出队时间、处理耗时；用 Prometheus 暴露 queue_length、task_dropped_total、worker_idle_seconds 等指标，比等 -race 报告更早发现问题。
map 当队列状态缓存时的并发写 panic
有些实现会用 map[string]*Task 缓存待处理任务 ID，方便去重或查状态。但 Go 的 map 天然不支持并发读写——只要两个 goroutine 一个 range 一个 delete，立刻 fatal error: concurrent map read and map write。
别信“我只读不写”或“写很少”，runtime 一旦检测到并发访问，不管概率多低，都 panic。
- 优先用
sync.Map替代原生map，尤其适合读多写少、key 动态增删的队列元数据场景 - 若需强一致性（比如任务状态机），改用
sync.RWMutex包裹普通map，读操作用Rlock()，写操作用Lock() - 避免在
defer中操作共享map：goroutine 退出时的defer和另一个正在运行的 goroutine 可能同时触发写
队列的并发安全，本质是把“谁在什么时候有权修改什么”这条线划清楚——不是所有地方都要加锁，但每个共享状态的访问契约，必须在代码里写死、在测试里验证、在线上用指标盯住。
