Redis 7.0 的 FUNCTION LOAD 并非加载预编译二进制，而是解析源码→编译为私有 Lua 5.1 字节码→校验合法性→注册元信息；不支持 luac 输出，须通过 AOF 持久化或部署期统一加载实现“一次编译、多处复用”。
Function库加载慢，不是脚本本身问题，而是每次 FUNCTION LOAD 都要解析+编译+校验 Lua 字节码；Redis 7.0 不支持直接加载预编译的二进制函数库，所谓“二进制格式预编译”是常见误解。
Redis 7.0 的 FUNCTION LOAD 实际做了什么
执行 FUNCTION LOAD 时，Redis 并非简单写入一段二进制，而是：解析 Lua 源码 → 编译为 Lua 5.1 字节码（非平台无关的二进制）→ 校验语法与 Redis API 调用合法性 → 注册函数元信息（name、desc、flags）→ 存入内存函数表。这个过程无法跳过，也没有外部二进制字节码加载接口。
常见错误现象：FUNCTION LOAD 延迟高（尤其首次）、集群中各节点重复加载、重启后函数丢失。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Redis 启动时不自动加载 Function，必须显式调用
FUNCTION LOAD或通过AOF回放（前提是启用了aof-use-rdb-preamble yes且 AOF 中包含该命令） - 不支持从文件直接加载已编译的
.luac（Lua 官方编译产物），Redis 的字节码格式与其内部 Lua 解释器强绑定，且含额外元数据封装 - 即使使用
FUNCTION RESTORE（Redis 7.2+），也只是序列化内存中的函数定义，不是“预编译二进制”，且不跨版本兼容
真正有效的加载加速手段
目标是减少重复编译、避免启动空窗、降低首次调用延迟。核心思路是「一次编译，多处复用」+「启动即就绪」。
- 在部署阶段统一执行
FUNCTION LOAD，将结果写入 AOF 文件（确保appendonly yes+aof-use-rdb-preamble yes），后续 Redis 启动时会自动重放该命令，函数立即可用 - 用
redis-cli --pipe批量加载多个函数，比逐条FUNCTION LOAD减少网络往返和命令解析开销 - 避免在应用启动时动态加载：把
FUNCTION LOAD移到初始化脚本或 CI/CD 部署流水线中，而不是业务代码里首次调用前才执行 - 函数体尽量精简——大段逻辑拆成多个小函数，或把计算密集部分下沉到客户端，因为 Lua 解释器本身无 JIT，长脚本编译耗时显著增加
为什么不能用 luac -o 生成的文件
有人尝试用系统 luac 编译 hello.lua 得到 hello.luac，再喂给 Redis，结果报错 ERR Error compiling function: syntax error 或直接崩溃。这是因为：
- Redis 内嵌的是修改版 Lua 5.1，其字节码结构与标准
luac输出不兼容（比如常量表布局、指令编码、调试信息字段） - Redis 要求函数必须带明确的
#!lua name=xxx flags=...shebang 头，而luac输出纯字节码，无此元信息 - Redis 在加载时会对所有
redis.call()/redis.pcall()调用做白名单校验，标准编译器无法嵌入该检查逻辑
真正需要关注的，是函数注册时机和 AOF 持久化路径是否闭环；所谓“二进制预编译”在 Redis 7.0 中并不存在可落地的实现方式，强行套用只会浪费调试时间。
