dir 是启动时只读参数，CONFIG SET 无效；dbfilename 可运行时修改但不持久；二者需配合使用且权限和路径必须正确。
dir 是启动时只读参数，改了 CONFIG SET 也没用
Redis 的 dir 参数控制 RDB 和 AOF 文件的**根目录位置**，但它不是运行时可变配置。执行 CONFIG SET dir /new/path 会直接报错 ERR Unsupported CONFIG parameter: dir——这不是权限或路径问题，是 Redis 内部设计决定的：它在启动阶段加载并锁定该值。
极少数情况下（比如 redis.conf 里压根没写 dir 行），CONFIG SET dir 可能成功，但后果不可靠：
- 旧 RDB/AOF 文件不会自动迁移过去
- 下次重启仍按原始配置加载，新设置丢失
-
CONFIG REWRITE虽能写回 conf，但 systemd 或容器环境常忽略重写后的内容
dbfilename 控制 RDB 文件名，CONFIG SET 有效但不持久
dbfilename 指定的是 RDB 快照文件的**具体文件名**（默认 dump.rdb），它和 dir 拼起来才是完整路径。这个参数支持运行时修改：CONFIG SET dbfilename mydb.rdb 立即生效，下一次 SAVE 或自动触发的 BGSAVE 就会写到 dir 目录下的 mydb.rdb。
但注意：
- 服务重启后，Redis 仍读取 redis.conf 里的原始
dbfilename值 - 如果
dir权限不对（比如用户无写权限），哪怕dbfilename改了，SAVE也会静默失败，日志里只显示Failed to open the temp RDB file - 别指望改完
dbfilename就能绕过dir的权限检查——路径不对，名字再好也没用
验证是否真生效？别只看 CONFIG GET
很多人执行 CONFIG GET dir 和 CONFIG GET dbfilename 都返回新值，就以为改成了。其实这只是内存里的值，不代表磁盘写入成功。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真正验证要三步走：
- 手动拼出完整路径：
CONFIG GET dir+CONFIG GET dbfilename→ 比如/var/lib/redis+mydb.rdb - 执行
SAVE（阻塞式，适合测试）或BGSAVE -
ls -l /var/lib/redis/mydb.rdb看文件是否存在、时间戳是否更新、属主是否为 redis 用户
如果文件没出现，或者出现在旧路径下，说明 dir 配置没改对、权限没设好，或者你编辑的压根不是 Redis 实际加载的那个 redis.conf（systemd 服务常指定 --config /etc/redis/6379.conf，而不是默认路径）。
dir 和 dbfilename 的分工不能颠倒
dir 必须是**绝对路径**，不能是 ./data 或 data；dbfilename 是纯文件名，不含路径。这是硬性约定，颠倒或混用会导致行为异常：
- 把路径写进
dbfilename（比如dbfilename /tmp/dump.rdb）会被忽略，Redis 仍按dir+dbfilename拼接 -
dir如果指向一个不存在的父目录（比如/ssd/redis-data但/ssd分区根本没挂载），Redis 启动会失败，报错Could not create server TCP listening socket或直接退出 - AOF 文件名由
appendfilename控制，它和dbfilename是独立配置项，别误以为改一个就能管两个
最常被忽略的一点：改完 dir 后，必须确保 redis 用户对该目录有 w 和 x 权限。创建目录后只 chown redis:redis 不够，chmod 755 才能让 Redis 进入目录并写文件。否则，一切配置都白搭。
