redis-check-rdb返回“rdb file is ok”仅说明文件结构合法，即魔数、版本号、操作码序列和eof标记等基础格式正确，但无法保证数据可用性，如value截断、字段缺失或key漏读等隐性损坏仍可能发生。
redis-check-rdb 只能告诉你 RDB 文件结构是否合法，不能证明数据可用 —— 这是它最常被误用的地方。
redis-check-rdb 返回 “RDB file is OK” 说明什么
它只确认了文件开头魔数（REDIS）、版本号、操作码序列、EOF 标记等基础结构没崩。常见通过场景包括：
• 文件未被截断（无 Unexpected EOF）
• 没有错位的 RDB_OPCODE_SELECTDB 或非法 type 字节
• LZ4 解压流能完整消费（若启用 compression）
但以下问题它完全无法发现：
• GET user:1001 返回空，实际 value 在写入时被静默截断
• HGETALL config 缺失 2 个字段，因哈希编码段二进制翻转
• KEYS * 漏掉 17% 的 key，因某段 RDB_OPCODE_RESIZEDB 后续解析偏移错乱
为什么必须用相同大版本的 redis-check-rdb
Redis 7.0+ 的 RDB 格式引入了 64 位长度字段、新 opcode（如 RDB_OPCODE_FUNCTION2）、模块辅助数据（RDB_OPCODE_MODULE_AUX）。若用 6.2.x 的工具检查 7.0.x 生成的 RDB：
• 会直接报 Invalid RDB version 或 Unknown RDB opcode
• 即使跳过未知 opcode，后续长度解析也会全盘错位，导致假阳性“OK”
• 工具本身可能 panic 退出（尤其遇到 rdb_version_8_with_64b_length_and_scores.rdb 类型）
验证方式：redis-check-rdb --version 与生成该 RDB 的 redis-server --version 输出前两位（如 7.0）必须一致
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Checksum OK ≠ 数据可加载
末尾 CRC64 校验（rdbchecksum yes 生效）仅覆盖从文件头到 EOF 前 8 字节的内容，不包含：
• 压缩头（LZ4 frame header）损坏
• 某个 RDB_OPCODE_EXPIRETIME_MS 后紧跟非法 type 字节（导致后续所有 key 被跳过）
• __redis__:keyspace 等内部 key 的结构错乱（不影响校验和，但干扰 INFO 解析）
典型现象：redis-check-rdb dump.rdb 输出 Checksum OK，但 redis-server --dbfilename dump.rdb --port 6380 启动时报 ERR Wrong signature for RDB file 或直接 abort
真正有效的验证必须加载运行
离线工具只能筛掉明显废件；数据逻辑正确性必须靠 Redis 实例自己读一遍：
• 启动临时实例：redis-server --port 6380 --dir /tmp --dbfilename dump.rdb --save "" --appendonly no
• 连接后立即执行：INFO keyspace 看 db0:keys=1234,expires=567 是否符合预期基数
• 对关键业务 key 抽样：TYPE user:1001 → 若为 hash，再 HLEN user:1001 并比对历史快照值
• 避免用 KEYS * 扫全量（慢且阻塞），改用 SCAN 0 COUNT 1000 分批验证
注意：若 RDB 含大量过期 key，INFO keyspace 显示的 expires 数可能远小于实际写入数——这是正常行为，不代表损坏
最容易被忽略的是：校验必须在与生产环境同构的 Redis 版本、同配置（尤其是 compression 和 rdbchecksum）下进行。差一个 patch 版本，或压缩开关不一致，都可能导致“离线 OK，加载失败”。
