用runtime.MemStats定位异步任务队列性能卡顿：重点关注MemStats.Alloc（每秒增长超50MB说明对象未复用）和MemStats.NumGC（每秒超2次表明高频小对象压垮GC），配合sync.Pool缓存Task结构体可有效缓解。
怎么用 runtime.MemStats 看内存是否在“喂”任务队列
异步任务队列性能卡顿，80% 以上先出在内存分配上——不是 CPU 不够，而是每秒几万次 new(Task) 或 json.Unmarshal 把 GC 压垮了。直接看 runtime.MemStats 是最快定位手段。
- 重点关注
MemStats.Alloc和MemStats.TotalAlloc：如果每秒增长超 50MB，说明任务结构体或序列化对象没复用 -
MemStats.NumGC每秒超过 2 次，基本可判定是高频小对象分配导致的 GC 频繁触发 - 用
sync.Pool缓存任务结构体时，注意New函数不能带闭包或依赖外部状态，否则会泄漏 goroutine
怎么抓 goroutine 阻塞点而不是只看数量
runtime.NumGoroutine() 数值高≠有问题，关键是看它们卡在哪。真正要查的是阻塞型系统调用和 channel 等待。
- 启用
-blockprofile=block.out运行程序，复现压测后执行go tool pprof block.out，重点看 top 函数里有没有chan receive或selectgo占比过高 - 如果大量 goroutine 停在
runtime.gopark且调用栈含io.ReadFull或http.Transport.RoundTrip，说明下游 API 响应慢，但 worker 没设 timeout - worker 启动时没加
defer func() { recover() }()，一旦 panic 就静默退出，表面 goroutine 数下降，实际是消费能力漏损
怎么验证 Redis Streams 消费延迟是不是真瓶颈
别一看到 “延迟高” 就优化 Go 代码——先确认延迟到底在链路哪一环。Redis Streams 的 XREADGROUP 调用本身不慢，慢的是你没配对参数。
-
Block参数设成0（非阻塞）会导致空轮询，CPU 白耗；设成>5s又会让短任务堆积。建议按 P95 处理耗时 × 2 来设，比如平均 120ms 就设250ms -
Count太小（如1）会让网络往返放大 10 倍；太大（如1000）又可能让单次处理超时。实测10~50是多数场景的甜点区 - 用
XRANGE task-stream - + COUNT 1对比XINFO GROUPS task-stream里的pending数，若 pending 持续 > 1000 且idle时间长，说明消费者处理不过来，不是网络或 Redis 问题
怎么判断是任务逻辑慢还是调度器慢
一个常见错觉：把 processTask() 里加了日志说“这里花了 300ms”，就认定是业务逻辑问题。其实可能是调度器根本没及时唤醒它。
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.ReadTrace()生成 trace.out，打开后看 goroutine 生命周期：从 “created” 到 “runnable” 的间隔是否稳定 - 检查
GOMAXPROCS是否被设成 1 —— 这会让所有 worker 强制串行跑，吞吐量直接砍掉 90% - 如果 trace 里大量 goroutine 在 “goready” 后立刻进 “runnable”，但长时间不进入 “running”，大概率是 OS 层线程调度受干扰（比如容器里没配
cpu-quota）
真实压测中，最常被忽略的是 worker 池与下游服务之间的节奏错配：比如 Redis Stream 拉取快，但数据库写入慢，结果所有 goroutine 都堵在 db.Exec() 上，此时优化 Go 并发数毫无意义，得先加连接池上限或降 batch size。
