本文详解如何利用 redis 的 `brpop` 命令让 go 后台服务高效、低开销地等待列表数据就绪，避免轮询，并指出常见错误（如参数缺失和错误处理颠倒）导致的“伪阻塞”问题。
在构建异步任务系统（例如 Node.js 前端入队 + Go 后台消费）时，Redis 列表配合阻塞命令是轻量级解耦的经典方案。关键在于：BRPOP 本身即为真正的阻塞操作——只要调用正确，它会挂起当前连接直到指定列表非空或超时，无需循环重试，也绝不会对 Redis 造成额外压力。
你的原始代码逻辑方向正确（无限循环 + BRPOP），但存在两个致命细节问题：
- BRPOP 参数数量错误：BRPOP key timeout 至少需要两个参数（键名 + 超时秒数）。你仅传了 “q:test”，Redis 返回 ERR wrong number of arguments 错误，导致 Cmd() 立即返回错误而非阻塞，外层 for 循环便高速空转——这才是“不停打印”的根源，而非 BRPOP 失效。
- 错误与成功逻辑混淆：你将 err != nil 分支当作“无错误”处理，掩盖了真实报错，使调试困难。
✅ 正确做法如下（使用现代 Radix v4 推荐方式，兼容性更好且更安全）：
