在 Redis 里遇到 WRONGTYPE Operation against a key holding the wrong kind of value，本质是：你对某个 key 执行了“与它真实数据类型不匹配”的命令。Redis 很快、也很“轴”——它不会替你猜业务意图🙂，类型不对就直接拒绝。

---

一、错误成因（抓住根因才能一把梭）

常见触发场景只有三类：

1. Key 类型被写错

• 例如你以为它是 Hash，用了 HGET/HSET，但实际上它曾被 SET 写成 String。

1. Key 冲突（命名不规范）

• 不同业务/模块共用同名 key：A 模块写 String，B 模块按 List 来读，迟早撞车。

1. 历史遗留 + 代码升级

• 早期用 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	GET SET INCR	对 String 用 HGET / LPUSH
Hash	HGET HSET HGETALL	对 Hash 用 GET / LPUSH
List	LPUSH LRANGE RPOP	对 List 用 GET / HSET
Set	SADD SMEMBERS	对 Set 用 GET
ZSet	ZADD ZRANGE	对 ZSet 用 HGET
Stream	XADD XRANGE	对 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 命名规范 + 类型契约

---

六、预防：把“类型契约”当作产品能力来做（长期收益最大）🚀

1. Key 命名规范：用前缀隔离业务域

• 例如：order:hash:1001、order:list:pending，让类型从命名层面可见，减少跨模块误用。

1. 写入前做一次类型断言（关键路径）

• 线上高价值写入前先 TYPE，不匹配就走“迁移/重建”分支，别硬写。

1. 灰度升级要带迁移脚本

• 从 String(JSON) 升级到 Hash 时，先迁移再切流量，别指望自然过期“自愈”。

---

如果你把“报错的 key 名称 + 你执行的命令 + 期望的数据结构（String/Hash/List…）”贴出来，我可以按你的实际场景给出一套更贴近生产的“最小停机修复方案”，包括是否需要备份、是否存在大 key 风险、以及如何在代码侧彻底杜绝再次发生。