redis list内存膨胀问题由maxmemory-policy统一管控，allkeys-lru可淘汰未访问list整key，volatile-lru需设ttl才生效，noeviction则直接拒写报oom。
Redis List 在内存不足时不会单独触发特殊机制——它和其他数据结构一样，统一受 maxmemory 和 maxmemory-policy 控制。真正起作用的是全局内存淘汰策略，而不是 List 自身行为。
List 本身不参与淘汰决策，但容易成为“高内存消耗者”
Redis 的淘汰机制不区分数据类型，只按配置策略扫描 key。但 List 是典型的内存“大户”：一个含百万元素的 list，即使每个元素是短字符串，也可能占用几十 MB；若用 LPUSH / RPUSH 持续堆积未清理，会加速触达 maxmemory 上限。
- 底层存储可能切换为
ziplist（紧凑编码）或linkedlist，前者省内存但扩容成本高，后者更耗空间但操作快 - 当 List 元素变多或单个元素变大（比如存 JSON 字符串），
ziplist会自动升级为linkedlist，内存占用可能翻倍 - 没有过期时间的 List key，在
volatile-lru或volatile-ttl策略下完全不会被考虑淘汰
不同淘汰策略对 List 的实际影响差异很大
关键看你的 maxmemory-policy 配置——List 能否被删、按什么逻辑删，全由它决定：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
allkeys-lru：List key 如果长期没被LPOP/LINDEX访问，会被优先淘汰（哪怕它存的是重要日志） -
volatile-lru：只有给 List 设置了EXPIRE，才可能进淘汰池；否则再大也不会动它 -
noeviction（默认）：List 写入失败直接报OOM command not allowed when used memory > 'maxmemory'，不是删数据，而是拒写 -
allkeys-random：List key 有同等概率被随机删掉，风险不可控
List 内存膨胀常被误认为“Redis 崩了”，其实是配置或使用问题
很多线上故障表现为 “List 插不进新元素”，但查 INFO memory 发现 used_memory_human 已超 maxmemory，这时不是 List 有问题，而是：
- 没设
maxmemory，结果 OS OOM Killer 杀了 redis-server 进程（此时看系统日志有Out of memory: Kill process redis-server） - 用了
noeviction却没配监控告警，业务持续LPUSH直到写失败 - List 存了不该存的东西：比如把整段 HTML、Base64 图片塞进一个 key，而不是拆成多个带 TTL 的小 key
- 误以为
LRU是“按元素淘汰”，其实 Redis 只能整 key 淘汰——删就删整个 List，不会只删 List 里的旧元素
真正要控制 List 内存，靠的不是等淘汰机制出手，而是写入侧限长（LTRIM 截断）、读取侧及时消费、key 级设置 TTL，并配合 allkeys-lru 这类主动策略兜底。否则等到内存满，List 不是被“优化”，而是整条消失或写入卡死。
