CONFIG REWRITE 仅持久化已通过 CONFIG SET 成功设置的可持久化参数，maxmemory-policy 属于此列；但若启动未加载对应配置文件、配置被命令行参数覆盖、或策略因兼容性校验失败未真正生效，则 CONFIG REWRITE 后仍不生效。
CONFIG REWRITE 不能直接写入淘汰策略，它只保存运行时通过 CONFIG SET 修改且被 Redis 认为“可持久化”的参数。 淘汰策略（maxmemory-policy）属于可持久化参数，但必须先用 CONFIG SET 正确设置，再执行 CONFIG REWRITE 才会落盘；否则即使配置文件里原本有，运行时改过又被覆盖，CONFIG REWRITE 也不会恢复旧值。
为什么 CONFIG REWRITE 后 maxmemory-policy 没生效
常见错误是：配置文件里写了 maxmemory-policy allkeys-lru，但启动后用 CONFIG GET maxmemory-policy 查到却是 noeviction。这不是 CONFIG REWRITE 的问题，而是启动时根本没加载那份配置文件——Redis 默认不读 /etc/redis/redis.conf，除非你显式指定路径启动。
- 第一步永远是确认实际加载的配置路径：
ps -ef | grep redis-server，看命令行尾部带的是哪个.conf - 第二步检查该配置文件里是否真有
maxmemory-policy行，且未被注释或拼错（比如写成maxmemory_policy或max-memory-policy） - 第三步注意优先级：命令行参数 > 配置文件 >
CONFIG SET；如果启动时加了--maxmemory-policy volatile-lru，那配置文件里的设置就完全被忽略
CONFIG SET + CONFIG REWRITE 的正确操作顺序
线上临时调整淘汰策略后想固化，不能只靠 CONFIG REWRITE。必须按顺序执行：
- 先用
CONFIG SET maxmemory-policy allkeys-lfu立即生效（验证是否接受该值） - 再用
CONFIG SET maxmemory 2gb（如果还没设maxmemory，maxmemory-policy无效） - 最后执行
CONFIG REWRITE—— 它只会把上述两个已生效的设置写回当前加载的配置文件 - 注意：
CONFIG REWRITE不会补全缺失的参数，也不会保留注释或格式；它只覆盖已存在参数的值，或追加新参数到文件末尾
容易被忽略的兼容性细节
Redis 7.0 对淘汰策略的校验更严格，部分组合在运行时会被拒绝，导致 CONFIG SET 失败，进而 CONFIG REWRITE 什么也写不了：
-
volatile-*类策略（如volatile-lru）要求至少有一个 key 带过期时间，否则写入会报错，但CONFIG SET本身不校验这点，只有首次触发淘汰时才暴露 -
allkeys-lfu在小内存实例（maxmemory - 如果你用
CONFIG REWRITE后发现文件里多出两行maxmemory-policy，说明之前配置文件里已有该参数但格式异常（比如前后有空格、大小写混用），Redis 会把它当新参数重写一次
真正关键的不是“怎么写回去”，而是“哪份文件被读、哪些值被认可、哪些组合实际可用”。CONFIG REWRITE 只是最后一环，前面每一步出错，它都救不回来。
