evalsha 返回“noscript”错误是因为脚本未预先加载到redis中；常见原因包括首次执行、实例重启、集群中仅部分节点加载脚本，需通过script load确保脚本存在后再调用evalsha。
为什么 EVALSHA 有时返回 “NOSCRIPT” 错误
直接调用 EVALSHA 前，Redis 必须已缓存对应 SHA1 值的脚本。如果脚本是首次执行、或 Redis 实例重启过、或用了集群且脚本只在部分节点加载，EVALSHA 就会失败并返回 NOSCRIPT。这不是 Lua 语法问题，而是脚本未注册的信号。
常见误操作：在连接复用场景（如连接池）中，假设脚本“已经存在”，跳过加载步骤；或者在 Redis Cluster 中只对一个节点 EVAL，却对其他节点直接 EVALSHA。
- 每次新连接建立后，应先用
EVAL或SCRIPT LOAD确保脚本已加载 - 集群环境下，需确保脚本被发送到所有涉及的哈希槽所在节点（通常靠 key 的 hash tag 或显式路由）
- 生产中建议封装一个
evalsha_safe辅助函数：先EVALSHA，捕获NOSCRIPT后自动 fallback 到EVAL
如何用 SCRIPT LOAD + EVALSHA 替代重复 EVAL
EVAL 每次都传输完整脚本字符串，带宽和解析开销大；而 SCRIPT LOAD 只传一次，返回 SHA1 值，后续全用 40 字符的 EVALSHA 调用，几乎零带宽增量。
关键不是“能不能”，而是“怎么保证加载时机和范围”。例如以下 Python 片段（使用 redis-py）：
script = "return redis.call('incr', KEYS[1]) + tonumber(ARGV[1])"
sha = r.script_load(script) # 返回类似 '98a2e...' 的字符串
result = r.evalsha(sha, 1, 'counter', '5') # 正确调用
-
SCRIPT LOAD是幂等操作，重复执行返回相同 SHA，可放心在初始化阶段多次调用 - SHA 值由脚本内容决定，空格、换行、注释都会影响结果，上线前建议固定格式化脚本（如用
lua-minify或 CI 校验） - 不建议把 SHA 写死在代码里——不同 Redis 版本或编译选项下，Lua 解析行为可能微变，导致 SHA 不一致
动态调整 Lua 脚本逻辑的可行边界
Redis 的 Lua 沙箱禁止任何外部 I/O、系统调用、随机数（math.random 被重写为确定性伪随机）、时间获取（os.time 禁用）。所谓“动态”，只能靠传入的 KEYS 和 ARGV 参数驱动分支逻辑，不能读配置、不能查网络、不能根据当前时间做决策。
- 支持条件分支：
if ARGV[1] == 'v2' then ... else ... end - 支持参数化行为：比如
ARGV[1]控制是否触发EXPIRE，ARGV[2]作为 TTL 秒数 - 不支持运行时加载新脚本或 patch 已加载脚本——
SCRIPT FLUSH会清空全部，不可局部更新 - 调试困难：出错时只有
(error) ERR Error running script...，建议开发期配合redis-cli --eval本地验证，再加redis.log(redis.LOG_WARNING, ...)输出中间值（仅限 debug 模式）
集群模式下 EVALSHA 的实际约束
Redis Cluster 要求脚本中所有 KEYS 必须落在同一哈希槽，否则报 CROSSSLOT。但更隐蔽的问题是：SCRIPT LOAD 只作用于当前连接的目标节点，其他节点并不知道这个脚本。
- 如果你的 key 是
{user}:123和{user}:456，它们同槽，SCRIPT LOAD发给任意一个节点即可，EVALSHA也能路由正确 - 但如果 key 是
user:123和order:789，无 hash tag，默认不同槽，必须改用{user}:123/{user}:789强制同槽，否则连EVAL都失败 - 没有跨槽脚本的取巧办法：Cluster 不允许，单靠客户端分片或改用 Redis Standalone 是唯一出路
真正省带宽的前提是脚本稳定、参数灵活、部署可控。一旦脚本频繁变更，维护 SHA 生命周期的成本可能反超带宽节省——这时候不如老实用 EVAL，至少语义清晰。
