redis lua脚本在c++中必须用rediscommand或rediscommandargv发送完整脚本字符串，hiredis不缓存sha、不预注册，需严格匹配keys/argv数量并转义，集群下须用一致hash tag保障原子性，超时由客户端socket级timeout兜底。
Redis Lua脚本在C++中必须用 redisCommand 发送完整脚本字符串
Redis 本身不提供“编译后缓存脚本句柄”这类抽象，C++ 客户端（如 hiredis）也无内置脚本管理机制。所有 Lua 脚本都得作为纯文本通过 redisCommand 或 redisCommandArgv 发送给 Redis 执行。这意味着每次调用都要传入完整脚本内容，Redis 内部会自动 EVALSHA 优化（首次执行 EVAL，后续尝试 EVALSHA），但客户端完全感知不到这个过程。
常见错误是试图“预注册脚本”或“只传 sha1 值让客户端自己缓存”，这会导致 NOAUTH Authentication required 或 NOSCRIPT No matching script —— 因为 hiredis 不做 SHA 计算和缓存，全靠 Redis 自己维护。
- 脚本字符串必须以
"return ..."结尾，否则 Redis 返回(nil)且不报错，容易误判成功 - 避免在脚本里用
redis.call("set", KEYS[1], ARGV[1])后再return 1却忽略返回值类型；C++ 侧redisReply*的type字段可能为REDIS_REPLY_INTEGER、REDIS_REPLY_STRING或REDIS_REPLY_NIL，需显式判断 - 脚本内不能访问外部变量、不能 sleep、不能发起网络请求，违反即触发
LUA scripting not allowed错误
KEYS 和 ARGV 传参必须严格区分，且数量要匹配 EVAL 命令的参数个数
Redis 要求 EVAL script numkeys key1 key2 ... arg1 arg2 ...，hiredis 中对应的是 redisCommand(ctx, "EVAL %s %d %s %s %s", script, numkeys, key1, key2, arg1)。如果 KEY 数量写错（比如声明 2 个 KEY 却只传 1 个），Redis 会直接返回 ERR Error running script (call to f_...): @user_script:... 类似错误，但定位困难。
更隐蔽的问题是：C++ 字符串拼接时未对 KEY/ARGV 做 Redis 协议转义（比如含空格或特殊字符的 key 名），导致解析错位。此时应改用 redisCommandArgv，把每个 KEY/ARGV 作为独立 char* 传入，由 hiredis 自动处理二进制安全传输。
-
redisCommandArgv第一个参数是redisContext*，第二个是参数总数（"EVAL"+ 脚本字符串 +numkeys+ 所有 KEY + 所有 ARGV），第三个是const char**数组，第四个是const size_t*长度数组 - 脚本中
KEYS[1]对应 argv[3]（跳过"EVAL"、script、numkeys），ARGV[1]对应 argv[3 + numkeys] - 若 KEY 名来自用户输入，务必确保其不含
{（影响 Redis Cluster key hash tag 判断），否则跨 slot 操作失败且报CROSSSLOT Keys in request don't hash to the same slot
原子性只在单个 Redis 实例或单 slot 下成立，集群模式下多 key 必须用 hash tag 对齐
Redis 的 Lua 原子性本质是“单线程执行脚本”，前提是所有涉及的 key 都落在同一个节点上。在 Redis Cluster 中，如果你的脚本同时操作 user:1001 和 order:2002，而它们 hash 到不同 slot，就会触发 CROSSSLOT 错误，脚本根本不会执行。
解决方法不是放弃 Lua，而是强制 key 落在同一 slot：用 {user:1001}_order:2002 这类 hash tag（花括号包裹公共前缀），让 Redis 只对括号内部分计算 CRC16。这样多个 key 就能共存于同一节点，Lua 才真正原子。
- 脚本内所有
KEYS[i]必须使用带一致 hash tag 的形式，不能一部分带一部分不带 - 业务层生成 key 时就要约定 tag 规则，例如“用户维度数据统一用 {uid} 开头”，而不是在 Lua 里拼接
- 本地开发用单机 Redis 测试不出该问题，上线集群环境才暴露，属于典型“环境差异坑”
超时和阻塞风险必须由客户端主动控制，Redis 不支持脚本级 timeout 配置
Redis 默认 lua-time-limit 是 5 秒，超时后连接会被断开，且当前脚本被 kill，但已执行的部分无法回滚（比如已写入部分 key）。C++ 客户端无法在脚本内部设 timeout，只能靠外部机制兜底：
- 设置
redisContext的timeout字段（struct timeval），控制整个redisCommand调用的 socket 级超时，防止卡死 - 避免在 Lua 中遍历大集合（
redis.call("hgetall", ...)返回几千字段）、不做嵌套循环、不用table.sort处理大数据量 - 若逻辑复杂到难以保证 5 秒内完成，应拆成多个小原子操作 + 客户端加锁（如
SETNX），而非硬塞进一个 Lua 脚本
真正难处理的是“脚本没超时但业务等不及”的场景——比如前端只给 800ms，而 Lua 平均耗时 1.2s。这时没有银弹，只能重构逻辑或降级策略。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
