不能靠 rename-command 隐藏 publish 防止未授权读取，因它仅改名不改权限模型，订阅者仍可接收所有消息，且攻击者知悉新命令名即可发布；真正有效的是启用密码认证、禁用或重命名高危命令、绑定内网地址三者缺一不可。
不能靠 rename-command 隐藏 PUBLISH 来防止未授权读取——它只影响命令名，不改变权限模型，订阅者仍能收到所有已发布的消息，且攻击者只要知道新命令名就能照常发消息。
rename-command PUBLISH 只是改名，不是加锁
把 PUBLISH 改成 safe_publish 后，Redis 不会自动拒绝未知客户端调用该命令；只要连接成功、认证通过（或没设密码），任何客户端都能执行 safe_publish。订阅端更不受影响：SUBSCRIBE 和 PSUBSCRIBE 完全不受 rename 影响，频道内容对所有订阅者透明。
- rename 是纯字符串映射，Redis 内部仍按原逻辑处理发布行为
- 没有 ACL 或用户粒度控制时，rename 对安全提升为零
- 若业务中存在多个服务共用一个 Redis 实例，仅靠改名无法区分“谁该发”和“谁不该发”
真正能阻止未授权发布的只有三件事
必须在 redis.conf 中同时落实以下配置，缺一不可：
- 启用密码认证：
requirepass your_strong_password，且应用层绝不硬编码密码到前端或日志中 - 禁用或重命名高危命令：
rename-command PUBLISH ""（彻底禁用）或rename-command PUBLISH "safe_publish"（仅当业务强依赖时） - 绑定内网地址：
bind 127.0.0.1 192.168.10.0/24，严禁bind 0.0.0.0；配合防火墙封掉非必要端口
注意：protected-mode yes 在 Redis 7.x 默认开启，但它只防“无密码 + bind 0.0.0.0”这种裸奔组合，不能替代上述三项。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
订阅端无法被“隐藏”，但可做内容防护
你没法让某个频道只对特定客户端可见——Redis 的 PUB/SUB 没有频道级访问控制。能做的只有事后过滤：
- 消费者收到消息后，先校验 JSON 结构是否合法，拒绝字段过多、嵌套过深或含
eval/system(等敏感字符串的消息 - 限制单条消息长度，例如截断超过 1MB 的 payload，避免内存耗尽
- 剥离非业务字段，比如自动删除所有以
_meta_开头的键，防止注入元数据
别指望 Lua 脚本在 SUBSCRIBE 侧做拦截——Redis 不允许在订阅上下文中执行 EVAL，那根本走不通。
ACL 用户才是现代 Redis 的正确防线
如果你用的是 Redis 6.0+（尤其是 7.x），应该放弃 rename 这种补丁式做法，直接用 ACL：
- 创建专用发布用户：
ACL SETUSER pubuser on >mypass ~channel:order* +publish - 创建只读订阅用户：
ACL SETUSER subuser on >mypass ~channel:order* +subscribe +psubscribe - 重启后，普通连接即使知道密码也无法执行
PUBLISH，除非显式切换用户
rename 是给老版本兜底的权宜之计；ACL 才是可控、可审计、可复用的正解。别在 2026 年还拿 rename-command 当主力防护手段。
