defineScript比eval更安全高效，因避免重复传输解析脚本、防止敏感逻辑泄露，且启动时即可语法校验；eval仅适用于调试或临时场景。
直接用 defineScript 定义脚本，比每次 eval 更安全、更快，且能自动处理 SHA 缓存和参数绑定。
为什么不能每次都用 eval？
每次调用 eval 都会把完整脚本字符串发给 Redis，重复传输、重复解析、重复校验 SHA —— 浪费带宽，也增加 Redis CPU 压力。更关键的是，脚本内容暴露在日志或监控中，有潜在泄露风险（比如含敏感逻辑或硬编码值）。
-
eval适合调试或一次性临时脚本，不适合生产环境高频调用 - Redis 对单个脚本长度有限制（默认 512MB，但实际建议控制在几 KB 内）
- 若脚本含语法错误，
eval报错信息是 Lua 错误堆栈，不带行号，定位困难；而defineScript在 Node 启动时就能校验语法（TypeScript + IDE 支持）
defineScript 的正确用法与参数陷阱
它不是“注册命令”，而是生成一个可复用的客户端方法，其行为由 NUMBER_OF_KEYS 和 parseCommand 共同决定 —— 后者必须显式 push 所有键和参数，否则 KEYS 数组为空或错位。
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
-
NUMBER_OF_KEYS指明前几个参数是键名，其余归入ARGV；但它不自动提取参数，必须靠parseCommand构建命令流 -
parseCommand的参数顺序 = 脚本方法调用时的实参顺序，不是KEYS/ARGV顺序 - 示例中
mincr('a','b',5)→parseCommand接收'a','b',5，你要手动parser.pushKey('a'); parser.pushKey('b'); parser.push(5) - 漏掉
parser.pushKey()或错用push()，会导致 Lua 中KEYS[1]取不到值，常见报错：ERR Error running script (call to f_...): @user_script:1: @user_script: 1: attempt to index a nil value (global 'KEYS')
Lua 脚本里该用 redis.call 还是 redis.pcall？
绝大多数情况用 redis.pcall —— 它不会中断整个脚本执行，而是返回 {ok=false, err="..."} 结构，你可以在 Lua 里判断并做 fallback，避免因单个 key 不存在或类型错误导致整个原子操作失败。
-
redis.call('GET','missing')直接抛异常，脚本终止，后续命令不执行 -
redis.pcall('GET','missing')返回{ok=false,err="ERR no such key"}，你可以if res.ok then ... else ... end - 注意：即使用了
pcall，如果脚本本身语法错、超时、内存超限，仍会整体失败 —— 这类问题无法被pcall捕获 - Redis 6.0+ 支持
redis.setresp(2)控制响应格式，但 node-redis v4 默认兼容 RESP2，无需额外设置
真正容易被忽略的点是：脚本的原子性只覆盖 Redis 命令执行，不包含 Node.js 端的逻辑。比如你在脚本里 INCR 成功，但后续 Node 代码网络超时没收到结果，业务层仍需幂等设计 —— Lua 解决不了分布式系统里的“最后一步失败”问题。
