RDB未真正关闭——即使配置save ""，只要dump.rdb文件存在，Redis在FLUSHALL、全量同步或shutdown时仍会重写它；必须删除文件+关闭混合持久化+验证状态三步闭环。
不能只改 save "" 就认为RDB已关闭——只要 dump.rdb 文件还躺在 dir 目录里，Redis 在 FLUSHALL、主从全量同步或 shutdown 时仍会重写它。
为什么改了 save "" 还会生成 dump.rdb
常见误解是注释掉所有 save 行或写上 save "" 就万事大吉。但 Redis 的行为逻辑是：只要当前工作目录下存在有效的 dump.rdb（且 dir 和 dbfilename 配置可访问），它就会在以下场景中自动重写该文件：
-
FLUSHALL命令执行时（无论是否启用自动快照） - 主节点触发全量同步（
SYNC或PSYNC2）给新从节点 -
redis-cli shutdown（默认行为是save，即同步落盘）
这不是 bug，是 Redis 的设计契约：它把现有 dump.rdb 当作“合法快照模板”，哪怕你禁用了所有自动触发条件。
必须同步清理残留文件 + 验证运行时状态
生产环境关 RDB 是个三步闭环动作，缺一不可：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在
redis.conf中明确写入save ""（不推荐仅注释，避免配置被覆盖或误启） - 确认
appendonly no且rdb-aof-use-rdb-preamble no（混合持久化也得关） - 在停机窗口内执行：
redis-cli shutdown nosave→ 手动删除dump.rdb及可能的dump.rdb.tmp→ 启动 Redis → 再次验证INFO persistence | grep rdb_中rdb_bgsave_in_progress:0且rdb_last_save_time不再更新
执行完 CONFIG SET save "" 后，务必用 redis-cli config get save 确认返回是 1) "save" 2) ""；否则说明命令未生效或配置未加载。
验证是否真关掉了：别信时间戳，要看文件和状态
只看 dump.rdb 文件修改时间或 rdb_last_save_time 差值，容易误判。真正可靠的验证方式是：
- 检查
ls -lh $(redis-cli config get dir | tail -n1)/$(redis-cli config get dbfilename | tail -n1)—— 文件应不存在，或大小为 0 - 运行
redis-check-rdb校验（如果文件意外存在）：输出必须是Checksum OK才算有效，否则是残缺快照 - 持续观察
INFO persistence：确保rdb_last_bgsave_status:ok不再出现，且rdb_last_save_time停止递增
最容易被忽略的是：即使 CONFIG GET save 返回空、appendonly 关闭、进程重启过，只要磁盘上那个 dump.rdb 没被删，下次 FLUSHALL 就会悄无声息地把它“复活”。
