keys必须仅包含真实操作的redis键名以支持集群路由，argv专用于传递所有非键参数；numkeys值决定keys与argv的参数分割点，错误将导致全部参数映射错乱。
KEYS 里只能放真正要操作的 Redis 键名
Redis 不是把所有参数都当字符串塞进 Lua 就完事了——它得在执行前就知道脚本会碰哪些 key，否则集群根本没法路由请求。所以 KEYS 数组不是“传参容器”，而是“声明式键清单”。你往 KEYS 里塞一个非 key 的值（比如用户 ID 字符串、过期时间数字），脚本可能跑通，但在集群里大概率报 ERR CROSSSLOT Keys in request don't hash to the same slot。
- 必须确保每个
KEYS[i]都对应一个真实存在的 Redis key，且该 key 真正被redis.call()调用（如GET、HGET、DEL） - 硬编码 key 名（如
"user:123"）在脚本里是反模式：无法复用、无法缓存 SHA、集群不兼容 - 如果脚本只读不写、或只操作本地内存变量，却仍往
KEYS里塞东西，属于无意义声明，徒增解析开销
ARGV 是唯一安全接收动态值的地方
所有非 key 的数据——数值、标志位、JSON 字符串、布尔语义字符串（"true"/"false"）、甚至空值——都必须走 ARGV。Redis 客户端传过来的任何东西，在 Lua 里全是字符串，ARGV[1] 永远是 string 类型，哪怕你用 Python 传了 int(42) 或 True。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 数值计算前必须显式调用
tonumber(ARGV[1])，且要检查返回值是否为nil，否则ARGV[1] + 10会直接报错attempt to perform arithmetic on a nil value - 不要依赖自动类型转换，
ARGV[1] == 1永远为 false；比较布尔含义请用ARGV[1] == "1"或ARGV[1] == "true" - 空参数处理要双重判断：
ARGV[1] ~= nil and ARGV[1] ~= ""，因为不同客户端对None的处理不一致（有的转空串，有的丢弃）
EVAL 命令中 numkeys 错一位，整个参数映射就全乱
numkeys 不是“参数总数”，而是明确告诉 Redis：“从第 3 个参数开始，往前数几个是 key”。它直接决定哪些字符串进 KEYS、哪些进 ARGV。错一个，KEYS[1] 和 ARGV[1] 就全指错了地方。
- 命令格式固定为：
EVAL "script" <numkeys><key1><key2> ... <arg1><arg2> ...</arg2></arg1></key2></key1></numkeys> - 例如：
EVAL "return KEYS[1]..ARGV[1]" 1 user:123 hello→KEYS[1] = "user:123",ARGV[1] = "hello" - 但如果写成
EVAL "..." 0 user:123 hello，则KEYS为空，ARGV[1] = "user:123",ARGV[2] = "hello"，脚本逻辑瞬间崩坏 - 用
redis-cli --eval时，逗号前后空格不能省：redis-cli --eval script.lua key1 key2 , arg1 arg2，少逗号或空格错位都会让参数错位
集群环境下 KEY 的哈希槽一致性是硬约束
Redis Cluster 要求脚本里所有 KEYS 必须落在同一个哈希槽，否则直接拒绝执行。这不是可选项，是架构级限制。而 ARGV 完全不受影响——你可以传 100KB 的 JSON 字符串进去，只要不把它当 key 去 redis.call()，就不会触发槽校验。
- 多个 key 必须同槽，最稳妥办法是用哈希标签：
user:{123}:profile和user:{123}:stats会被哈希到同一槽 - 别指望靠
redis.call("EXISTS", "some:other:key")绕过声明——只要没出现在KEYS数组里，这个调用在集群里就是非法的 -
ARGV再大也不影响分片逻辑，但要注意 Lua 脚本总内存占用（默认 512MB 上限），超限会报ERR Error running script (OOM)
