hset单命令原子，但多次hset非原子；eval脚本通过keys/argv传参、循环调用hset实现多字段批量原子更新，避免hgetall全量读写，支持条件判断与乐观锁逻辑。
为什么直接用 HSET 无法保证多个字段更新的原子性？
Redis 的单个命令（比如 HSET）确实是原子的，但如果你用多次 HSET 分别更新不同字段，就变成多个独立命令——中间可能被其他客户端插入操作，导致部分字段更新、部分未更新。尤其在计数器累加、状态机切换、库存扣减等场景下，这种“半更新”会引发数据不一致。
EVAL 脚本里怎么安全地批量更新哈希字段？
Lua 脚本在 Redis 服务端执行，整个脚本天然原子。关键是要避免手动拼接 key 名、防止注入，且必须用 redis.call() 调用原生命令。常见错误是把字段名/值当硬编码写死，或用字符串拼接构造哈希路径。
- 用
KEYS[1]传入哈希 key，用ARGV传入字段名和值（成对出现），例如：ARGV[1]是字段名，ARGV[2]是对应值，ARGV[3]是下一个字段名…… - 脚本里用
for循环按步长 2 遍历ARGV，每次取两个参数：for i = 1, #ARGV, 2 do redis.call('HSET', KEYS[1], ARGV[i], ARGV[i+1]) end - 不要用
redis.call('HGETALL', KEYS[1])再改再写——这会读全量、放大网络和内存开销，且没必要
更新时需要条件判断（比如只在字段存在时才改）怎么办？
Redis 没有内置的 “HSETNX 多字段” 命令，但 Lua 可以补足。典型需求：仅当某个字段值等于预期旧值时，才更新一批字段（类似乐观锁）。这时得先 HGET 判断，再决定是否 HSET。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 用
redis.call('HGET', KEYS[1], ARGV[1])获取待校验字段值（如"version"） - 用
if ... then ... else控制逻辑分支，返回值可设为1（成功）或0（失败）便于客户端判断 - 注意：Lua 中比较 nil 要用
== nil，不能用~= nil（会报错） - 避免在脚本里做复杂计算或循环超长列表——Redis 是单线程，脚本阻塞会影响所有请求
实际调用时容易漏掉的细节
脚本本身没问题，但客户端调用出错往往卡在参数传递上。最常踩的坑不是逻辑，而是序列化和类型。
-
KEYS数组长度必须 ≥ 1，哪怕只用一个 key，也要显式传["myhash"]，不能传空数组 -
ARGV里的数字会被 Redis 当作字符串处理，如果后端逻辑依赖数值比较（如if tonumber(ARGV[2]) > 100 then），必须显式tonumber() - 某些客户端（如 jedis）默认把
Integer自动转成字符串传给ARGV，导致HINCRBY类命令失败，此时需手动.toString() - 脚本长度超过 4KB 或执行时间过长（默认超时 5 秒），Redis 会直接中断并返回
(error) BUSY—— 这种情况得拆分逻辑或改用Redis Functions（Redis 7.0+）
真正麻烦的不是写脚本，而是验证它在并发下的行为是否符合预期。建议用 redis-benchmark -n 10000 -c 100 --eval 模拟压测，再检查最终哈希内容是否全量一致。
