直接用 eval 管理会话不可靠也不安全，因其无法保证字段级原子性、易参数错位、无脚本缓存、网络开销大；应预加载 sha 校验脚本，强制 keys 传 session key、argv 传业务字段和 ttl，并用 redis.pcall 保障容错与原子性。
直接用 EVAL 执行 Lua 脚本管理会话，既不可靠也不安全——它无法保证字段级更新的原子性，且容易因参数错位导致键名污染或超时失效。真正可行的做法是：把会话读写封装成预加载的、带 SHA 校验的脚本，并强制通过 KEYS 传 session key，ARGV 仅传业务字段和 TTL。
为什么不能直接用 EVAL 写会话逻辑？
常见错误是把整个会话 JSON 序列化后塞进 SET + EXPIRE 两步走，或者用 EVAL 拼接字符串做 HSET 和 EXPIRE。问题在于：
-
EVAL每次都传输完整脚本，网络开销大，且 Redis 不缓存未注册脚本的 SHA - 如果脚本里混用
KEYS[1]和ARGV[1]但调用时顺序写反，可能把用户 ID 当成 key 名，误删其他数据 - 没用
redis.pcall()包裹关键操作，一旦HGET返回 nil 后继续tonumber()就会抛错中断，导致会话状态不一致 - 超时重置逻辑（如每次访问延长 TTL）若不在脚本内完成，就存在竞态：客户端读完 session 后过期，再写入时已失效
必须用 defineScript 预注册三个核心脚本
node-redis 的 defineScript 不只是语法糖，它确保脚本只上传一次、后续全走 EVALSHA，同时自动绑定 KEYS 和 ARGV 类型校验。会话管理至少需要这三个脚本：
-
createSession：接收KEYS[1]（session key）、ARGV[1]（user ID）、ARGV[2]（TTL 秒数），执行HSET+EXPIRE原子写入 -
touchSession：接收KEYS[1]，检查 key 是否存在，存在则刷新 TTL 并返回 1，否则返回 0 —— 这是防止会话静默过期的关键 -
getSession：接收KEYS[1]，用redis.pcall("HGETALL", KEYS[1])安全读取，避免因 key 不存在而报错；返回空表或实际字段
示例定义（使用 node-redis v4+）：
const { defineScript } = require('redis');
const createSession = defineScript({
NUMBER_OF_KEYS: 1,
SCRIPT: `redis.call('HSET', KEYS[1], 'userId', ARGV[1], 'createdAt', ARGV[2], 'lastAccess', ARGV[2]);
redis.call('EXPIRE', KEYS[1], tonumber(ARGV[3]));
return 1;`,
NAME: 'createSession'
});
KEYS 必须只传 session key，别碰其他键
Redis 要求所有被脚本操作的 key 都显式声明在 KEYS 数组里，这是原子性和集群模式支持的前提。常见错误是把用户 ID 或 IP 地址也塞进 KEYS，导致：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 在 Redis Cluster 中，脚本只能访问同一个 slot 的 key，混用不同业务 key 会触发
CROSSSLOT错误 -
KEYS长度声明（NUMKEYS）和实际传入数量不匹配时，脚本直接拒绝执行，错误信息是ERR Error running script (call to f_...): @user_script:1: Wrong number of args - 会话 key 格式必须统一，例如
session:{uuid}，不能动态拼接前缀（如user:{id}:session），否则无法做 key hash 分片
正确做法：所有会话数据都存于单个 Hash key 下，业务字段（如 ip、userAgent）只走 ARGV，不参与 key 路由。
超时刷新必须在脚本内完成，且用 pcall
“用户每次请求都延长会话有效期”这个需求，看似简单，实则极易出错。如果先 GET 再判断再 EXPIRE，中间存在时间窗口；如果用 redis.call("EXPIRE", ...) 但 key 已过期，会返回 0 且不报错——但你无法区分是 key 不存在还是刚过期。
安全写法是用 redis.pcall 包裹，并检查返回值：
local res = redis.pcall("EXPIRE", KEYS[1], tonumber(ARGV[1]))
if type(res) == "table" and res.err then
return 0 -- 脚本内捕获异常，比如 key 不存在
else
return res -- 1 表示成功设置过期，0 表示 key 不存在
end
注意：不要依赖 redis.call("EXISTS", KEYS[1]) 再决定是否刷新，因为 EXISTS 和 EXPIRE 之间仍有并发间隙；pcall 的原子失败反馈才是唯一可靠依据。
最易被忽略的一点：Lua 脚本里所有数字都要显式转 tonumber()，比如 ARGV[2] 是字符串，直接用于 INCRBY 或比较会静默失败；另外，Redis 6.0+ 默认开启 ACL，确保执行脚本的用户有 scripting 权限，否则 EVAL 和 EVALSHA 全部被拒。
