redis-py 读取 pickle 数据时报 UnicodeDecodeError

Redis 中的值能正常写入，Python 用 get() 读取却出现 UnicodeDecodeError，例如提示 UTF-8 无法解码开头的 0x80。如果值由 pickle、压缩程序或其他二进制编码生成，而客户端设置了 decode_responses=True，先检查客户端是否把二进制值当成文本解码。

Redis String 可以保存任意字节，不保证其中内容是 UTF-8 文本。解码失败本身不能证明值损坏。redis-py 8.1.0 的编码器仍会按配置的编码与错误处理方式解码，不能指望安装另一个解析器就自动把失败的响应变成 bytes。

为二进制数据使用明确的客户端配置

如果文本业务与二进制库可以分别使用客户端，为二进制部分建立 decode_responses=False 的专用客户端或连接池。连接目标、数据库、认证、TLS 与超时应使用原项目批准的配置，不能为了改解码设置而切到另一个 Redis 实例。

下面假设 binary_client 已按上述方式配置，示例只读取：

raw = binary_client.get("payload:42")
if raw is None:
    # 按业务规则处理不存在的键
    pass
else:
    # 将 bytes 交给已确定的数据格式处理流程
    pass

键名为示例。业务解析流程需要区分键不存在、空字节串和有效载荷，不能把三者合并成一个假值判断。不要为了查看数据把完整二进制内容或秘密写入日志。

如果第三方库内部读写自己的二进制数据，应通过它支持的配置入口传入兼容客户端，检查它是否还要求特定的连接池或解码模式。仅改外层一个 get()，不能修复库内部继续使用文本连接的路径。

一个客户端也可以先保留字节，再按字段解码

必须共享一个客户端时，可以统一保留 bytes，在业务确实定义为 UTF-8 的文本字段处显式解码。这样返回类型由数据约定决定，而不是由“这次恰好能不能解码”决定。

不要在并发请求之间临时修改正在使用的客户端或池的编码器。池里的连接与解析器可能已有各自设置，调用方也可能依赖原来的字符串返回值。调整前应检查所有消费者，并按受控生命周期替换配置。

使用 errors="ignore" 或 "replace" 会丢失或改写无法解码的字节，不适合修复 pickle 等二进制载荷。捕获解码异常后把异常对象中的片段当完整 Redis 值，也不能保证涵盖 pipeline 或各种响应形状。

如果数据是 pickle，只能进入可信的反序列化流程。改为 bytes 不会消除反序列化不可信 pickle 的代码执行风险，不应把一次读取修复写成对任意输入直接调用 pickle.loads() 的示例。

核对读到的是原键和原值

保持原来的 bytes 键，不要用 str(key) 生成带 b 和引号的新键名。这个问题与 SCAN 后 HGETALL 报 WRONGTYPE 不同：这里可能读取的是合法 String，只是值不能按文本解码。

验收包含已知二进制值、已定义的文本值和不存在的键，确认返回类型、字节内容与业务解析符合约定。pipeline 和第三方库内部读取也应按实际入口核对，不能只检查单个 get() 不再抛异常。