优先用 redis-check-aof --fix 自动修复尾部无效数据，若失败则需结合 rdb 回滚或从节点同步；切勿手动编辑或截断，避免破坏 resp 协议完整性。
Redis AOF 文件尾部乱码导致启动失败怎么办
Redis 启动报错 Bad file format reading the append only file 或卡在 loading AOF 阶段，大概率是 AOF 文件末尾被截断或混入非 Redis 协议字节（比如日志追加错误、磁盘满后强制写入、SIGKILL 中断 rewrite）。AOF 不是普通文本，不能用 vim 或 sed 直接删行——协议是二进制前缀（如 *3\r\n$3\r\nSET\r\n$1\r\nk\r\n$1\r\nv\r\n），删错一个 \r\n 就全崩。
- 别用
truncate -s -100 aof_file.aof猜长度，AOF 的有效结尾必须落在完整命令边界上 - 优先用 Redis 自带的
redis-check-aof修复，它会扫描到最后一个合法命令位置并截断后续 - 执行前务必备份：
cp appendonly.aof appendonly.aof.bak - 运行
redis-check-aof --fix appendonly.aof，它会输出类似Successfully truncated AOF to 12345678 bytes - 如果提示
Invalid argument，说明文件开头已损坏（不止是尾部），这时不能硬修，得靠 RDB 回滚或从节点同步
为什么 redis-check-aof --fix 有时不生效
它只处理“尾部无效”，不修复中间损坏。常见失效场景：
- AOF 在 rewrite 过程中被 kill，导致头部有
REDIS0011魔数但后面跟了半截命令——redis-check-aof会直接报错退出，不尝试修复 - 文件被人为插入调试日志（如
echo "DEBUG" >> appendonly.aof），且插在两个命令之间，工具无法判断哪部分该留哪部分该删 - 使用了
aof-use-rdb-preamble yes，但 RDB 段末尾和 AOF 段开头衔接异常，此时必须用redis-check-rdb先验 RDB 段 - Redis 版本低于 4.0，
--fix选项不存在，只能手动定位最后一个\r\n前的完整命令（极不推荐）
手动定位最后一个合法命令的实操底线
仅当 redis-check-aof --fix 明确报出偏移量但拒绝操作时才考虑，风险极高：
- 用
hexdump -C appendonly.aof | tail -n 50查看末尾十六进制，找最近的0d 0a（即\r\n）序列 - 往前推，确认前面是否构成完整 RESP 格式：以
*开头的数组长度行，后跟若干$开头的字符串行，每行以\r\n结束 - 用
dd if=appendonly.aof of=fixed.aof bs=1 count=XXXXX截取到该位置（XXXXX 是十进制偏移量） - 启动前务必用
redis-server --test-memory 1验证内存安全，再用redis-server --appendonly yes --appendfilename fixed.aof试启
修复后仍加载缓慢或内存暴涨的隐性原因
表面修好了，但可能埋了更麻烦的坑：
- 被截断的命令可能是大 key 的
LPUSH或HSET，修复后只剩一半数据，应用层逻辑错乱（比如订单状态丢失） - AOF 中存在大量过期键的
PEXPIREAT，截断点恰在过期指令之后，导致这些键永久驻留内存 - 如果开启了
aof-rewrite-incremental-fsync yes，而 rewrite 进程崩溃，残留的临时文件可能被误认为主 AOF - 修复后的 AOF 文件时间戳早于 RDB，Redis 重启时若配置了
appendonly yes且save ""，可能跳过 RDB 加载，只加载损坏过的 AOF
