必须用xadd的maxlen参数实时限流，因其与xadd组成原子操作，插入即裁剪最老消息；xtrim仅事后补救，存在窗口期且不自动重复；maxlen位置错误会报语法错，~n为近似上限，spring boot需手动执行原生命令并配置监控。
必须用 XADD 的 MAXLEN 参数，否则消息堆积就是时间问题。 单靠 XTRIM 定时清理是补救，不是防控；它不实时、不原子、不防爆内存。
为什么MAXLEN必须和XADD一起写，不能事后补
MAXLEN 是唯一能在写入瞬间完成裁剪的机制。它和 XADD 组成原子操作：插入新消息 → 立即检查长度 → 超限时同步删最老消息 → 内存立刻释放。
-
XTRIM是独立命令，执行时机由你控制，中间存在窗口期——两秒内可能已积压上万条 -
XTRIM mystream MAXLEN 1000只删一次，不会自动重复；也没有触发监听，无法感知新消息写入 - 如果程序只发
XADD mystream * field value（没带MAXLEN），再怎么定时XTRIM都晚了
MAXLEN语法位置错一个字符就报错
Redis 对 MAXLEN 在 XADD 命令中的位置极其敏感，放错直接返回 ERR Syntax error，不是静默忽略。
- ✅ 正确：
XADD mystream MAXLEN 1000 * field value - ✅ 正确（指定 ID）：
XADD mystream MAXLEN 1000 1624567890000-0 field value - ❌ 错误：
XADD mystream * MAXLEN 1000 field value（*后不能插MAXLEN） - ❌ 错误：
XADD mystream 1624567890000-0 MAXLEN 1000 field value（ID后不能跟MAXLEN）
MAXLEN ~N 和 MAXLEN N 实际行为差异
两者都用于限长，但策略不同，影响精度与性能：
-
MAXLEN 1000：严格上限，写入第 1001 条时，必定删掉最老的 1 条，保证 Stream 永远 ≤ 1000 条 -
MAXLEN ~ 1000：近似上限，实际可能保留 1000 或 1001 条；内部跳过部分索引检查，O(1) 开销更低，适合高吞吐场景 - 别混用：
XADD ... MAXLEN ~1000+ 后台XTRIM ... MINID，可能重复裁剪，白耗 CPU
Spring Boot 中绕过StreamOperations.xAdd()不支持MAXLEN的限制
Spring Data Redis 的 StreamOperations.xAdd() 方法没有暴露 MAXLEN 参数，得手动拼命令或换方式：
- 用
redisTemplate.execute()执行原生命令：XADD mystream MAXLEN 1000 * field value - 把
max-len: 1000提到application.yml配置里，避免硬编码，上线后可动态调参 - 务必配监控：
MEMORY USAGE mystream+XINFO STREAM mystream查看增长斜率；1000 条只是起点，高流量下可能要调到 5000+ - 漏掉
XACK会导致待处理消息堆积，MAXLEN和XTRIM都救不了——这点最容易被忽略
真正卡住人的从来不是“怎么加 MAXLEN”，而是忘了它只管“写入时裁最老的”，不管“谁读过没读过”。消费端不 XACK，数据就一直挂着，MAXLEN 删的只是新来的压力，不是积压本身。
