Redis Lua脚本可通过“版本路由脚本”实现安全热更新：先用SCRIPT LOAD注册一个原子执行“读版本→取脚本→EVAL”的路由脚本，调用时传入version key和body前缀，由该脚本统一加载并执行对应版本业务逻辑；热更新时按SET新脚本、SET新版本、DEL旧脚本顺序操作，客户端通过缓存并比对version key实现轻量感知与按需重载。
Redis Lua脚本怎么避免每次改完都手动 EVAL 或 EVALSHA？
直接硬编码 EVAL 调用会丢失可维护性，而反复 SCRIPT LOAD + EVALSHA 又容易因脚本变更导致 SHA 不匹配失败。真实生产环境需要“一次注册、多处调用、按需更新”。核心思路是：把脚本内容存进 Redis 的一个 script:xxx:body Key，再用另一个 script:xxx:version Key 存当前生效的版本号（比如 v2），调用时先读版本号，再拼出对应脚本 Key 去 GET，最后 EVAL —— 这样更新只要改两个 Key，无需客户端重启或重新部署。
如何用 Lua 脚本原子地完成“读版本→取脚本→执行”三步？
不能在客户端分三步做：中间可能被其他写操作打断，导致读到旧版本号却拿到新脚本（或反之）。必须用一个 Lua 脚本兜底。这个脚本不存放业务逻辑，只做路由和加载：
local version = redis.call('GET', KEYS[1])
if not version then
return {err='version key missing'}
end
local script_key = KEYS[2] .. ':' .. version
local body = redis.call('GET', script_key)
if not body then
return {err='script not found for version ' .. version}
end
return redis.call('EVAL', body, unpack(ARGV))
调用方式：EVALSHA 这段路由脚本的 SHA（先 SCRIPT LOAD 一次），然后 KEYS[1] 传 script:rate_limit:version，KEYS[2] 传 script:rate_limit:body，其余参数原样透传给业务脚本。
热更新时为什么必须用 SET + DEL 组合，不能只 SET？
只改 script:xxx:version 是不够的——旧版本脚本内容还留在 Redis 里，下次有人手误读错 Key 或缓存了旧版本号，仍可能执行过期逻辑。真正安全的热更新流程是：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
SET script:xxx:body:v3 "..."—— 先写新脚本内容（确保完整） -
SET script:xxx:version v3—— 再切版本号（原子切换） -
DEL script:xxx:body:v2—— 最后删旧脚本（可异步，但建议紧接执行）
注意：DEL 不要放在 SET 前，否则切换瞬间无脚本可读；也不要在同一事务里和 SET 绑定，因为 DEL 成败不影响路由逻辑，反而增加失败风险。
客户端怎么判断脚本是否需要重载？
不是每次调用都去查 script:xxx:version。合理做法是：客户端本地缓存当前已知版本号（如 v2），每次调用前用 GET 检查是否一致；不一致时，才触发一次 GET script:xxx:body:v3 并缓存新内容。关键点：
- 缓存版本号比缓存脚本内容更轻量，且能准确反映变更意图
- 检查用
GET而非EXISTS，避免因网络抖动误判 Key 不存在 - 如果业务对延迟极度敏感，可加一层本地 TTL 缓存（比如 10 秒），但首次不命中必须强一致校验
真正容易被忽略的是错误兜底：当 GET script:xxx:version 返回空，或 GET script:xxx:body:vN 返回空时，客户端不应静默 fallback 到旧版本，而应明确报错并告警——这往往意味着发布流程断裂或 Key 被误删。
