应先用EXISTS检查key存在，再用TYPE校验类型是否为string，因GET对非string类型会直接报错且无法捕获；TYPE返回值严格区分大小写和拼写，须用==全等比较。
Redis Lua 脚本里怎么判断一个 key 存在且是 string 类型
直接用 redis.call("TYPE", KEYS[1]) == "string" 不够安全——TYPE 在 key 不存在时返回 "none"，但如果你没提前检查 key 是否存在，后续 GET 或 INCR 就可能报错或行为异常。
真正稳妥的做法是先确认 key 存在，再校验类型：
if redis.call("EXISTS", KEYS[1]) == 0 then return error("key not exists") endlocal t = redis.call("TYPE", KEYS[1])if t ~= "string" then return error("expected string, got " .. t) end
注意：EXISTS 返回的是整数 0/1，不是布尔值；Lua 里不能用 == false 判断。
为什么不能用 GET 结果是否为 nil 来判断类型
GET 对非 string 类型的 key 会直接报错：WRONGTYPE Operation against a key holding the wrong kind of value，这个错误无法在 Lua 里被 pcall 捕获（Redis 内置 Lua 环境禁用了 pcall 和 xpcall）。
所以别这么写：
local val = redis.call("GET", KEYS[1]) -- 如果 key 是 list，这行就直接中断脚本
正确路径永远是：先 EXISTS → 再 TYPE → 最后按类型选操作函数（比如 GET、LLEN、HGETALL）。
处理 hash/set/zset 时 TYPE 判断的常见误判点
TYPE 返回的是字符串字面量，大小写敏感，固定为 "string"、"list"、"set"、"zset"、"hash"，没有复数、缩写或别名。
容易踩的坑：
- 写成
t == "hashes"或t == "HASH"→ 永远不匹配 - 对 zset 错误记成
"sorted_set"→ 实际是"zset" - 用
string.find(t, "set")模糊匹配 →"zset"和"set"都会命中，逻辑失控
建议严格用 == 全等比较，加注释说明依据：-- Redis TYPE command returns exact lowercase strings per https://redis.io/commands/type
在 EVALSHA 场景下 TYPE 判断失效的隐性风险
如果脚本通过 EVALSHA 执行，而 Lua 缓存被清空（比如 SCRIPT FLUSH），下次执行会 fallback 到 EVAL，但行为一致——真正的问题出在「多 key 场景下的原子性假设」。
例如你写了：
if redis.call("TYPE", KEYS[1]) == "string" then redis.call("DEL", KEYS[1]) end
看起来没问题，但如果 KEYS[1] 在 TYPE 和 DEL 之间被其他客户端改成 list，DEL 仍会成功（DEL 支持所有类型），但你的业务逻辑可能预期只删 string。这时候 TYPE 判断只是“快照校验”，不是锁。
结论：TYPE 判断适合做前置防御，不适合替代业务层的并发控制。真要强一致性，得配合 WATCH + EVAL 或外部协调服务。
