chan适用于单机低频可丢任务场景；需缓冲和消费者goroutine防阻塞；asynq/machinery用于持久化跨进程等需求，配置错误易致任务不消费或注册失败。
chan 适合单机、低频、可丢任务的场景；一旦要持久化、跨进程、延时或失败重试，就得换 asynq 或 machinery。
用 chan 做队列为什么一发就卡死？
常见现象是 taskCh 永久阻塞，主流程挂住。根本原因就两条：没缓冲 + 没人消费。
-
make(chan Task)是无缓冲的，发送立刻阻塞，除非同时有 goroutine 在 -
make(chan Task, N)的N是缓存上限，不是“最多存 N 个”——超了照样阻塞发送方 - 必须配至少一个持续
for range taskCh的 goroutine，只读一次就退出等于没写 - 别在 worker 里直接调用耗时函数，建议包装成 goroutine 或扔进固定池，否则阻塞整个 channel
asynq 启动了但任务不消费？先查这三处
日志里没 Started processing，或报 redis: nil pointer dereference，基本是配置漏项。
-
asynq.NewServer必须传完整asynq.RedisClientOpt{Addr: "localhost:6379", Password: "xxx", DB: 0}，空结构体不行 - 发任务时用了
asynq.Queue("high")，Server 就得显式声明asynq.Queues(map[string]int{"high": 5}) - Redis 连接不校验会静默失败——启动前加一行
redisClient.Ping(ctx)，别信默认值 -
Concurrency不是越大越好，设 100 可能让 Redis QPS 扛不住，压测前先看 CPU 和 Redis 监控
machinery 注册任务总失败？签名和协议必须严丝合缝
worker 日志停在 waiting for tasks，大概率是 broker 配错或函数签名不合法，而且它不报错，只沉默。
立即学习“go语言免费学习笔记（深入）”；
- 任务函数只能是包级纯函数，签名严格为
func(interface{}) error，不能带接收器、不能多返回值 - broker 地址必须带协议：
redis://123456@localhost:6379/0✅，localhost:6379❌ - broker 和 result_backend 别用同一个 Redis 实例同一 DB，推荐 broker 用
/0，backend 用/1或memcache:// -
Args.Type只能填基础类型名："string"、"int"、"bool"——"[]byte"或自定义类型名都会导致 worker 收不到任务
需要优先级？别手写堆，直接用 container/heap
自己实现堆容易索引越界、比较逻辑翻转、并发不安全；标准库 container/heap 只要补五个方法，就能稳定工作。
- 必须实现
Len、Less、Swap（值接收者），以及Push、Pop（指针接收者） -
Less(i, j)返回true表示 i 优先级更高，所以数字越小越先执行就写p[i].Priority -
heap.Pop(&pq)返回的是被弹出的最高优先级元素，不是新堆顶——别漏掉它 - 并发场景下，
Push/Pop必须用sync.Mutex包裹，但 Work 函数要在锁外执行，否则卡死其他任务
真正难的不是选哪个方案，而是判断「这个任务丢了能不能接受」——channel 里丢一个发邮件任务可能只是延迟几秒，丢一个支付回调就是资损。别等线上报警才回头改队列。
