优先加载 appendonly.aof 文件；只要该文件存在（即使为空或损坏），redis 启动时就不会读取 dump.rdb，且因严格解析导致损坏即启动失败。
Redis启动时同时存在RDB和AOF文件，优先加载哪个？
优先加载 appendonly.aof 文件，无论其内容是否完整、是否可读。只要 appendonly.aof 文件存在（哪怕为空或损坏），Redis 启动时就不会读取 dump.rdb。
为什么AOF文件存在但损坏会导致启动失败？
因为 Redis 在加载 AOF 时是「严格解析」的：逐行读取命令、校验格式、执行重放。一旦遇到非法指令、CRC校验失败、截断或手动篡改过的行，就会报错退出，例如：
Invalid argument during startup: Invalid AOF header
此时即使 dump.rdb 完好且最新，也不会被尝试加载。
常见诱因包括：
- 手动编辑过
appendonly.aof（生产环境严禁） - 服务器异常断电导致 AOF 写入不完整
- 使用
redis-check-aof --fix修复失败后残留脏数据 - 混合持久化开启时，AOF 文件头含 RDB 片段但校验失败
如何安全地从RDB恢复，跳过AOF加载？
必须确保启动前 appendonly.aof 文件不存在或被临时移走。具体操作顺序不能颠倒：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 停掉 Redis 进程：
redis-cli shutdown - 重命名或移走 AOF 文件：
mv appendonly.aof appendonly.aof.bak - 确认配置中
appendonly no（防止启动时自动生成新 AOF） - 启动 Redis，此时会自动加载
dump.rdb - 确认数据正确后，再通过
config set appendonly yes动态开启 AOF - 等待 BGREWRITEAOF 自动触发或手动执行，生成新的干净 AOF 文件
注意：如果配置里写了 appendonly yes 但文件缺失，Redis 会创建空 appendonly.aof 并加载——这等于用空日志覆盖了 RDB 数据，必须提前关掉配置项。
混合持久化（aof-use-rdb-preamble yes）下恢复逻辑有变化吗？
没有本质变化。混合模式只是让 appendonly.aof 文件开头嵌入一段 RDB 格式数据，后面接常规 AOF 命令。但整个文件仍被视为一个 AOF 文件，加载流程不变：先解析头部 RDB 片段，再逐条执行后续命令。一旦头部 RDB 校验失败，或后续命令出错，同样直接 abort。
这意味着：混合持久化提升了 AOF 重写效率和启动速度，但没改变「AOF 存在即优先」这个底层规则，也没给 RDB 提供 fallback 通道。
真正容易被忽略的是：AOF 文件的存在本身就是一个开关，它不依赖内容是否有效，只依赖文件路径是否存在且可读。这点在故障排查时常常被低估。
