goroutine不能直接替代消息队列，因其无持久化、进程崩溃即丢失、无法追踪状态；可靠异步需解耦+持久化+可追溯，须配合redis stream等中间件实现ack、重试与幂等。
为什么 goroutine 不能直接替代消息队列做异步任务
很多人一想到 Golang 异步，立刻写 go doSomething() —— 这在轻量、瞬时、无失败重试、不跨进程的场景下可行，但一旦涉及订单通知、邮件发送、第三方 API 调用，就容易丢任务。因为进程崩溃、机器重启、panic 未捕获时，内存里的 goroutine 全部消失，且无法追踪执行状态。
真正可靠的异步处理，核心是「解耦 + 持久化 + 可追溯」。所以生产环境必须搭配持久化中间件（如 RabbitMQ、Kafka、Redis Stream 或 PostgreSQL 表）来承载任务，goroutine 只负责消费端的并发执行层。
- 任务入队必须是同步写入（比如
redis.Client.XAdd返回成功才算入队成功） - 消费者启动后应使用
for range持续拉取，而非单次Read后退出 - 每条任务消费前先
ACK（如 Redis Stream 用XCLAIM或 PostgreSQL 用SELECT ... FOR UPDATE SKIP LOCKED）避免重复投递
用 Redis Stream 实现可重试的异步任务队列
Redis Stream 是 Golang 做轻量级异步任务的高性价比选择：天然支持消费者组、消息确认、失败重试、死信队列，且无需额外部署服务（相比 RabbitMQ/Kafka）。
关键点在于消费者组生命周期管理：
立即学习“go语言免费学习笔记（深入）”；
- 首次启动用
XGROUP CREATE创建组，避免NOGROUP No such key错误 - 消费时用
XREADGROUP GROUP <group><consumer> COUNT 10 BLOCK 5000 STREAMS <stream> ></stream></consumer></group>，>表示只读新消息 - 处理失败时调用
XACK不要提前执行；应先完成业务逻辑，再XACK，否则消息会丢失 - 超时未
ACK的消息会被XCLAIM重新分配，需在代码中处理“重复消费”幂等性（例如用task_id写SETNX做去重）
示例片段（省略错误处理）：
msgs, _ := rdb.XReadGroup(ctx, &redis.XReadGroupArgs{
Group: "orders",
Consumer: "worker-01",
Streams: []string{"order_events", ">"},
Count: 10,
Block: 5000,
}).Result()
for _, msg := range msgs[0].Messages {
handleOrderEvent(msg.Values)
rdb.XAck(ctx, "order_events", "orders", msg.ID) // 成功后才 ACK
}
sync.WaitGroup 和 context.WithTimeout 在批量异步任务中的误用陷阱
常见错误是用 WaitGroup 控制一组 goroutine 执行，却忽略上下文取消和超时——导致主流程已超时返回，后台 goroutine 仍在跑，甚至引发资源泄漏或重复写库。
正确做法是让每个子任务同时响应 context.Context：
- 不要只靠
WaitGroup.Done()判断完成，而要用select { case 主动退出 - 数据库操作、HTTP 请求等阻塞调用必须传入带 timeout 的
ctx，例如http.NewRequestWithContext(ctx, ...) - 如果任务本身不可中断（如正在写大文件），需在
defer中清理临时资源，并记录ctx.Err()状态供后续补偿
反例：go func() { defer wg.Done(); heavyIO() }() —— 完全无视上下文；正例应为 go func(ctx context.Context) { ... select { case 。
如何设计一个带优先级与延迟的异步任务系统
纯 FIFO 队列无法满足运营活动推送（高优）、日志归档（低优）、定时优惠券发放（延迟）等混合需求。Golang 中较实用的组合方案是：Redis ZSET 做延迟队列 + 多个 Stream 按优先级分片。
- 延迟任务：把
task_id和执行时间戳（UnixMilli）作为 score 写入ZADD delay_queue <timestamp><task_json></task_json></timestamp>，另起一个 goroutine 每 100msZRANGEBYSCORE delay_queue -inf <now> LIMIT 10</now>扫描并转投对应 Stream - 优先级：定义
high_priority_stream、low_priority_stream，消费者按 CPU 核数比例分配 goroutine 数量（如 8 核机器，6 个协程消费 high，2 个消费 low） - 避免 ZSET 扫描压力过大：每次
ZRANGEBYSCORE后立即ZREM已取出的任务，而不是靠 score 自动过期
这个模型不依赖外部调度器，所有逻辑在 Go 进程内可控，适合中小规模业务快速落地。但要注意 ZSET 的 score 精度必须统一用毫秒，否则跨语言或跨服务时时间比较会出错。
真正难的不是并发数量，而是任务状态的一致性边界——比如「已入队但未消费」「已消费但未 ACK」「已 ACK 但业务失败」这三类状态，在监控和补偿流程里必须有明确标识和恢复路径。
