Redis 单个 HGETALL 正常，遍历 scan_iter 却报 WRONGTYPE：检查混合类型

已知某个键能用 hgetall() 读出内容，但把 scan_iter() 返回的所有键都交给同一个方法时，redis-py 报 WRONGTYPE Operation against a key holding the wrong kind of value。这种差异首先要查键对应的数据类型：SCAN 遍历数据库中的键，不会默认只返回 Hash。

另一个容易混在一起的现象是把键写成 str(key) 后不再报错，却全部返回空字典。这可能只是查了另一个不存在的键，不能当成修复。

找到出错的键，检查实际类型

记录失败时的键名及 Redis 连接目标，包括逻辑数据库。下面是只读检查示例，record:42 应替换为失败的键；使用与应用一致的连接和认证配置：

TYPE record:42

返回 hash，才适合 HGETALL；返回 string、list 等，需要使用对应类型的读取方式。返回 none 表示检查时键已经不存在，可能过期或被删除。只抽查一个正常键无法证明整批键都是 Hash。

键名看起来具有相同前缀，也不保证类型一致。检查哪些写入代码使用了 SET，哪些使用了 HSET，以及不同功能是否复用了相同键名。不要为了让读操作通过就删除或覆盖异常键，其中可能存着另一项业务的数据。

遍历时保留键本身，按类型选择读取

下面假设 rc 是已经配置好的同步 redis-py 客户端，示例只读取 record:* 前缀下的 Hash。按实际业务修改前缀，并避免把整库内容输出到日志：

for key in rc.scan_iter(match="record:*"):
    kind = rc.type(key)
    if kind not in (b"hash", "hash"):
        continue
    data = rc.hgetall(key)
    # 在这里处理当前 Hash 的 data

类型响应可能是 bytes 或字符串，取决于客户端解码设置，所以示例兼容两者。若这批键按设计必须全部是 Hash，不能仅跳过错误就结束处理；还要记录类型冲突的键，检查写入方和命名约定，避免漏掉业务记录。

TYPE 与 HGETALL 是两个独立请求。其他客户端若在两次请求之间删除并重建键，仍可能出现 WRONGTYPE。需要一致性保证的任务应协调写入方或设计原子读取流程；不要捕获所有异常后继续运行，让权限、连接或类型错误一起消失。

Redis 6.0 起，SCAN 支持服务端类型过滤；当前 redis-py 用 _type 参数传递它：

for key in rc.scan_iter(match="record:*", _type="hash"):
    data = rc.hgetall(key)
    # 在这里处理当前 Hash 的 data

旧服务端或不支持该参数的客户端不能直接套用。类型过滤同样不锁定键，过滤之后被改写的情况仍需处理。SCAN 也不是数据库快照，可能重复返回键；对遍历结果有写入或计数动作时，应让重复处理安全。

为什么 str(key) 后变成空字典

默认未启用 decode_responses 时，键可能表现为 b'record:42'。直接把这个 bytes 对象交给 redis-py 可以访问原键；str(key) 则得到带有 b 和引号的文本 "b'record:42'"，键名已经改变。

HGETALL 对不存在的键返回空结果，这就解释了“报错消失，数据也没了”。保持原 bytes 键即可。项目确实采用文本键且需要字符串时，可以统一配置 decode_responses=True，或按明确的编码解码；不要对任意二进制键强行按 UTF-8 解码，也不要只改一处客户端解码设置而忽略调用方对 bytes 的依赖。

修复后的验收应包含已知正常 Hash、同前缀的其他类型键及不存在的键：正常记录仍能读取，其他类型按业务规则报告或跳过，不存在的键按预期处理。在实际任务的一轮完整遍历中还应核对遗漏和重复处理，不能以“没有异常”代替数据完整性检查。