直接用Eval传Lua脚本易出错，主因是Go字符串转义破坏脚本（如\n、"）及keys/args未严格分离；正确做法是用反引号包裹脚本、显式拆分非空keys切片与args参数，并根据调用频率选择Eval或ScriptLoad+EvalSha组合。
为什么直接用 Eval 传 Lua 脚本容易出错？
Go 中用 go-redis 执行 Lua 脚本最常见错误是脚本内容被 Go 字符串转义破坏，比如 \n 或 " 混入后 Lua 解析失败；另一个坑是键与参数没按 Redis 要求严格分离——EVAL 命令强制前 N 个参数为 key，之后才是 arg，但很多人把所有参数一股脑塞进 args 切片里，导致 KEYS[1] 取不到值。
正确做法是显式拆分：keys 传给 Eval 的第一个参数（[]string），args 是后续任意数量的值（...interface{}）。
-
keys必须是非空切片，哪怕只操作一个 key，也要写成[]string{"mykey"}，不能传nil或空切片 - 脚本字符串建议用反引号
`包裹，避免手动转义双引号和换行 - 如果脚本里用了
redis.call("get", KEYS[1])，但调用时keys是空的，Redis 会直接报错ERR wrong number of arguments
Eval 和 EvalSha 怎么选？
两者本质一样，区别在于传输方式：Eval 每次都发完整脚本，适合一次性、不频繁的逻辑；EvalSha 先用 ScriptLoad 把脚本缓存到 Redis，之后只传 SHA1 校验值（40 字符），省带宽也快。但要注意：如果 Redis 实例重启或执行了 SCRIPT FLUSH，已加载的脚本就没了，EvalSha 会返回 Nil 错误。
- 高频调用脚本（如限流、原子计数）必须用
ScriptLoad+EvalSha组合 - 调试阶段优先用
Eval，脚本改一次不用手动 reload - 生产环境部署前，建议在服务启动时预加载脚本并校验 SHA，例如：
client.ScriptLoad(ctx, script).Result()，捕获redis.Nil表示已存在，其他错误要 panic 或告警
如何安全处理 Lua 脚本返回值？
go-redis 的 Eval 返回 Cmd，其 Val() 方法会自动把 Lua 类型转成 Go 类型：数字→int64 或 float64，字符串→string，表（table）→[]interface{}，nil→nil。但类型不确定时直接断言会 panic。
立即学习“go语言免费学习笔记（深入）”；
例如 Lua 返回 return {1, "ok", true}，Go 里得到的是 []interface{}，其中第三个元素是 bool，但如果你写 v[2].(string) 就崩了。
- 永远用类型断言 + ok 模式：
if s, ok := v.(string); ok { ... } - 对数组结果，先判断
v是否为[]interface{}，再逐个检查子项类型 - 如果 Lua 可能返回
nil（比如redis.call("get", "missing")），Val()返回nil，别直接解引用 - 需要统一返回结构时，Lua 侧最好用
cjson.encode()（需 Redis 加载 cjson 库）转成 JSON 字符串，Go 侧用json.Unmarshal解析，避免类型模糊
本地调试 Lua 脚本的最快方法
别在 Go 里反复改代码跑测试——先用 redis-cli --eval 直接验证脚本逻辑是否正确。命令格式固定：redis-cli --eval script.lua key1 key2 , arg1 arg2，注意逗号前后有空格，逗号前是 keys，后面是 args。
- 脚本里用
redis.log(redis.LOG_WARNING, "debug:", KEYS[1], ARGV[1])输出调试信息（需 Redis 配置loglevel warning） - 如果脚本依赖 Redis 模块（如 RediSearch 的
FT.SEARCH），本地 redis-cli 可能不支持，得连真实实例测 - Go 测试中可用
github.com/alicebob/miniredis/v2启一个内存版 Redis，它支持EVAL，但不支持所有 Lua 命令（比如没有redis.sha1hex），复杂脚本仍要真机验证
Redis Lua 脚本真正的难点不在语法，而在键空间约束、返回值类型不确定性、以及缓存生命周期管理。哪怕一行脚本，也要想清楚：它会访问哪些 key？是否可能被其他客户端并发修改？SHA 值有没有在服务重启后失效？这些地方一漏，线上就静默出错。
