必须用 scan + type 过滤出纯 string key 再 get：scan 避免阻塞，type 确认类型为 "string" 后才执行 get，禁用 keys；导出时注意 value 编码、换行符处理及内存控制。
直接导出全部 String 类型数据，不能只靠 GET 或 KEYS <em></em> 简单拼凑——因为 KEYS 会阻塞 Redis，且返回的 key 混杂所有类型；而 GET 对非 String key 会报错 WRONGTYPE Operation against a key holding the wrong kind of value。必须先过滤、再取值。
用 SCAN + TYPE 过滤出纯 String key
这是最安全、生产环境唯一推荐的方式。SCAN 避免阻塞，TYPE 命令逐个确认类型，只对 string 类型执行 GET。
-
SCAN游标需循环调用，每次带count=1000参数提升效率 - 每个 key 必须显式执行
TYPE key，响应为"string"才继续GET - 不要依赖客户端缓存的“已知类型”——Redis key 类型可随时被覆盖（比如先
HSET再SET） - Python 示例中，
r.type(key).decode() == "string"是必要判断，跳过这步会导致脚本中断
避免用 KEYS * 导出 String 数据
KEYS * 在数据量 >10 万时极易触发 Redis 主线程卡顿，集群环境下还可能被禁用（redis.conf 中 rename-command KEYS ""）。即使你后续加了 TYPE 判断，也已经把风险前置了。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 错误写法：
redis-cli KEYS "*" | xargs -I{} redis-cli TYPE {} | grep string -q && redis-cli GET {}—— 多次连接开销大，且KEYS本身已违规 - 正确替代：始终用
SCAN 0 MATCH * COUNT 1000起手，游标推进到"0"结束 - 某些运维平台（如阿里云 Redis 控制台）会自动拦截
KEYS，但放行SCAN，这点要提前验证
导出格式选纯文本还是 JSON？
取决于下游用途。纯文本（key:value）适合快速人工核对或导入其他 KV 存储；JSON 更利于程序解析，但要注意 GET 返回的 value 是字节串，需 decode，且空值（None）和二进制内容需额外处理。
- 简单场景用
f.write(f"{key.decode()}:{value.decode() if value else ''}\n")即可 - 若 value 含换行符或不可见字符，
repr(value)比decode()更稳妥，避免文件损坏 - 不建议直接
json.dump()全量数据——内存占用陡增，100 万 key 可能吃掉 2GB+ RAM - 导出大库时，务必加
time.sleep(0.001)（每千条一次），防客户端缓冲区溢出
真正麻烦的不是“怎么取”，而是“怎么不崩”。SCAN 的游标管理、TYPE 的响应判等、value 的编码容错——漏掉任意一环，脚本在半夜跑一半就挂，而你收到告警时，Redis 已经又写入了新数据。
