蓝易云 ：redis报错WRONGTYPE Operation against a key holding the wrong kind of value
在 Redis 里遇到WRONGTYPE Operation against a key holding the wrong kind of value，本质是：你对某个 key 执行了“与它真实数据类型不匹配”的命令。Redis 很快、也很“轴”——它不会替你猜业务意图🙂，类型不对就直接拒绝。
一、错误成因（抓住根因才能一把梭）
常见触发场景只有三类：
Key 类型被写错
例如你以为它是 Hash，用了
HGET/HSET，但实际上它曾被SET写成 String。
Key 冲突（命名不规范）
不同业务/模块共用同名 key：A 模块写 String，B 模块按 List 来读，迟早撞车。
历史遗留 + 代码升级
早期用 String 存 JSON，后期改成 Hash 拆字段，但没做迁移/兼容。
二、快速定位（3 步完成“事实核验”）🔍
1）确认 key 的真实类型
TYPE your:key解释：
TYPE返回当前 key 的数据类型（string/hash/list/set/zset/stream 等）。这是排错的第一性原理：先确认“它是什么”，再决定“你该用什么命令”。
2）确认 key 是否存在、是否有生命周期
EXISTS your:key TTL your:key解释：
EXISTS：判断 key 是否存在（1=存在，0=不存在）。避免你在“空 key”上做无意义猜测。TTL：查看剩余过期时间（-1=永不过期，-2=不存在）。很多线上错配来自“旧 key 没过期还在”。⏳
3）查看底层编码（辅助判断是否“大 key / 风险操作”）
OBJECT ENCODING your:key MEMORY USAGE your:key解释：
OBJECT ENCODING：看 Redis 内部编码方式，用于判断是否可能是压缩/整数集合等实现细节。MEMORY USAGE：估算该 key 占用内存，帮助你决定删除策略（大 key 更建议用 UNLINK 而不是 DEL）。
三、命令与类型对照表（避免“拿锤子拧螺丝”）🧰
| 数据类型 | 正确读写命令示例 | 常见误用导致 WRONGTYPE |
|---|---|---|
| String | GETSETINCR | 对 String 用HGET/LPUSH |
| Hash | HGETHSETHGETALL | 对 Hash 用GET/LPUSH |
| List | LPUSHLRANGERPOP | 对 List 用GET/HSET |
| Set | SADDSMEMBERS | 对 Set 用GET |
| ZSet | ZADDZRANGE | 对 ZSet 用HGET |
| Stream | XADDXRANGE | 对 Stream 用GET |
四、修复方案（按“业务价值/风险”选策略）
方案 A：确认无价值数据，直接删除（最快）
UNLINK your:key解释：
UNLINK：异步删除，对大 key 更友好，避免DEL造成主线程阻塞。删除后你再用正确类型的写入命令重新创建即可。
如果你明确是小 key，也可以用
DEL your:key；但在生产环境，默认优先UNLINK更稳。
方案 B：保留旧数据，做“迁移/改名”再重建（最稳）
RENAME your:key your:key:bak解释：
RENAME：把旧 key 改名留存，相当于做一次“可回滚”的快照。之后你可以用新 key 写入正确结构，避免直接覆盖导致数据不可逆丢失。
方案 C：典型场景示例（String ↔ Hash 冲突）
假设你想写 Hash，但 key 其实是 String：
TYPE user:1001 HSET user:1001 name "Tom"解释：
TYPE user:1001若返回 string，说明HSET必然触发 WRONGTYPE。正确做法是：先备份或删除旧 key，再写 Hash：
RENAME user:1001 user:1001:bak HSET user:1001 name "Tom" HSET user:1001 age "18"解释：
先
RENAME保留旧值，避免“误删背锅”。再
HSET按 Hash 结构落地，后续读取用HGET/HGETALL。
五、推荐排错工作流（给团队做 SOP 用）✅
发现 WRONGTYPE -> TYPE key（确认真实类型） -> EXISTS/TTL（确认是否旧 key 残留） -> 判断是否要保留数据 -> 需要保留：RENAME key key:bak -> 按新类型重建 -> 不需保留：UNLINK key -> 按新类型重建 -> 代码层修复：统一 Key 命名规范 + 类型契约六、预防：把“类型契约”当作产品能力来做（长期收益最大）🚀
Key 命名规范：用前缀隔离业务域
例如：
order:hash:1001、order:list:pending，让类型从命名层面可见，减少跨模块误用。
写入前做一次类型断言（关键路径）
线上高价值写入前先
TYPE，不匹配就走“迁移/重建”分支，别硬写。
灰度升级要带迁移脚本
从 String(JSON) 升级到 Hash 时，先迁移再切流量，别指望自然过期“自愈”。
如果你把“报错的 key 名称 + 你执行的命令 + 期望的数据结构（String/Hash/List…）”贴出来，我可以按你的实际场景给出一套更贴近生产的“最小停机修复方案”，包括是否需要备份、是否存在大 key 风险、以及如何在代码侧彻底杜绝再次发生。