Redis中LRANGE无法条件过滤时，应使用EVAL执行Lua脚本遍历处理：先用redis.call('LRANGE')获取列表，再在Lua中条件筛选、限长保护、安全返回；禁用客户端过滤和频繁redis.call调用，大列表需预分类或分页处理。
用 LUA 在 Redis 里截取列表，LRANGE 不够用时怎么办
Redis 原生 LRANGE 只能按索引范围取值，没法做条件过滤、去重、转换或分页跳过已读项。这时候必须上 EVAL 或 EVALSHA 执行 Lua 脚本——但别直接拼字符串，得靠 Lua 自己遍历处理。
常见错误是把整个列表 LRANGE 出来再在客户端过滤，既浪费带宽又丢掉原子性；或者在 Lua 里用 table.remove 频繁删中间元素，性能崩得飞快。
- 优先用
redis.call('LRANGE', KEYS[1], 0, -1)拿全量，再用 Lua 做逻辑（小列表安全） - 大列表（>5k 元素）必须加限长：先
redis.call('LLEN', KEYS[1])判断，超阈值就报错或降级 - 避免在循环里反复调
redis.call，比如逐个LINDEX查——Lua 和 Redis 交互是同步阻塞的，一次脚本里最多 1–2 次外部调用
EVAL 脚本里怎么安全地“按内容截取”列表
比如要从 msg:queue 里取出所有 status="pending" 的消息 ID，且只取前 10 条——这没法靠原生命令链实现，必须 Lua 遍历 + 条件收集。
关键点在于：Lua 表是内存结构，不能直接当 Redis 列表用；所有写操作（如 LPOP）必须显式调用 redis.call，且只能发生在脚本末尾集中处理，否则破坏原子性。
- 用
for i = 1, #list do遍历redis.call('LRANGE')返回的 table，别用ipairs（可能含 nil） - 匹配后存到 Lua 局部 table（如
result = {}），最后用return result输出，不要试图redis.call('LPUSH', ...)写回新 key - 如果需要“截取并删除原列表中已选元素”，必须两阶段：先收集索引，再倒序
LREM（正序删会偏移后续位置）
eval "local list = redis.call('LRANGE', KEYS[1], 0, -1); local res = {}; for i, v in ipairs(list) do if string.match(v, 'pending') then table.insert(res, v) end; if #res >= tonumber(ARGV[1]) then break end end; return res" 1 msg:queue 10
为什么 LUA 脚本里不能用 string.split 或 json.decode
Redis 内置 Lua 环境极度精简：只有基础库（string, table, math, struct），没有 lpeg、没有 cjson、没有 split 函数。所有 JSON 解析、字符串切分都得手写。
典型翻车场景：想从 "{id:1,status:pending}" 里抽 status，结果用 string.gmatch 写错模式，或没处理转义字符，脚本直接报 Lua ERR error running script。
- 简单 KV 用
string.match(v, 'status:(%w+)')足够，别碰复杂 JSON - 真要解析 JSON，请提前在客户端序列化成扁平字段（如
"id=1&status=pending"），再用string.match提取 - 所有
string.match必须加空检查：if val then ... end，否则nil传给table.insert会静默失败
性能临界点在哪？什么情况下该放弃 LUA 改用客户端处理
单次 Lua 脚本执行超过 5ms 就该警惕；超过 100ms 基本等于堵死 Redis 主线程。不是脚本逻辑慢，而是数据量导致的内存遍历开销不可控。
一个 LRANGE 返回 10 万条字符串，哪怕 Lua 只做 if v == ARGV[1] then ...，光内存拷贝和遍历就吃掉几十毫秒——这比网络传输还重。
- 列表长度 > 1k 且需复杂条件时，优先考虑在写入端预分类（如用不同 key 存 pending/processing/done）
- 如果必须运行时过滤，把条件下沉到业务层：用
SCAN+ 游标分批拉，在客户端聚合，牺牲一点原子性换响应稳定 - 永远检查
redis.call('LLEN', KEYS[1])结果，大于 500 就拒绝执行，返回明确错误（如ERR list too large）而不是让脚本卡住
最常被忽略的是脚本缓存和复用：EVALSHA 比 EVAL 快 30% 以上，但得自己维护 SHA1 映射；另外，别在脚本里硬编码 key 名，用 KEYS[1] 传参，否则无法复用。
