redis从节点默认启用只读保护，由slave-read-only（或replica-read-only）配置控制，运行时通过info replication查看role=slave且slave_read_only=1确认，客户端写命令会报错“readonly you can't write against a read only slave”。
可以，但必须明确：Redis从节点的写入控制只靠 slave-read-only（或新版 replica-read-only）配置项，且它只对客户端写命令生效，不防内部操作或管理命令。
这个配置不是“可选功能”，而是默认开启的安全基线——自 Redis 2.6 起，所有从节点默认就是 slave-read-only yes，一旦启用主从复制，客户端执行 SET、DEL 等写命令就会直接报错：(error) READONLY You can't write against a read only slave.
怎么确认从节点已启用只读保护
别只看配置文件，运行时状态才作数：
- 检查配置文件中是否设置了
slave-read-only yes（Redis replica-read-only yes（Redis ≥ 5.0），注意旧版参数名在新版本中仍兼容，但推荐统一用新名 - 连接从节点后执行
CONFIG GET slave-read-only或CONFIG GET replica-read-only，返回值必须是"yes" - 执行
INFO replication，确认role:slave且master_host非空；若显示role:master，说明已脱离复制拓扑，该配置失效
为什么改了配置还是能写？常见误判点
报错消失 ≠ 写入被允许，很多“能写”其实是绕过了只读限制：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
slave-read-only no是危险操作，仅用于极少数临时调试场景，重启后失效（除非写入配置文件并重载） -
CONFIG SET slave-read-only no可动态关闭，但不持久化，服务重启即恢复默认yes -
SLAVEOF NO ONE会让从节点升为主节点，角色变更后slave-read-only不再起作用——此时它已是主，自然可写 -
CONFIG、DEBUG、MODULE等管理命令默认仍可用，哪怕只读模式下也能执行CONFIG SET修改自身配置，必须配合rename-command或 ACL 禁用
Redis Cluster 中从节点的只读行为不一样
Cluster 模式下没有传统 slave-read-only 这个配置项，它的只读是硬编码逻辑：
- Cluster 的从节点（replica）默认拒绝所有客户端写命令，无论配置如何，
slave-read-only参数在 Cluster 中完全无效 - 只读由
CLUSTER REPLICATE <node-id></node-id>建立关系后自动触发，无法通过 config 命令关闭 - 想让 Cluster 从节点接受写入？不行。唯一合法方式是执行
CLUSTER FAILOVER触发故障转移，让它变成 master —— 但这属于拓扑变更，不是“解除只读”
真正要防住写入，光靠 slave-read-only 不够
它只拦普通客户端命令，不拦三类风险：
- ACL 用户权限未收敛：即使只读模式，若用户有
+@all权限，仍可执行CONFIG SET关闭只读 - 未禁用危险命令：
CONFIG、DEBUG、MODULE等默认开放，应通过rename-command CONFIG ""或 ACL 显式屏蔽 - 运维误操作：比如用
redis-cli -h slave-host -p 6379直连后执行SLAVEOF NO ONE，瞬间打破只读边界
线上环境必须把 slave-read-only yes 写死在配置文件里，配合 ACL 锁死管理命令，并监控 INFO replication 中的 role 和 slave_read_only 字段变化。任何“从节点变可写”，基本都源于角色切换或权限失控，而不是只读开关本身失灵。
