MAXLEN是Redis Streams唯一实时限长方式，必须与XADD原子配合使用；~N为近似保留，N为严格上限；XTRIM仅作兜底，非实时；语法中MAXLEN须紧随stream名后，错位即报错。
MAXLEN 是唯一靠谱的截断方式
Redis Streams 本身不支持“队列满则阻塞写入”，只支持写入时主动丢弃老消息。真正起作用的只有 XADD 命令的 MAXLEN 参数，它在插入新消息的同时触发裁剪——不是后台定时清理，也不是写完再删，而是一次原子操作。
常见错误是以为 MAXLEN 能限制整个 Stream 的总长度，其实它只对本次 XADD 操作生效；如果用 LPUSH + LTRIM 那套思路去套 Streams，会发现根本没用——Streams 不吃那套命令。
-
MAXLEN ~ N表示“尽量保留 N 条”，但允许多一条（因 Redis 内部实现机制，实际可能为 N 或 N+1） -
MAXLEN N表示“严格最多 N 条”，超出部分立即丢弃 - 必须和
XADD一起用，单独执行XTRIM是补救手段，非实时控制
为什么不用 XTRIM 做实时限长
XTRIM 是独立命令，执行时机由你控制，无法嵌入写入流程。它适合做兜底清理或批量维护，比如凌晨跑个脚本统一收缩所有 Stream，但不能替代 MAXLEN 实现实时长度管控。
典型翻车场景：程序一边狂发 XADD（没带 MAXLEN），一边定时 XTRIM —— 两秒内可能已积压上万条，内存早就爆了。这时候 XTRIM 才姗姗来迟，毫无意义。
-
XTRIM mystream MAXLEN 1000只删一次，不自动重复执行 - 没有监听机制，无法感知新消息写入后是否超限
- 和
XADD非原子，中间有窗口期，可能被其他客户端插入
带 ID 的 XADD 必须小心 MAXLEN 位置
XADD 语法顺序很关键：MAXLEN 必须出现在 STREAM_NAME 之后、ID 和字段之前。一旦放错位置，Redis 直接报错 ERR Syntax error，而不是静默忽略。
尤其当你要指定消息 ID（比如用 1624567890000-0 做时间戳ID），容易把 MAXLEN 误写在 ID 后面，结果命令直接失败。
- ✅ 正确：
XADD mystream MAXLEN 1000 * field value - ✅ 正确（带 ID）：
XADD mystream MAXLEN 1000 1624567890000-0 field value - ❌ 错误：
XADD mystream * MAXLEN 1000 field value（报错） - ❌ 错误：
XADD mystream 1624567890000-0 MAXLEN 1000 field value（报错）
内存与性能的真实影响
启用 MAXLEN 不会降低单次 XADD 的耗时，反而略高一点——因为要同步做裁剪。但这是值得的代价：避免 Stream 无限膨胀拖垮内存，也防止 XREAD 扫描时卡住。
一个容易被忽略的点：Stream 的每个消息都带完整 ID 和字段结构，比纯字符串列表（如 LPUSH）内存开销大不少。10 万条消息可能占几十 MB，远超同数量级的 list。
- 别用
INFO memory看粗略值，用MEMORY USAGE mystream查真实占用 - 如果业务能接受“近似长度”，优先用
MAXLEN ~ N，减少裁剪频率 - 高频写入场景下，
MAXLEN值不宜设得太小（比如 10），否则每条写入都在裁剪，白白增加开销
事情说清了就结束。
