不能直接用 cat 或 grep 查看 aof 文件，因其采用 resp 协议编码的二进制友好格式（如 *n、$m、\r\n），导致 cat 输出不可读，grep 易误匹配长度字段而非真实命令。
为什么不能直接用 cat 或 grep 查看 AOF 文件
AOF 文件不是纯文本日志，而是按 RESP 协议编码的二进制友好格式：每条命令前有 *N 表示参数个数，$M 表示后续字段长度，结尾必须是 \r\n。直接 cat appendonly.aof 会看到大量不可读的 $3\r\nSET\r\n$4\r\nname\r\n 混合内容；grep SET 更可能匹配到长度字段（比如 $3 中的 SET 字符串）而非真实命令，结果完全不可信。
waoffle 是目前最实用的 AOF 解析工具
它能把原始 AOF 流准确还原成人类可读的 Redis 命令行，且支持管道过滤和重定向。安装后执行：waoffle appendonly.aof > commands.txt
输出类似：SELECT 0SET user:1001 "original"EXPIRE user:1001 3600DEL user:1001
关键点：
- 不依赖 Redis 进程运行，离线解析，安全
- 自动处理多参数命令（如
HSET,LPUSH），不会把$5\r\nfield1\r\n$3\r\nval\r\n拆错行 - 对模块命令（如
JSON.SET）也支持，只要 Redis 版本与 waoffle 兼容（v2.0+ 支持 Redis 7.0） - 若需进一步转 JSON，可用
awk或jq处理输出的命令行，例如：waoffle appendonly.aof | awk '/^SET/ {print "{\"cmd\":\"SET\",\"key\":\"" $2 "\",\"val\":" $3 "}}"' | jq -s '.' > events.json
想定位某次误操作？别删 AOF，用时间戳+命令组合过滤
AOF 本身不含时间戳，但如果你开启了 appendfsync everysec 并配合系统日志（如 dmesg 或应用层打点），就能大致对齐时间窗口。更可靠的做法是：
- 先用
waoffle导出全部命令到文件 - 结合业务线索缩小范围，比如误操作 key 前后常伴随
GET、INCR或HGETALL，用grep -A3 -B3 "user:1001"查上下文 - 注意
EXPIRE/PEXPIREAT类命令会重置过期逻辑，重放时不是“回到当时时间”，而是“按当前时间重新设过期”——所以回溯重点应是值变更链，而非时间戳 - 如果怀疑是某次
FLUSHDB或FLUSHALL导致数据清空，直接搜这两条命令即可，它们在 AOF 中是单行明文（*1\r\n$8\r\nFLUSHDB\r\n）
修复前务必确认 AOF 是否已损坏，否则解析器会静默失败
waoffle 遇到协议错误（如缺 \r\n、长度声明与实际不符）会直接退出并报错，但它不修复。真正要动手前，必须先跑：redis-check-aof --check appendonly.aof
输出类似：AOF analyzed: size=2456789 bytes, ok_up_to=2456000 bytes, diff=789 bytes
说明最后 789 字节损坏。此时应：
- 立即备份：
cp appendonly.aof appendonly.aof.bak - 用
--fix截断损坏尾部：redis-check-aof --fix appendonly.aof（注意：该命令会直接改原文件） - 再运行
waoffle—— 否则解析器可能卡死或输出乱码 - 特别注意：如果 AOF 中含
RedisJSON.SET等模块命令，而当前redis-check-aof版本未启用对应模块，它会报Unknown command并终止，此时需先卸载模块或换用兼容版本
真正麻烦的从来不是解析，而是你手头那份 AOF 文件是否还完整——协议层面的损坏，会让所有上层分析归零。
