直接用 lpush + rpop 不能构成真正的循环队列，因为它只是固定长度的 fifo 队列，无法实现新元素自动覆盖最旧元素；ltrim 保留区间而非删除区间，且索引方向易错，需用 rpush + ltrim -n -1 或 lua 原子封装。
为什么直接用 LPUSH + RPOP 不能构成真正的循环队列？
很多人误以为只要用 LPUSH 入队、RPOP 出队，再配合 LTRIM 截断长度，就实现了“循环”。但这是错觉——它只是**固定长度的 FIFO 队列**，不是循环队列。
真正循环队列的关键在于：当队列满时，新元素应自动覆盖最旧元素（即“头被踢掉”），而不是拒绝入队或丢弃新元素。而 LPUSH + RPOP 的组合天然偏向“尾进头出”，若强行用 LTRIM 控制长度，会把**最新入队的元素截掉**（因为 LTRIM queue 0 N-1 保留的是从头开始的 N 个），违背循环语义。
- 正确做法是统一用
RPUSH入队（尾部追加），再用LTRIM从头部裁剪：例如RPUSH queue item后执行LTRIM queue -N -1，保留最后 N 个元素 - 或者用
LPUSH入队 +RTRIM裁剪右侧，但需注意方向一致性，否则逻辑混乱 - 别混用
LPUSH和RPOP—— 它们操作端不匹配，容易导致顺序错乱
LTRIM 的索引方向和负数用法极易踩坑
LTRIM 的两个参数是 start 和 stop，表示**保留区间**，不是删除区间。而且索引从 0 开始，负数从尾部倒数（-1 是最后一个）。
常见错误：LTRIM queue 0 4 想留 5 个元素，但若队列当前只有 3 个，该命令仍合法；而 LTRIM queue 0 -2 会删掉最后一个元素——这在循环覆盖场景中常被误用。
- 要保留最多 N 个最新元素，用
LTRIM queue -N -1（推荐），它天然适配“尾部追加 + 保留后 N 个”的循环逻辑 - 避免用
LTRIM queue 0 N-1，除非你确定始终从左端入队且希望保留最老的 N 个 -
LTRIM在空队列上执行不会报错，但返回 0，需检查实际长度（LLEN）确认是否真有数据
并发场景下 RPUSH + LTRIM 不是原子操作
Redis 单条命令是原子的，但 RPUSH 和 LTRIM 是两条命令。在高并发写入时，可能出现：A 写入 item1 并执行 LTRIM，B 在 A 的 LTRIM 前写入 item2，导致最终队列长度超过 N。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
这不是 Redis 的 Bug，而是业务逻辑没兜住。
- 必须用 Lua 脚本封装：先
RPUSH，再LTRIM，保证原子性。例如：eval "redis.call('rpush', KEYS[1], ARGV[1]); redis.call('ltrim', KEYS[1], -tonumber(ARGV[2]), -1); return 1" 1 queue:item 5 - 不要依赖客户端先后发两条命令，网络延迟或重试会让中间状态暴露
- 如果用 Jedis/Lettuce 等客户端，务必确认其 pipeline 或 eval 调用方式正确，避免脚本里 key/argv 传错位置
判空和长度判断不能只信 LLEN
LLEN 返回列表长度，看似可靠，但在某些边界下会误导：
- 刚创建的 key，
LLEN返回 0，但该 key 还未被任何RPUSH触发，此时LLEN和EXISTS行为不一致 - 用
LTRIM裁剪到空区间（如LTRIM queue 0 -2当只有 1 个元素时），key 会被自动删除，下次LLEN返回 0，但已无 key - 消费者用
RPOP或BRPOP时，空队列返回 nil，比LLEN更直接反映“可消费性”
所以：入队逻辑看 LLEN + LTRIM 组合；出队逻辑优先用 BRPOP 或 RPOP 的返回值判断，而非先查 LLEN 再取——多一次 round-trip，还可能因并发变无效。
真正难的不是写对几条命令，而是想清楚“谁覆盖谁”“哪边进哪边出”“裁剪保哪段”——这三个问题定错一个，整个循环语义就崩了。Redis List 本身没有循环概念，所有“循环”都是靠你用命令组合出来的幻觉。
