XREAD不返回新消息主因是参数错误：未设BLOCK导致非阻塞轮询，或游标用错（如硬编码0或$）；正确做法是显式指定BLOCK并动态维护消息ID游标。
为什么 XREAD 一直不返回新消息？
常见现象是程序调用 XREAD 后卡住，等了很久才收到数据，或者压根收不到——多半是因为没传对参数。Redis Streams 的阻塞逻辑依赖两个关键点：游标位置和阻塞时长。
-
BLOCK参数必须显式指定，比如BLOCK 0（永久阻塞）或BLOCK 5000（5秒超时），不加就变成非阻塞轮询，立刻返回空结果 - 游标不能用
0或$硬编码：用0会从头重读；用$是“只读新增”，但首次运行时若流为空，$等价于不存在，XREAD直接返回空且不阻塞 - 正确做法是首次用
XRANGE key - + COUNT 1拿最新 ID，取其值作为初始游标；后续都用上一次收到的最后一条消息 ID 加-1（例如1728456290123-0→1728456290123-1），才能确保不丢、不重
XREAD 和 XREADGROUP 到底该选哪个？
如果你只是单个消费者实时监听一个流，XREAD 足够轻量；但只要涉及多实例、故障恢复、或需要确认消费成功，就必须切到消费者组模型。
-
XREAD无状态：每次调用完全独立，崩溃重启后得自己维护游标，容易漏或重复 -
XREADGROUP自动记录每个消费者已读位置，支持ACK和PEL（待处理列表），适合生产级可靠消费 - 注意
XREADGROUP首次调用必须先XGROUP CREATE，且组名、消费者名不能含空格或特殊字符，否则报错NOGROUP No such key or consumer group - 性能上，
XREAD更低开销；XREADGROUP多一层元数据管理，但差异微乎其微，别为这点性能放弃可靠性
阻塞超时后怎么续读才不丢数据？
用 BLOCK 5000 之类有限超时很常见，但超时返回空结果时，如果直接拿旧游标重发请求，可能跳过中间新进的消息。
- Redis 不保证超时期间消息一定被推送给你，所以每次超时后，应先用
XREVRANGE key + - COUNT 1查当前最新 ID，再决定游标：如果最新 ID > 当前游标，说明有遗漏，需从当前游标重拉；否则继续用原游标 - 更稳妥的做法是始终用
$作为游标（只读新增），但前提是能接受首次启动时漏掉历史数据；若不能漏，就得在应用层持久化最后一次成功处理的 ID - 别依赖客户端时间戳做游标判断——Redis 服务端时间可能漂移，ID 才是唯一可靠序号
Python 里用 redis-py 调用 XREAD 的坑
官方库对 Streams 支持较晚，redis-py 4.0+ 才稳定，老版本会把消息 ID 解成字符串而非元组，导致解析出错。
- 确保安装
redis>=4.5.0，调用时传参格式必须是redis.xread({key: last_id}, block=0, count=1)，不是{key: [last_id]} -
last_id必须是字符串，如"1728456290123-0"，传None或0会被转成"0"，触发全量重读 - 返回结构是
[(key, [(id, {field:value})])]，嵌套三层，容易误取；建议解包时加if res:判断，避免IndexError - 连接池要设
decode_responses=False，否则二进制字段（比如图片 base64）可能被错误 decode 报错
游标不是时间戳，也不是偏移量，它是消息的唯一身份 ID；用错一次，轻则重复处理，重则永久跳过某条数据。线上环境务必让游标落地存储，别只存在内存里。
