必须在Lua脚本中用HGETALL+循环筛选字段，避免客户端全量拉取；需通过KEYS[1]传key、ARGV传条件值，遍历时按field/value交替结构步进，统一小写比较，并评估数据规模防阻塞。
用 HGETALL + Lua 循环筛字段，别拉回客户端
Redis 本身不支持哈希的条件查询，HGETALL 是唯一能一次性读取全部 field/value 的命令。但直接在客户端过滤会把整块数据（比如上万字段）全拉过来，浪费带宽、内存，还丢掉原子性。
必须在 Lua 脚本里完成匹配逻辑：
-
KEYS[1]传入 key 名，避免硬编码；ARGV传条件值（如"active"、">=100"），不能拼进脚本字符串里 -
HGETALL返回的是交替数组{"name","Alice","age","30"}，遍历时得用for i = 1, #res, 2步进，别用ipairs - 字段名比较建议统一转小写：
string.lower(res[i]) == "status"，避免大小写不一致漏匹配 - 如果哈希字段超 5000 个，
HGETALL可能阻塞，此时应改用HSCAN分批，但脚本内实现分页较复杂，先评估规模再决定
用 SCAN 配合 TYPE 和 HGET 实现跨类型多条件删
想删所有 hash 类型中 status == "failed" 且 retry_count > 3 的 key？不能靠 KEYS * —— 它会阻塞整个 Redis 实例。
必须用 SCAN 迭代，每次只处理一批（比如 100 个），并在脚本内判断类型和字段值：
- 先
redis.call("TYPE", key)，确认是"hash"再调HGET，否则会报WRONGTYPE -
retry_count可能为空，得写成tonumber(retry or "0")，避免nil转数字出错 - 匹配逻辑全放在 Lua 里，不要把 raw value 拉回客户端判断——网络往返+并发竞争风险都来了
- 单次脚本执行建议控制在 100ms 内，否则触发
BUSY Redis is busy running a script；可调小COUNT值降压
用 LRANGE + Lua 遍历做列表内容截取，别信 LRANGE 能过滤
LRANGE 只按索引取值，没法按内容筛选。比如从消息队列里取前 10 条 status="pending" 的记录，必须靠 Lua 遍历。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键不是“怎么写循环”，而是“怎么写才不翻车”：
- 先
redis.call("LLEN", KEYS[1])判断长度，超 5k 就报错或降级，防大列表卡死 - 用
redis.call("LRANGE", KEYS[1], 0, -1)拿全量，再用for i = 1, #list do遍历——ipairs遇到nil会提前退出 - 匹配后存进 Lua 局部 table（如
result = {}），最后return result，别试图在脚本里反复redis.call("LPUSH")写新 key - 如果要“截取并删除原列表中已选元素”，必须两阶段：先收集索引，再倒序
LREM（正序删会导致后续位置偏移）
传参必须分清 KEYS 和 ARGV，否则集群/ACL 直接报错
Redis 集群要求所有操作的 key 必须落在同一个 slot，ACL 也靠 KEYS 列表做权限校验。把条件值（如时间戳、状态字符串）塞进 KEYS 或硬编码进脚本，会直接失败。
正确姿势只有一条：所有真实 key 名走 KEYS，所有动态条件值走 ARGV。
- 错误写法：
EVAL "if redis.call('GET', 'user:123') == 'active' then..." 0——'user:123'硬编码，无法复用EVALSHA，集群下 key slot 校验失败 - 正确写法：
EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then..." 1 user:123 active - 条件值永远别拼进脚本字符串，否则有注入风险，且
SCRIPT LOAD后无法通过EVALSHA复用
最易被忽略的一点：Lua 环境极度精简，没有 json.decode、没有 string.split。想从 JSON 字符串里抽字段，只能手写 string.match，模式写错脚本就直接报 Lua ERR —— 这类错误不会在语法检查阶段暴露，得跑起来才崩。
