redis string类型原生支持二进制数据存储，无需base64编码，set/get可直接存取原始字节流；其二进制安全特性保证字节序列原样存储与返回，但需注意客户端配置（如decode_responses=false）及大值性能限制。
Redis String 类型原生支持二进制数据存储，不需要 Base64 编码或额外转换——只要客户端能传 bytes，服务端就原样存、原样取。
直接用 SET 和 GET 存取原始字节流
这是最常用也最稳妥的方式。Redis 的 String 是二进制安全的，SET 接收任意字节序列，GET 返回完全一致的 bytes。
- Python 示例：
r.set("img:123", b"\x89PNG\r\n\x1a\n...")→r.get("img:123")返回相同bytes - 注意：某些客户端（如旧版
redis-py）默认将响应 decode 成 str，需显式指定decode_responses=False或直接接收bytes - 不建议对大文件（如 >1MB）频繁用单个
SET，因为 Redis 是单线程处理命令，大 value 会阻塞其他请求；可考虑分片或改用外部存储 + Redis 存 URL - 最大单值限制为 512MB，但实际应控制在几十 MB 内，避免 RDB/AOF 持久化压力过大
SETBIT 不是用来存二进制文件的
很多人看到 “位操作” 就想用来拼 PNG 或序列化数据，这是典型误用。它只适合稀疏布尔状态管理。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
SETBIT key 100 1只设置第 101 位（offset 从 0 开始），不是第 100 字节；要还原一个字节（8 位），得调 8 次SETBIT，且 offset 要按 big-endian 算高位在前，极易错位 - 存 1KB 图片需 8192 次网络往返，延迟和失败率陡增；中间自动补零的字节全是
\x00，无法精确控制每个字节的 8 位值 - 真实适用场景：用户签到（
SETBIT sign:20260713 uid 1）、布隆过滤器、权限位图 —— 关心的是“第 N 位是不是 1”，而不是“第 N 字节是什么” - 批量位操作请用
BITFIELD（Redis 3.2+），它支持一次读写多个位段，比多次SETBIT高效得多
哈希表（HASH）适合结构化二进制分段存储
当二进制数据有逻辑子结构（如图片含缩略图、元数据、原始图），用 HASH 比单个 String 更易维护。
-
HSET img:123 thumb "..." meta "..." raw "..."，各字段独立存取，不用解析整块数据 - 注意
HGETALL会一次性拉取全部字段，大数据量时慎用；优先用HGET按需取字段 - 所有
HVALS/HGET返回值仍是二进制安全的，不会截断\x00或做编码 - 内存开销略高于纯 String（多了字段名和哈希表结构），但换来的是可读性和灵活性
最容易被忽略的一点是：Redis 客户端对二进制数据的处理差异很大。比如 redis-cli 默认以 UTF-8 显示，遇到非文本内容会乱码或报错，必须加 --raw 参数；而 Python 的 redis-py 在连接时若没关 decode_responses，GET 会抛 UnicodeDecodeError。这些不是 Redis 的问题，而是管道两端的约定没对齐。
