lpush+lpop无法自动限长，因lpop删队首而新元素入队尾，导致长度持续增长；唯一可靠方式是lpush后立即ltrim，或用lua脚本原子执行推入与截断。
为什么不能靠LPUSH+LPOP自动限长
很多人以为只要每次 LPUSH 后紧跟 LPOP 就能维持固定长度，其实这是错的——LPOP 删除的是队首元素，而新元素在队尾，中间会不断堆积，实际长度持续增长。真正要截断旧数据，必须主动清理尾部或头部冗余项。
LTRIM 是唯一可靠的限长手段
LTRIM 直接在服务端裁剪列表，只保留指定索引范围内的元素，其余立即释放内存。它不是“删除后再插入”，而是原子性截断，不存在竞态导致超长的问题。
- 保留最新 N 条：用
LTRIM key -N -1（负索引从尾部计数） - 保留最老 N 条：用
LTRIM key 0 N-1 - 执行顺序必须是
LPUSH或RPUSH之后立刻LTRIM，否则窗口期可能超限 - Redis 7.0+ 支持
LPUSH key value LIMIT N语法，但仅限于单元素 push 场景，不通用
用 Lua 脚本保证原子性（生产环境必需）
单独发 LPUSH 和 LTRIM 两条命令，在高并发下仍有极小概率被其他客户端插队，导致临时超长。必须封装为 Lua 脚本执行：
eval "redis.call('LPUSH', KEYS[1], ARGV[1]); redis.call('LTRIM', KEYS[1], 0, tonumber(ARGV[2])-1); return 1" 1 mylist new_item 100
上面脚本把「推入 + 截老」打包成一个原子操作，ARGV[2] 是目标最大长度，0 到 N-1 精确保留最老的 N 条；若想留最新的 N 条，把 0 换成 -ARGV[2] 即可。
注意 LTRIM 的边界行为和性能影响
LTRIM 时间复杂度是 O(N)，N 是被删除的元素个数，不是总长度。所以日常维护时尽量控制单次裁剪量——比如每 push 一次就 trim 一次，比攒够 1000 次再 trim 一次更平稳。
- 索引越界不会报错：
LTRIM key 100 200对空列表或长度不足的列表是安全的 - 当列表长度小于指定范围时，
LTRIM不做任何事，也不会失败 - 如果用负索引（如
-10 -1），而列表实际只有 3 个元素，结果就是保留全部 3 个 - 频繁
LTRIM不会导致内存碎片，Redis 内部会直接调整底层链表指针
真正容易被忽略的是：Lua 脚本里调用 redis.call 失败会中断整个脚本，但 LTRIM 几乎不会失败，除非 key 类型错误——所以务必确保目标 key 始终是 List 类型，混用 SET 或 HASH 会导致后续所有操作报 WRONGTYPE 错误。
