XADD+XREAD无法保证消息不丢，因缺乏消费确认机制：消息读取后不进入Pending列表，崩溃时无法重投；可靠消费必须用XGROUP CREATE创建组、XREADGROUP读取（默认入Pending）、XACK显式确认三者缺一不可。
为什么直接用 XADD + XREAD 无法保证消息不丢
因为 Redis Streams 本身不提供“消费确认后才删除”的原子语义。单纯 XADD 发送、XREAD 读取，一旦消费者崩溃或网络中断，消息就永远滞留在流里，但没人知道它是否已被处理——这不是“可靠”，只是“持久化”。真正可靠的前提是：消息必须进入待处理状态（pending），且只有显式确认（XACK）后才从 pending 列表移除。
XREADGROUP 是可靠消费的起点，但必须配 XGROUP CREATE
没有消费者组，就谈不上消息归属和 ACK 管理。创建组不是一次性的可选操作，而是必须前置步骤，且需确保幂等：
- 首次运行时执行
XGROUP CREATE mystream mygroup $ MKSTREAM，$表示从最新位置开始消费；若想重放历史，改用0 - 重复执行同一
XGROUP CREATE会报错BUSYGROUP，所以代码里要捕获该错误并忽略，或先用XINFO GROUPS mystream检查是否存在 - 组名不能含空格或特殊字符，否则
XREADGROUP会静默失败（无报错，但返回空结果）
消费者必须用 XREADGROUP 并指定 NOACK 或手动 XACK
默认行为是“读即入 pending”，这是可靠性的核心机制。但很多人误以为读完就算消费完成，其实不然：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不加
NOACK：消息被读取后自动进入消费者组的 pending entries list，此时若进程崩溃，Redis 会保留这些 pending 消息，后续可用XPENDING查看并重新分配 - 加
NOACK：跳过 pending 阶段，相当于退化为普通XREAD，失去可靠性保障 - 必须在业务逻辑成功执行后，显式调用
XACK mystream mygroup <id>；若失败，应调用XCLAIM抢回超时 pending 消息，而非忽略
Go 客户端要用 github.com/go-redis/redis/v8，且注意 StreamReadGroupArgs 的坑
社区常用客户端对 Streams 的封装容易掩盖底层语义，比如：
-
redis.XReadGroup方法中，Count参数控制单次最多读几条，但若设为1而实际有 5 条 pending，它仍只返回 1 条——这会导致 pending 积压，必须轮询或增大Count -
Block时间单位是毫秒，但传0表示不阻塞，不是“永久等待”；真正永久阻塞得传-1（部分版本支持，v8.11+ 推荐用time.Second * 30这类明确值） - 消息 ID 在 Go 中是
redis.XMessage.ID字符串，但XACK必须用原始 ID（如"1698765432100-0"），不能用结构体指针或拼接字符串
可靠性不取决于吞吐量，而取决于你是否愿意为每条消息多写三行：读、处理、确认。漏掉 XACK 或没处理 XPENDING 恢复逻辑，再完善的架构也只是一层薄冰。
