不能直接用多个INCR命令拼报表，因为多条INCR间无事务隔离，可能被并发修改导致数据不一致；应使用EVAL执行Lua脚本，将所有INCR放在一个原子操作中，并注意返回值类型转换与性能风险。
为什么不能直接用多个 INCR 命令拼报表
因为 INCR 是原子操作，但多条 INCR 之间没有事务隔离——中间可能被其他客户端修改，导致报表数据不一致。比如统计「今日注册用户数」「今日下单数」「今日支付数」三个指标，若分三次调用 INCR，两次之间若有并发写入，最终加总值就不是某个精确时间点的快照。
- Redis 单命令原子，多命令不原子；
EXEC+MULTI也不能保证读-改-写逻辑的正确性（没 CAS） -
EVAL执行 Lua 脚本时，整个脚本在服务端串行执行，天然具备原子性 - 脚本内可复用变量、做条件判断、批量读写，适合聚合类逻辑
怎样写一个安全的多计数 Lua 脚本
核心是把所有 INCR 操作放在一个 EVAL 中，用 KEYS 和 ARGV 传参，避免硬编码 key 名，提升复用性。
- key 列表通过
KEYS传入（最多 1024 个），确保 Redis 能预判访问哪些 key，用于集群路由和锁管理 - 增量值统一用
ARGV传，比如ARGV[1]是注册数增量，ARGV[2]是下单数增量 - 别在脚本里用
redis.call("GET", ...)再读一次——INCR本身就返回新值，重复读浪费且可能引入冗余逻辑
示例脚本：
EVAL "return {redis.call('INCR', KEYS[1]), redis.call('INCR', KEYS[2]), redis.call('INCR', KEYS[3])}" 3 user:reg:todays user:order:todays user:pay:todays 1 1 1
返回的是三个新值组成的数组，客户端可直接解包使用。
INCR 在 Lua 里要注意的类型陷阱
INCR 返回的是数字（integer），但 Lua 脚本中所有 Redis 返回值默认是字符串类型——即使你 INCR 一个不存在的 key，返回 "1" 而不是 1。如果后续要算差值或比较大小，必须显式转换。
- 用
tonumber()转换，例如local a = tonumber(redis.call("INCR", KEYS[1])) - 不要直接用
==比较redis.call("INCR",...)的结果和数字字面量，比如redis.call("INCR",k) == 100永远为 false - 如果某 key 不存在且你依赖初始值，先
EXISTS或用INCRBY配合GETSET更稳妥
性能与超时风险：别让 Lua 脚本变“长尾”
Redis 是单线程执行 Lua，脚本运行期间会阻塞所有其他命令。哪怕只是多做几次 INCR，问题不大；但一旦加入循环、网络调用（不允许）、或大量字符串处理，延迟就会飙升。
- 避免在脚本里遍历几百个 key 做
INCR——改用INCRBY批量加总后单次写入 - 不要用
redis.call("KEYS", "...")——这会扫描全库，集群下直接报错，本地模式也极慢 - 线上建议用
SCRIPT LOAD+EVALSHA替代重复EVAL，减少网络传输和解析开销
真正复杂的报表聚合（比如带时间窗口、去重计数），不该压在 Lua 里做——该用客户端预聚合，或导出到 ClickHouse/Druid 等专用引擎。
最易被忽略的一点：Lua 脚本里的 INCR 失败不会抛异常，而是返回错误对象（如 error 类型），但 redis.call() 遇错会直接中断脚本并向上抛。所以只要 key 类型不对（比如对 string 执行 INCR），整个脚本就失败，得靠客户端捕获 (error) ERR value is not an integer or out of range 这类信息来诊断。
