Redis启动的时候，明明配置文件里设了`appendonly yes`，重启后却仅加载了RDB、没理会AOF——这种情况很多开发者都遇到过。其实原因非常直接：Redis并非“选择性忽略”AOF，而是严格依据文件存在性来做判断。只要`appendonly.aof`文件在`dir`指定的路径下存在且可读，它就强制走AOF加载流程；反过来，哪怕配置中写了`appendonly yes`，只要那个文件不存在，Redis就老老实实退回RDB加载逻辑，完全不检验内容是否有效。

### Redis启动时跳过AOF加载的直接原因 简单说：不是Redis“故意忽略”，而是它只检查文件存在与否。`appendonly.aof`在`dir`配置目录下存在且可读，就强制走AOF加载；反之，即使配置文件里写了`appendonly yes`，只要该文件缺失，Redis就自动切换到RDB加载逻辑。这一判断非常机械，不存在“智能回退”机制。 ### 为什么`appendonly yes`但没加载AOF？ 常见的情况其实就那么几种： - `appendonly.aof`被手动删除或重命名，但`redis.conf`里依然保留着`appendonly yes`。 - Redis上次通过`shutdown`正常关闭，但配置中的`appendonly yes`实际上并未生效——比如配置文件未被重载，或者启动命令行用`--appendonly no`参数覆盖了设置。 - 启用了混合持久化（`aof-use-rdb-preamble yes`），但新AOF文件尚未生成，而旧AOF因损坏被自动清空，导致目录下根本没有有效的AOF文件。 - 权限问题：`redis`用户对`appendonly.aof`所在目录缺少读权限，文件明明存在却无法打开——这在容器或系统迁移后尤其常见。 ### 如何快速确认AOF是否本应被加载？ 想知道是否该走AOF但没走，按下面顺序排查，缺一不可： 1. 运行`redis-cli config get appendonly`，确认返回值是`"yes"`——别只看配置文件，因为运行时配置可能被覆盖。 2. 运行`redis-cli config get dir`和`config get appendfilename`，拼出完整路径，然后用`ls -l`确认`appendonly.aof`存在且大小大于0。 3. 查看启动日志：在`redis-server /path/to/redis.conf`的输出中，搜索`Starting Redis server`之后有没有出现`Reading AOF from file`或`Failed to open the AOF file`。 4. 如果日志里有`Invalid argument during startup: Invalid AOF header`，说明文件存在但内容损坏，Redis已经中止加载并静默跳过——这种情况下不会自动回退到RDB，你需要先手动移走或修复那个文件才能恢复正常加载。 ### 最容易被忽略的细节：AOF文件存在即生效，不校验内容有效性 Redis在启动早期只检查`appendonly.aof`是否存在、是否可读，**根本不验证内容是否合法**。这意味着： - 一个空文件、零字节的`appendonly.aof`，也会触发AOF加载流程，然后因为加载失败直接退出。 - 手动`touch appendonly.aof`后启动Redis，等同于开启AOF但无数据——结果是加载了一个空状态，直接覆盖掉RDB里的全部数据。 - 混合持久化下，即使RDB preamble校验失败，整个AOF加载也会中止，不会尝试解析后面的有效命令。它把整个文件当做一个原子单元处理，要么全部加载，要么全部放弃。 所以排查的时候别只盯着配置项，先盯住那个文件在不在、有没有被其他进程锁住、是不是被截断过。很多时候，问题就出在文件状态上，跟配置一点关系都没有。