function load 将函数库作为数据库对象持久化并复制，script load 仅内存缓存脚本且不落盘、不复制；前者支持高可用与跨节点复用，后者重启或主从切换后即失效。
Redis Functions 不是 Lua 的“升级版”，而是把脚本当作数据库对象来管理的全新机制 —— 它解决了 Lua 脚本在持久化、复制、复用和调试上的根本性缺陷，但不能直接复用旧 Lua 脚本，必须重写并注册。
FUNCTION LOAD 和 SCRIPT LOAD 的本质区别在哪
SCRIPT LOAD 只是把 Lua 脚本哈希缓存到当前连接或节点内存中，不落盘、不复制、不跨节点同步；重启、主从切换后脚本就丢失，应用必须重新 SCRIPT LOAD。而 FUNCTION LOAD 是将函数库作为 Redis 数据库的一部分写入 AOF/RDB，并通过主从复制同步到所有节点，相当于“脚本即数据”。
常见错误现象：SCRIPT LOAD 后在从节点执行 EVALSHA 报错 ERR NOSCRIPT No matching script；换成 FUNCTION LOAD 后，从节点可直接 FCALL。
- 必须带
REPLACE参数才能覆盖已注册同名库，否则报错ERR Library already exists - 函数库名（
name=xxx）必须唯一，且会出现在FUNCTION LIST输出中 - 不支持裸 Lua 代码，必须用
#!lua name=xxx开头声明引擎和库名
如何把老 Lua 限流脚本迁移到 Function
旧版限流脚本常靠 INCR + EXPIRE 组合，但存在 key 过期瞬间被 INCR 创建为永不过期 key 的竞态问题。Lua 脚本靠原子性规避，Function 同样能做，但写法更清晰、可维护。
示例迁移要点：
- 原 Lua 脚本中
redis.call('incr', KEYS[1])→ Function 中仍可用，但推荐封装为独立函数逻辑 - 必须显式处理 key 不存在时的初始化：用
redis.call('exists', keys[1]) == 0判断，再set并expire - 参数传入方式变化：
FCALL myrate 1 limit:uid 60中，60是ARGV[1]，不是硬编码 - 别漏掉
redis.register_function('incrlimit', handler)，否则FCALL找不到函数
FCALL 执行失败的典型原因和排查路径
不同于 EVAL 报错信息模糊，FCALL 错误更结构化，但新手常卡在环境准备阶段。
- 报错
ERR Unknown function：确认FUNCTION LIST是否有对应函数名，注意大小写和库前缀 - 报错
ERR user_function:5: attempt to call a nil value：函数体内调用了未定义的局部变量或未local声明（如num = unpack(args)必须写成local num = unpack(args)） - 报错
ERR Error running script (call to f_...): @user_function: line 12: user_script:12: write commands not allowed：Function 默认只读，若需写操作（如set），必须在register_function时加{ flags = { 'allow-oom' } }或明确允许写（部分版本需flags = { 'allow-stale' }，视 Redis 补丁版本而定） - 调试建议：先用
redis-cli --eval测试原始 Lua 片段，再套进 Function 模板，避免语法嵌套出错
Functions 的热更新和版本管理怎么落地
Function 支持在线替换，但“热更新”不等于无感切换 —— 正在执行的函数不会中断，新请求才走新版，这点和 Lua 的 SCRIPT FLUSH + 重载完全不同。
- 用
FUNCTION LOAD REPLACE覆盖同名库，旧函数立即不可调用，新函数立刻生效 - 若要保留历史版本，得手动改库名（如
name=mylib_v2），再用新名FCALL -
FUNCTION DELETE可删整个库，但无法删单个函数；删错只能重LOAD - 生产环境建议：函数名带业务+版本标识（如
rate_limit_v1），配合 CI/CD 自动化注册，避免手工操作遗漏
真正容易被忽略的是权限控制：ACL 默认不放行 FUNCTION 相关命令，必须显式给用户加 function 权限，否则 FUNCTION LIST 都返回空 —— 这点比 Lua 更严格，也更安全。
