FCALL是Redis函数式执行的架构级替代方案，跳过脚本传输与编译，仅传函数名和参数，预加载函数定义，降低毫秒级延迟；函数持久化至AOF/RDB并自动复制，支持细粒度ACL权限、可观测性命令及沙箱硬隔离。
FCALL 跳过脚本传输和编译，直接执行
FCALL 不是 EVAL 的语法糖，而是架构级替代：它不传脚本内容，只传函数名和参数，比如 FCALL inventory.decr_stock 1 item:123 10。服务器端已预加载函数定义，跳过了字符串解析、语法检查、字节码编译三步。这对高频调用（如库存扣减）意味着毫秒级延迟下降。
而 EVAL 每次都要把整段 Lua 代码通过网络发给 Redis，哪怕只有几行；EVALSHA 虽省传输，但首次仍需 EVAL 编译缓存，且缓存不持久、不复制——主节点重启后全部失效，客户端被迫 fallback 到 EVAL，网络开销翻倍。
函数持久化到 AOF/RDB，避免重复加载
FUNCTION LOAD 注册的函数会真实写入 AOF、参与 RDB 快照，并自动复制到所有从节点。它被当成数据库状态的一部分来对待，不是内存缓存。
常见错误现象：EVALSHA 在从节点执行报错 ERR NOSCRIPT No matching script；换成 FUNCTION LOAD 后，从节点可直接 FCALL，无任何中断。
对比之下，SCRIPT LOAD 的脚本只存在当前节点内存中，不落盘、不复制、不跨节点同步。主从切换、集群分片迁移、Redis 重启后，脚本即失——这不是配置问题，是 Redis 6.x/7.x 明确的设计行为。
可观测性与权限控制降低运维成本
FUNCTION LIST 可查所有已注册函数及其 SHA256 校验值，FUNCTION LIST WITHCODE 还能导出源码，方便审计和迁移；FUNCTION STATS 能看到执行次数、错误率、平均耗时、最后调用时间——这些在 EVAL 场景下完全不可见。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
ACL 权限可精确到函数级别：+function|call ~stats.* 表示只允许调用 stats 库下的函数，比粗粒度的 +eval 安全得多。而 EVAL 只能按命令开关，禁用就全禁，放开就全放。
函数库名（如 inventory.decr_stock）必须带前缀，否则报错 ERR unknown function；改一个函数就得整库重载（FUNCTION FLUSH + FUNCTION LOAD），避免运行中版本错乱——这点看似麻烦，实则是稳定性的关键约束。
Lua 环境收紧反而提升执行确定性
Functions 对沙箱做了硬性隔离：第一行必须是 #!lua name=lib:xxx，不能有空行；命令名全小写（redis.call("incr", key) 合法，REDIS.CALL 或 redis.CALL 直接报错）；禁用 os、io、loadstring 等非安全模块。
这些限制看似繁琐，实则消除了 EVAL 中常见的隐式依赖和运行时不确定性。比如老脚本里写 redis.call("INCR", KEYS[1]) 会失败，因为 Functions 要求显式声明 local redis = redis 并用小写 keys 参数；这种强制规范让函数更易测试、更少因环境差异出错。
真正容易被忽略的是：Functions 和 EVAL 一样，仍运行在 Redis 单线程中。一个函数里循环十万次、调用 KEYS *、或试图做阻塞操作（虽然根本没 http.get 这种命令），结果就是所有客户端命令排队，监控里 latency spike 打满屏——性能提升的前提，是函数本身写得足够轻量。
