Redis 7.0 Functions 替换 EVAL 失败主因是版本不达标、模块未加载或跨库/跨节点未同步；需确认≥7.0.0、MODULE LIST含redis_function、按库加载并预热调用。
Redis 7.0 Functions 替换 EVAL 时，脚本加载失败报 ERR Unknown command 'FUNCTION'
说明：这个错误不是脚本写错了，而是 Redis 实例压根不支持 Functions 功能——它只在 7.0+ 启用，且默认开启，但你连的可能是旧版本服务，或者用了未启用模块的 Docker 镜像（比如某些 alpine 版本没编译 redis_function 模块）。
实操建议：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先确认版本：
redis-cli INFO server | grep redis_version，必须 ≥7.0.0 - 检查模块是否加载：
redis-cli MODULE LIST | grep function，应看到name:redis_function - Docker 用户注意：
redis:7-alpine有些小版本缺失 Functions 支持，换用redis:7.2或redis:7.2-bookworm更稳 - 云数据库（如阿里云、腾讯云）需确认控制台是否已升级到 7.0+ 并开启「函数功能」开关，部分厂商默认关闭
把老 EVAL 脚本改写成 FUNCTION LOAD 时，Lua 环境差异导致运行异常
说明：Functions 不再共享全局 Lua 状态，redis.call() 行为一致，但 redis.pcall() 错误结构变了；更重要的是，Functions 默认禁用 redis.log() 和 math.random()，且不能用 KEYS/ARGV 全局表——参数全靠显式传入。
实操建议：
- 别直接复制
EVAL "return redis.call('GET', KEYS[1])" 1 foo过去；改用：FUNCTION LOAD lua "redis.register_function('get_key', function(keys, args) return redis.call('GET', keys[1]) end)" -
keys和args是 table，不是数组索引从 1 开始的“伪数组”，但 Lua 里仍用keys[1]取第一个 key——这点和 EVAL 一样，容易误以为要改下标 - 若原脚本依赖
math.random()，得换成math.randomseed(redis.sha1hex(ARGV[1] or ''))再调用，否则报attempt to call a nil value - 调试时加
redis.log(redis.LOG_WARNING, 'debug: '..cjson.encode(keys))，但上线前删掉——Functions 的日志默认不输出到 slowlog，也不进 MONITOR
迁移后发现 FUNCTION LIST 返回空，或新函数调用报 ERR Unknown function
说明：Functions 是按库（database）隔离的，不是全局注册。你在 db 0 FUNCTION LOAD，却在 db 1 FCALL，就会找不到；另外，FUNCTION FLUSH 默认只清当前库，不是全实例。
实操建议：
- 所有
FCALL前，先SELECT到对应 db，或明确指定 db 连接（如 redis-py 的redis.Redis(db=1)） - 批量迁移时，用
FUNCTION LIST WITHCODE导出函数定义，再用FUNCTION LOAD逐库重载，别指望一次加载全库通用 - 集群模式下，Functions 必须在每个 shard 上单独
FUNCTION LOAD，官方不自动同步——漏掉某个节点，就会出现「有时能调、有时报错」的诡异现象 - CI/CD 中不要用
FUNCTION FLUSH清环境，改用FUNCTION DELETE <name>精确移除，避免误删其他服务部署的函数
性能对比：为什么 FCALL 比 EVAL 慢了 10%？
说明：Functions 引入了额外的沙箱校验、签名验证和上下文隔离，冷启动确实略慢；但真正影响大的是「首次调用」——后续 JIT 缓存生效后，差距基本消失。如果你压测看到持续慢，大概率是没预热或用了太小的 lua-time-limit。
实操建议：
- 上线前做一次预热：
FCALL myfunc 1 keyname跑几遍，让 LuaJIT 编译缓存就位 - 检查配置：
lua-time-limit默认 5000ms，Functions 对超时更敏感，若脚本含循环或大 key 扫描，可临时调高，但别关（0）——关了会失去中断保护 - 避免在 Functions 里做网络请求、文件读写、或调用阻塞命令（如
BLPOP），这些在 Functions 中被禁止，会直接报错，不是变慢 - 如果函数逻辑简单（比如只是
GET + INCR），EVAL 仍有轻微优势；但逻辑一复杂（分支多、嵌套深），Functions 的可维护性和 debug 能力远胜 EVAL，这时性能差异可以接受
