可用文本工具直接查看AOF文件，但需注意其为RESP协议编码的纯文本，推荐用vim/less/VS Code打开；常见命令如SET key1 value对应$3\r\nSET\r\n$4\r\nkey1\r\n$5\r\nvalue格式。
怎么用文本工具直接看AOF文件里的命令
AOF 文件本质就是 Redis 执行过的写命令的纯文本记录，所以不用启动 Redis 就能打开看——但得注意编码和换行格式。默认是 UTF-8，Windows 记事本可能乱码，推荐用 less、vim 或 VS Code（禁用自动格式化）。
常见错误现象：cat appendonly.aof | head -n 20 看到一堆 *3\r\n$3\r\nSET\r\n$4\r\nkey1\r\n$5\r\nvalue 这种格式，不是“看不懂”，而是没意识到这是 RESP 协议的原始编码，不是故意加密。
-
\r\n是分隔符，每条命令由若干行组成：开头*N表示后面有 N 行参数，每行以$M开头表示接下来 M 字节是内容 - 真正可读的命令藏在奇数行里，比如
$3\r\nSET后面跟着$4\r\nkey1和$5\r\nvalue，合起来就是SET key1 value - 如果 AOF 开启了
appendfsync everysec，文件末尾可能有不完整命令（只写了一半就断电），这时redis-check-aof --fix才能安全截断，别手动删
如何快速定位非法写入（比如意外的 FLUSHALL 或大量 KEYS）
非法写入往往有特征：高频、非业务键名、危险命令。直接 grep 最有效，但要注意 RESP 编码会把命令拆成多行，所以得匹配完整结构或用正则跨行扫描。
使用场景：线上突然发现缓存全空，怀疑被 FLUSHALL 或 FLUSHDB 清掉；或者监控发现某类键爆炸式增长，想回溯是谁写的。
- 查危险命令：
grep -a -o -P '(\$[0-9]+\r\n){1,}FLUSH(ALL|DB)' appendonly.aof（-a强制当文本处理二进制残留，-P支持 Perl 正则） - 查可疑键名：
grep -a '\$[0-9]\+\r\n\$[0-9]\+\r\n.*\.[a-z]\{2,3\}' appendonly.aof可抓到类似user.123或tmp_xyz这种非标准命名 - 避免漏匹配：
KEYS *在 AOF 里是*2\r\n$4\r\nKEYS\r\n$1\r\n*，不能只搜KEYS，否则会混进GETKEYS这类正常命令
为什么 redis-check-aof 比人眼扫更可靠
人眼扫 AOF 容易误判，因为 Redis 在 rewrite 时会压缩命令（比如把多次 INCR 合成一个 SET），还会过滤过期键、跳过已删除键的写入。直接看原始 AOF，看到的不一定是最终生效的操作。
性能 / 兼容性影响：运行 redis-check-aof --fix appendonly.aof 不会加载数据到内存，只做语法校验和截断，耗时取决于文件大小（GB 级通常几秒内），但会生成临时修复文件，磁盘空间要留够。
- 它能识别出「不合法 RESP 结构」，比如
*2\r\n$3\r\nGET后面少了一行值，这种人工很难发现 - 对
EXPIRE/PEXPIRE类命令，它会检查时间戳是否合理（比如负数或远超当前时间），而文本搜索完全无法判断 - 如果 AOF 里混入了 Lua 脚本（
EVAL），redis-check-aof会尝试解析脚本体，但不会执行，比正则安全得多
哪些情况不能只靠看 AOF 日志排查
AOF 只记录「写命令到达 Redis 服务端之后」的内容，前面的链路问题它不管。很多你以为是 Redis 写错了，其实根本没到它那儿。
容易踩的坑：发现 AOF 里没有某条该有的写入，就断定代码没调用 Redis，但更可能是客户端连接失败、超时、序列化异常，或者用了 pipeline 但没 sync() 就退出了。
- 客户端未 flush：Java Jedis 的
pipeline.sync()、Python redis-py 的pipe.execute()忘调，命令压根没发出去，AOF 当然为空 - 网络中间件拦截：某些代理（如 Twemproxy）不支持
SCRIPT LOAD或CLIENT SETNAME，会静默丢弃，AOF 里自然找不到 - Redis 配置限制：如果
rename-command FLUSHALL ""，那任何客户端发来的FLUSHALL都会被服务端拒绝，也不会记入 AOF
真要闭环排查，得配合客户端日志、TCP 抓包（如 tcpdump -i lo port 6379 -w redis.pcap）、以及 Redis 的 slowlog 和 monitor（仅调试用，别开在生产）。
