必须用redis-cli config get appendonly确认返回"yes"，否则可能因命令行参数覆盖、配置文件路径错误、动态修改未持久化等原因导致未生效；还需验证appendonly.aof文件存在、可读且非空。
确认 appendonly 配置已在运行时生效
很多人改了 redis.conf 里的 appendonly yes 就以为万事大吉，但 Redis 启动时只认实际生效的配置，不认文件里写了什么。必须用 redis-cli config get appendonly 确认返回值是 "yes"。如果返回 "no"，常见原因包括：
- 启动时用了
--appendonly no命令行参数，它会覆盖配置文件 - 配置文件路径传错，Redis 实际加载的是另一份未修改的
redis.conf - 配置被
CONFIG SET动态改过，但没持久化到文件，重启后失效
确保 appendonly.aof 文件真实存在且可读
Redis 不校验 AOF 内容合法性，只做存在性检查：文件在 dir + appendfilename 拼出的路径下、大小 > 0、权限允许 redis 用户读取。执行以下三步验证：
-
redis-cli config get dir和config get appendfilename，拼出完整路径（例如/var/lib/redis/appendonly.aof） -
ls -l /var/lib/redis/appendonly.aof，确认文件存在、大小非零、属主为 redis 用户 -
sudo -u redis cat /var/lib/redis/appendonly.aof | head -n 1，测试能否以 redis 身份读取
哪怕文件内容损坏（比如开头不是有效命令），只要能打开，Redis 就会尝试加载并报具体错误；而文件缺失或不可读，它会直接跳过 AOF，转去加载 RDB。
避免混合持久化导致的隐式降级
启用 aof-use-rdb-preamble yes 后，Redis 生成的 AOF 文件头部是 RDB 格式数据，后面才是文本命令。但如果重写失败、磁盘满或进程被杀，可能留下一个只有 RDB preamble 但无后续命令的截断文件。此时 Redis 加载会失败并 abort，**不会 fallback 到 RDB**——它卡在 AOF 加载阶段直接退出。排查方法：
- 用
head -c 100 /var/lib/redis/appendonly.aof | hexdump -C查看开头是否为REDIS0011（RDB 魔数） - 若开头是
REDIS但文件总大小异常小（如仅 128 字节），大概率是截断的 preamble，需用redis-check-aof --fix修复或手动移除后触发重写 - 临时禁用混合模式：
CONFIG SET aof-use-rdb-preamble no，再BGREWRITEAOF生成纯文本 AOF，排除 preamble 干扰
启动日志里没出现 Reading AOF from file 怎么办
这是最直接的判断依据。如果启动输出中只有 DB loaded from disk after xxx seconds 却没有 AOF 相关日志，说明 Redis 根本没走 AOF 路径。此时不要猜，立刻检查：
- 是否在
redis.conf中误加了save ""但漏掉appendonly yes？save ""只禁用 RDB 触发，不影响 AOF 优先级 - 是否把
appendonly.aof放到了错误目录？比如dir是/var/lib/redis，但文件实际在/var/lib/redis/6379/下 - 是否启用了 systemd 服务，而
ExecStart里硬编码了--appendonly no？这种覆盖优先级最高
真正起作用的永远是启动那一刻生效的配置和那个实实在在存在的文件——而不是你“以为”它该有的状态。
