redis 7.0 中 function load 注册的函数自动持久化并同步至从节点，而 script load 的脚本仅存于内存、不复制不落盘；function 作为数据一部分写入 rdb/aof 并在 psync 中推送，重启或故障切换后仍可用，script 则需人工重载且易报 noscript 错误。
Redis 7.0 的主从复制会自动同步 FUNCTION 加载的函数，而旧版的 SCRIPT LOAD 脚本默认不参与主从复制，也不持久化——这是最核心的区别。
FUNCTION LOAD 确保函数随 RDB/AOF 和主从流一起传播
从 7.0 开始，FUNCTION LOAD 注册的函数被视为“数据的一部分”，不是临时执行逻辑：
-
FUNCTION LOAD后的函数会写入 AOF 文件（如果启用 AOF），也会被包含在 RDB 快照中 - 主从握手阶段，主节点会在
PSYNC响应中主动推送已注册的函数到从节点 - 从节点重启加载 RDB 或重放 AOF 时，函数自动重建，无需人工干预
- 即使发生故障切换（如哨兵触发 failover），新主节点仍持有全部函数定义
SCRIPT LOAD 的脚本只存于当前节点内存，断连即丢失
在 Redis 7.0 之前（及 7.0 中继续使用 SCRIPT LOAD 时），Lua 脚本的行为完全相反：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
SCRIPT LOAD返回的 SHA1 值仅缓存在当前实例内存，不落盘、不复制 - 主节点重启后，所有已
LOAD的脚本消失；从节点重连后不会重新获取，EVALSHA直接报错NOSCRIPT - 用户必须自行维护脚本源码，在每个节点启动前用
SCRIPT LOAD重新注册（常见于初始化脚本或部署流水线） - 没有机制校验主从之间脚本内容是否一致，靠人工对齐
为什么 FUNCTION 不再需要 EVALSHA + 缓存管理
旧版依赖 EVALSHA 是为了节省带宽和避免重复解析，但代价是状态不可靠；FUNCTION 改变了这个权衡：
- 函数名直接调用（如
FCALL myhash.get 1 user:123），语义清晰，无需拼接 SHA - 函数元信息（name、description、flags）和 Lua 代码体一同序列化传输，主从间一致性由复制协议保证
- 即使网络中断后部分重同步（
PSYNC），函数定义也不会丢失——因为它们属于“数据快照”的一部分，不是运行时缓存 - 注意：
FUNCTION KILL是立即生效的，且会同步到从节点；但FUNCTION FLUSH需谨慎，它会清空所有函数并触发全量同步重传
真正容易被忽略的是：如果你混合使用 FUNCTION 和 SCRIPT，两者互不感知。比如一个 FUNCTION 内部调用 EVAL，那段内联 Lua 依然不受保护——只有显式 FUNCTION LOAD 的才进复制管道。
