通过redis-cli执行config get save和appendonly可快速判断持久化配置：save返回非空表示rdb自动触发已启用，appendonly返回yes表示aof已开启；但最终需结合info persistence及文件系统检查确认实际运行状态。
redis-cli config get save 和 appendonly
直接用 redis-cli 连上 Redis 实例，执行这两条命令就能快速判断是否启用了持久化：
-
redis-cli config get save—— 查 RDB 是否配置了自动触发规则。如果返回类似"900 1 300 10"的字符串，说明 RDB 已启用；返回空数组或nil表示没配任何规则，RDB 不会自动触发 -
redis-cli config get appendonly—— 查 AOF 开关。返回"yes"表示 AOF 已启用；返回"no"或空值，说明 AOF 关闭
注意：save 配置为空 ≠ RDB 完全不可用（手动 SAVE 或 BGSAVE 仍能执行），但自动快照不会发生；appendonly no 就是 AOF 彻底关闭，不会生成 appendonly.aof 文件。
INFO persistence 返回实时持久化状态
INFO persistence 是最接近“当前运行态”的检查方式，它不只看配置，还告诉你最近一次持久化是否成功、时间戳、文件路径等实际状态：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 如果 RDB 正在运行中，会看到
rdb_changes_since_last_save、rdb_last_save_time、rdb_bgsave_in_progress等字段 - AOF 相关字段如
aof_enabled（=1 表示开启）、aof_last_rewrite_time_sec、aof_current_size都是真实写入状态的反映 - 哪怕
config get appendonly返回"yes"，但如果aof_enabled: 0，说明 AOF 因错误被自动关闭过（比如磁盘满、权限不足），此时需查日志
检查 dump.rdb 或 appendonly.aof 文件是否存在
配置开了 ≠ 文件真存在，尤其在刚启动或出错后。两个关键路径要确认：
- RDB 文件：先运行
redis-cli config get dir和config get dbfilename，拼出完整路径（例如/var/lib/redis/dump.rdb），再用ls -l看文件是否存在、大小是否 > 0 - AOF 文件：同样用
config get dir+config get appendfilename拼路径（默认appendonly.aof），注意：AOF 文件可能为空（刚启用未写入）或被重写中断残留临时文件（如appendonly.aof.tmp） - 常见坑：Redis 启动时若指定的
dir不可写，会静默失败——配置显示开启，但根本没生成文件，INFO persistence中对应字段也会异常
Docker 或 systemd 环境下容易漏掉的点
容器或服务管理器常掩盖底层配置细节：
- Docker 启动时用
-v挂载了宿主机目录到/data，但 Redis 配置里dir写的是/var/lib/redis—— 实际文件根本没落进挂载点，ls查不到 - systemd 启动的 Redis 可能加载的是
/etc/redis/redis.conf，但你改的是/usr/local/etc/redis.conf；或者redis-server /path/to/conf显式指定了配置文件，而config get返回的是运行时生效值，不是你本地编辑的文件 - 某些云托管 Redis（如阿里云 Tair、腾讯云 CRS）禁用
CONFIG命令，config get会报错，只能靠INFO persistence+ 控制台配置页交叉验证
真正要确认“此刻有没有持久化”，不能只信配置项，得把 config get、INFO persistence、文件系统检查三者对齐——尤其是 rdb_last_bgsave_status:ok 和 aof_last_bgrewrite_status:ok 这两个字段，它们才是持久化真正跑通的铁证。
