LTRIM 是限制 Redis List 长度的唯一可靠方式，因其原子性、精准截断和内存即时释放特性；必须配合 LPUSH 使用，错误参数会清空列表，高并发下推荐 Lua 脚本保障原子性。
为什么 LTRIM 是限制 Redis List 长度的唯一可靠方式
Redis 的 LPUSH + LTRIM 组合，是控制 List 最大长度、只保留最新 N 条记录的事实标准。没有内置的“自动截断”配置项，LTRIM 不是备选方案，而是必须步骤——跳过它，List 就会无限增长。
常见错误现象：LPUSH key value 后不跟 LTRIM，导致内存持续上涨；或误用 LPOP/RPOP 做“清理”，结果删掉了最新数据（因为 List 是栈式结构，RPOP 删的是最老的）。
-
LTRIM是原子操作，不会出现“push 之后、trim 之前”被其他客户端读到超长状态 - 它只保留指定索引范围内的元素，其余立即释放内存，不触发延迟回收
- 索引支持负数：0 表示第一个（最老），-1 表示最后一个（最新），所以保留最新 100 条就是
LTRIM key -100 -1
LTRIM 参数写错会导致整个 List 被清空
这是最常踩的坑：LTRIM key start stop 要求 start ≤ stop，且索引必须在当前 List 实际范围内。一旦违反，Redis 直接返回 OK，但 List 变成空。
典型翻车场景：List 当前只有 5 个元素（索引 0~4），却执行 LTRIM key 10 19 或 LTRIM key 2 1 —— 这两个都会清空 List，且无任何警告。
- 安全写法永远用负数索引：想留最新 N 条，固定写
LTRIM key -N -1，哪怕 N 大于当前长度，Redis 也会自动取 min(N, len) - 避免用正数索引计算起始位置，除非你刚用
LLEN确认过长度且加了并发锁（不推荐） - 调试时可用
LRANGE key 0 -1验证截断结果，别只信返回值
高并发下用单条命令还是 Lua 脚本？
单纯 LPUSH + LTRIM 是两条命令，中间有竞态窗口。如果多个客户端同时 push，可能某次 trim 没覆盖到新插入的元素，导致短暂超长。
这不是理论风险：在 QPS > 500 的写入场景中，实测超长概率可达 3%~8%。解决方案不是加锁，而是用 Lua 脚本把两步压成原子操作。
- 推荐脚本：
EVAL "redis.call('LPUSH', KEYS[1], ARGV[1]); redis.call('LTRIM', KEYS[1], -tonumber(ARGV[2]), -1);" 1 mylist new_value 100 - 注意：Lua 中
tonumber()必须显式调用，否则-ARGV[2]会拼成字符串"-100"，而 Redis 索引只接受数字 - 如果使用连接池，确保脚本被缓存（如 Python redis-py 的
register_script），避免每次传输开销
用 LTRIM 保留最新记录时，性能和内存到底怎么变？
LTRIM 的时间复杂度是 O(N)，N 是被删除的元素个数，不是总长度。也就是说，保留最新 100 条时，删掉前面 10000 条，耗时和删 1 条几乎一样——Redis 内部是直接调整指针，不是逐个释放节点。
但有两个隐性成本容易被忽略：
- 如果 List 底层用了 quicklist 编码（默认），且被截断后剩余元素分散在多个 ziplist 中，
LRANGE读取最新数据时会有小幅额外跳转开销 - 频繁
LTRIM（比如每秒 push+trim 1000 次）会导致 quicklist 的 ziplist 频繁合并/分裂，长期可能增加内存碎片；此时可考虑改用MAXMEMORY配合 LRU 驱逐，而非强控长度 - 真正影响性能的是
LPUSH本身：List 超过 512 个元素后，quicklist 默认每个 ziplist 存 64 个元素，push 触发 ziplist 扩容的代价比小 List 高
实际部署时，如果业务能容忍“最多多存一两秒的数据”，建议把截断阈值设得稍宽松（比如要最新 100 条，就 LTRIM ... -120 -1），减少 trim 频率，比死磕精确数字更稳。
