slave-read-only yes（Redis 5.0+ 为 replica-read-only yes）是 Redis 从库写入保护的默认核心开关，配置为 yes 时协议层拦截所有客户端写命令并返回 READONLY 错误；需通过 CONFIG GET/SET 检查并同步更新配置文件以确保持久生效。
slave-read-only yes 是 Redis 从库写入保护的默认且核心开关
Redis 从库默认开启只读模式，slave-read-only yes 是生效前提。如果从库意外接受写命令（如 SET、DEL），大概率是该配置被显式设为 no，或运行时被动态修改过。它不依赖用户权限系统，而是直接在协议层拦截写操作——只要配置为 yes，所有客户端（包括本地 redis-cli）执行写命令都会收到 READONLY You can't write against a read only slave. 错误。
如何确认和修复从库的只读状态
别只看配置文件，运行时状态才真实有效。需同时检查静态配置与当前生效值：
- 检查配置文件中是否含
slave-read-only yes（注意：Redis 5.0+ 已改名replica-read-only yes，但旧配置仍被兼容） - 连接从库后执行
CONFIG GET slave-read-only或CONFIG GET replica-read-only，确认返回值为["slave-read-only","yes"] - 若返回
"no"，立即执行CONFIG SET replica-read-only yes（Redis 5.0+ 推荐用新参数名） - 注意：该设置仅对当前进程有效，重启后会恢复配置文件中的值，务必同步更新配置文件
为什么有些写操作看起来“成功”了？常见例外场景
slave-read-only yes 拦截的是客户端发来的写命令，但以下情况不会报错，容易误判为“写入生效”：
-
INFO replication或ROLE返回slave状态，不代表从库正在接收写请求，只是说明其复制角色 - 从库执行
CONFIG SET修改自身配置（如maxmemory）是允许的，这属于管理命令，不违反只读原则 - 主库故障后手动执行
SLAVEOF NO ONE升级为新主库，此时只读自动关闭，但这是主动运维行为，不是保护失效 - 使用
redis-cli -a连接时若密码错误，部分旧版本可能降级为无认证连接并绕过某些限制（极少见，但建议始终校验 AUTH 状态）
集群模式下该配置是否还起作用？
不起作用。Redis Cluster 中没有传统意义的“从库”概念，每个节点都是独立的 master 或 slave 角色，但 slave-read-only 配置仅适用于主从复制（SLAVEOF / REPLICAOF）场景。Cluster 节点的只读由 CLUSTER REPLICATE <node-id></node-id> 控制，且从节点默认拒绝客户端写入——这个行为是硬编码逻辑，不依赖 slave-read-only 配置项。因此，在 Cluster 环境中修改该参数无效，也不应依赖它做安全控制。
真正关键的是：确保主从拓扑中每个从库的 replica-read-only（或旧版 slave-read-only）在配置文件和运行时均为 yes，并且理解它只管“客户端写入”，不管内部复制流或管理命令。任何绕过它的尝试，基本都源于混淆了角色、版本或部署模式。
