不能直接用HGETALL全量拉取再过滤，因网络和内存开销大；Redis不支持哈希条件查询，需Lua在服务端筛选，注意用KEYS[1]传参、正确解析field/value交替数组、统一小写比较，并评估数据规模避免阻塞。
为什么不能直接用 HGETALL 拿哈希全量再过滤？
客户端拉回整个哈希结构（比如上万字段）再做条件筛选，网络开销和内存压力都很大，尤其当只需要其中几个匹配字段时。Redis 本身不支持哈希的“条件查询”，HGETALL、HSCAN 都是遍历型命令，没法跳过无关字段。
Lua 脚本能直接在服务端执行逻辑，只把结果传回来——这是减少传输的核心前提。
用 redis.call("HGETALL", KEYS[1]) 在 Lua 里筛字段要注意什么？
常见错误是写成 redis.call("HGETALL", "user:123") 硬编码 key，导致脚本无法复用；或没处理返回值为空的情况，HGETALL 返回的是交替的 field/value 数组，直接 table.foreach 容易下标越界。
- 必须用
KEYS[1]接收 key，通过EVAL ... 1 user:123传参 -
HGETALL返回形如{"name","Alice","age","30","status","active"}，要用for i=1,#res,2步进取 field - 字段名比较建议统一小写（
string.lower(res[i])），避免大小写不一致漏匹配 - 如果哈希极大，
HGETALL仍可能阻塞，此时应改用HSCAN分批，但 Lua 里实现分页较复杂，一般先评估数据规模
local res = redis.call("HGETALL", KEYS[1])
local matched = {}
for i = 1, #res, 2 do
local field = res[i]
if string.match(field, "^status$") or string.match(field, "^score$") then
table.insert(matched, res[i])
table.insert(matched, res[i+1])
end
end
return matched
redis.call("HGET", ...) 多次查 vs HGETALL 一次筛，哪个更稳？
看起来多次 HGET 更精准，但实际在 Lua 中每调一次 redis.call 都有微小开销，且 Redis 是单线程，频繁调用不会并发加速；而 HGETALL 一次读内存更快，只要字段总数可控（比如几百以内），它更可靠。
- 适合场景：
HGETALL+ Lua 过滤，适用于字段数 config_ 前缀的键） - 不适合场景：字段超 5000 且只取 1–2 个，此时明确用
HGET或HMGET更省资源 - 注意：
HMGET不支持通配符，只能用于已知字段名列表，无法替代模糊匹配逻辑
evalsha 复用脚本时，为什么总报 NOSCRIPT No matching script？
脚本 SHA1 值依赖内容精确一致——空格、换行、注释哪怕差一个字符，SHA 就不同；另外，脚本首次必须用 EVAL 注册，才能用 EVALSHA 调用。
- 上线前用
SCRIPT LOAD手动加载一次，拿到 SHA 后存配置，避免每次EVAL重解析 - 别在脚本里拼接字符串生成 key，例如
"user:"..ARGV[1]，这会让脚本失去确定性，Redis 可能拒绝缓存 - 调试时先用
EVAL确认逻辑正确，再切到EVALSHA，别跳步
Lua 脚本真正难的不是语法，而是对 Redis 单线程模型和数据结构边界的理解——比如哈希字段名不能含空格或控制字符，否则 HGETALL 解析会错位；还有脚本执行超时（默认 5 秒）被 kill 后，状态不可回滚，这些细节比写逻辑更容易出问题。
