Redis启动时若appendonly yes且appendonly.aof存在（无论内容是否有效），则强制加载AOF并完全忽略dump.rdb；仅当AOF文件不存在或appendonly no时才加载RDB，该规则主从一视同仁。
appendonly yes 时，Redis 主从节点重启都只认 appendonly.aof，完全忽略 dump.rdb —— 无论主库还是从库，只要 AOF 开启且文件存在，RDB 就不会被加载。
redis-server 启动时的加载逻辑优先级
-
Redis 启动时先读配置项
appendonly：- 如果是
yes，直接尝试加载appendonly.aof - 加载失败（比如文件损坏、格式错误、权限不足），会报错退出，不会 fallback 到 RDB
- 只有当 AOF 文件根本不存在（或
appendonly no），才会去加载dump.rdb
- 如果是
这个规则对主库、从库一视同仁。从库在首次同步前也是普通 Redis 实例，同样走这套加载流程。
即使你手动把一个新鲜的
dump.rdb放进数据目录，只要appendonly yes且appendonly.aof存在（哪怕内容为空或只有几行），Redis 就只加载 AOF。
主从场景下 AOF 文件的来源与风险点
-
从库开启 AOF 后，它的
appendonly.aof是自己写入的，不是从主库复制来的- 主库的写操作通过复制协议发给从库，从库执行后才追加到自己的 AOF 文件
- 所以从库的 AOF 是“本地执行日志”，和主库的 AOF 内容不一致（尤其在网络延迟、重连、部分命令被过滤时）
-
如果从库重启，它用自己那份 AOF 恢复，数据状态 = 上次断连前本地执行完的所有命令
- 这通常没问题，但要注意：如果从库曾执行过
CONFIG SET、DEBUG类命令，或发生过本地写（如slave-read-only no且有人直连写入），这些也会进 AOF，重启后会保留
- 这通常没问题，但要注意：如果从库曾执行过
主库重启也一样：它只按自己的 AOF 恢复，不会参考从库状态
redis-check-aof --fix 什么情况下必须用
当 AOF 文件末尾损坏（比如进程被 kill -9、磁盘满、断电），Redis 启动时报类似错误：
Invalid argument reading the append only file或Bad file format-
此时不能靠删文件硬重启（会丢数据），得先修复：
redis-check-aof --fix appendonly.aof
- 它会扫描文件，找到最后一个完整命令位置，截断后面脏数据 - 修复后务必人工检查日志是否合理（比如最后几条是不是 SET/DEL，有没有混入二进制乱码） 注意：
redis-check-aof不处理 RDB，也不修复网络中断导致的主从不一致，它只救 AOF 文件本身
AOF 开启后，Redis 对恢复路径极其“固执”——它不权衡、不协商、不 fallback。真正容易被忽略的是：主从各自维护独立的 AOF，重启恢复行为互不影响，但数据一致性完全依赖复制链路的健壮性，而不是文件本身。
