症状
本篇指南处理“Redis WRONGTYPE — 键持有的类型不符”。请从症状出发，按顺序执行诊断，在推进前确认每个假设；随后通过修复与验证步骤闭环。
可观察到的症状包括：
- WRONGTYPE 操作针对的键持有错误类型的值
- 命令对新键可用，对既有键失败
- 部署改变键的存储方式后出现该错误
诊断
先在隔离环境中复现故障，再按顺序执行以下检查，逐步缩小范围。
步骤 1
redis-cli TYPE cache:user:1返回的类型（string、hash、list、set、zset）指明哪些命令可用。
步骤 2
redis-cli SET k v; redis-cli HSET k f v第二条命令报 WRONGTYPE，证明该键是字符串而非 hash。
常见诱因（按出现频率排序）：
- 先存为字符串键，随后用 hash/list 命令操作（或反之）
- 不同功能共用键名，却存储不同结构
- 代码变更后旧键仍保留原类型
根因
Redis 键只有一种类型，在首次写入时确定。用其他类型的命令操作会抛 WRONGTYPE，这常揭示键名冲突或部署间的存储格式变更。
修复
使用与键类型匹配的命令，按结构为键加命名空间（user:1:profile 为 hash、user:1:token 为字符串），并在格式变更时迁移或删除陈旧键。
注意：对类型不符的键执行 DEL 会销毁数据；迁移时删除前应确认该键可安全移除。
# inspect before operating
redis-cli TYPE user:1:profile # -> hash
redis-cli HGETALL user:1:profile
# namespace by structure to avoid collisions
redis-cli HSET user:1:profile name alice
redis-cli SET user:1:token abc123 # different key, string type
# migrate by writing the new type under the right key, then delete the old验证
用正确类型重跑命令并确认成功；验证 TYPE 报告预期结构。
修复后补充一条回归测试，复现原始症状，防止问题再次出现。
这类故障通常是环境问题而非纯逻辑错误，因此在缺陷记录中应写明完整命令、环境变量与工作目录。请用最小的脚本复现，待最小用例清楚后再扩大范围。为这类故障准备一份简短的排查清单，能显著减少下次排障时间。