Asynq 是需搭配 Redis 的 Go 客户端库，非开箱即用服务；发任务前须显式配置 Redis 地址，否则静默失败；worker 需手动启动 Server 并阻塞运行；任务 payload 必须 JSON 可序列化且导出；默认重试机制易致任务“消失”于 retry 队列。
Asynq 不是开箱即用的“任务队列服务”，它本质是一个 Go 客户端库，必须搭配 Redis 才能运行；直接 go run 一个文件不会启动任何后台 worker，也不会自动消费任务。
为什么 asynq.Client 发任务后 Redis 里看不到任务？
默认情况下，asynq.NewClient 使用的是 asynq.DefaultRedisClientOpt，但如果你没显式传入 *redis.Options，它会尝试连接 localhost:6379 —— 很多本地开发环境根本没起 Redis，或者用了 Docker 网络别名（比如 redis:6379），导致任务静默失败。
- 检查是否真有 Redis 实例在运行：
redis-cli ping返回PONG - 初始化 client 时必须显式配置地址：
cli := asynq.NewClient(asynq.RedisClientOpt{Addr: "redis:6379"}) - 发任务后，用
redis-cli keys "asynq:*"查看是否有asynq:default这类 key；没有说明连接失败或任务被丢弃（Enqueue返回 error 但你没检查）
asynq.ServeMux 注册 handler 后 worker 为啥不执行任务？
注册 handler 只是定义了“这个任务类型该交给哪个函数处理”，但真正驱动消费的是 asynq.Server 实例，它需要你手动调用 Start 并保持进程运行 —— 它不是 goroutine 自启，也不是 daemon 进程。
- 必须显式创建并启动 server：
srv := asynq.NewServer( asynq.RedisClientOpt{Addr: "redis:6379"}, asynq.Config{Concurrency: 5}, ) srv.Run(mux) // 阻塞调用，不能漏 - 如果用
go srv.Run(mux)异步启动，主 goroutine 立即退出，整个进程就结束了 - worker 进程要和 producer 进程分开部署：一个进程只负责发任务，另一个（或多个）专门跑
srv.Run
怎么让 asynq.Task 带自定义参数又不被序列化失败？
Asynq 底层用 encoding/json 序列化任务 payload，所以字段必须是可 JSON 编码的类型（string、int、bool、map[string]interface{}、[]interface{}），且导出（首字母大写）。
立即学习“go语言免费学习笔记（深入）”；
- 不要传指针、函数、channel、struct 包含 unexported 字段 —— 会静默变成
null或报错 - 推荐定义明确结构体，并加
jsontag：type SendEmailPayload struct { To string `json:"to"` Subject string `json:"subject"` Body string `json:"body"` } task := asynq.NewTask("send_email", map[string]interface{}{"to": "a@b.c", "subject": "hi"}) // 可行但易错 // 更安全： payload, _ := json.Marshal(SendEmailPayload{To: "a@b.c", Subject: "hi"}) task := asynq.NewTask("send_email", payload) - handler 里反序列化也要对应：
json.Unmarshal(t.Payload(), &p)，别直接用t.Payload()当字符串拼接
最常被忽略的一点：Asynq 的重试机制默认开启，失败任务会进 asynq:retry 队列并按指数退避重试；如果你没配 OnFailure 或没查 asynq:failed，任务看似“消失”其实卡在重试中。调试阶段建议临时设 RetryCount: 0 或用 asynqmon Web UI 直接观察队列状态。
