redis pub/sub 跨语言通信需统一utf-8编码、json序列化、小写频道命名，并手动重建订阅；它无持久化与ack，仅适用于实时性高、允许丢失的场景。
Redis Pub/Sub 本身不跨语言，但协议是通用的
Redis 的发布订阅功能没有语言绑定，所有客户端库都基于相同的 RESP 协议实现 PUBLISH、SUBSCRIBE、UNSUBSCRIBE 和 PSUBSCRIBE 命令。这意味着 Python 的 redis-py、Go 的 github.com/go-redis/redis、Java 的 lettuce，只要遵循协议，就能互相收发消息——前提是双方约定好序列化格式和频道命名规则。
常见错误现象：Python 发送 JSON 字符串，Java 客户端直接用 StringRedisTemplate 接收却没做 new String(bytes) 解码，或反向出现乱码；更隐蔽的是 Go 客户端默认用 []byte 接收，而 Java 默认尝试 UTF-8 解码失败后静默丢弃。
- 所有客户端必须统一使用 UTF-8 编码传输 payload，避免平台默认编码干扰
- 频道名（channel）建议全小写 + 下划线，如
order.created，避免大小写敏感导致订阅失效 - 不要依赖客户端自动重连机制处理订阅断连——
SUBSCRIBE是阻塞命令，连接中断后需手动重建连接并重新SUBSCRIBE
用 JSON 作为跨语言序列化格式最稳妥
二进制协议（如 Protobuf）虽高效，但要求所有服务端提前共享 schema 并生成代码，实践中容易因版本不一致导致解析失败。JSON 是唯一被所有主流语言原生支持、无需额外依赖、可读性高、容错性强的格式。
使用场景：微服务间传递事件（如用户注册、库存扣减），前端通过 WebSocket 桥接 Redis 消息时也依赖 JSON 可直接转 JS 对象。
- 发送前始终调用
json.dumps(obj, ensure_ascii=False)（Python）、new ObjectMapper().writeValueAsString(obj)（Java）、json.Marshal()（Go），确保不转义中文 - 接收端必须捕获解析异常（如
JSONDecodeError、JsonProcessingException），不能假设消息一定合法 - 避免在 JSON 中嵌套二进制数据（如图片 base64），应改为传递 URL 或独立存储 key
客户端必须显式管理订阅生命周期，不能靠“自动恢复”
Redis 服务器不会保存客户端订阅状态，连接断开即丢失所有 SUBSCRIBE。很多客户端库文档里写的 “auto-reconnect” 只负责重建 TCP 连接，**不自动重订频道**——这是跨语言通信中最常被忽略的坑。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
错误现象：Java 服务运行 2 小时后网络抖动，连接恢复但不再收到 payment.confirmed 消息，日志里也没有报错，排查半天才发现订阅没重建。
- Go 客户端（
go-redis）需在PubSub.Listen()返回 error 后，显式调用ps.Subscribe(channel)重订 - Python 的
redis-py使用pubsub.listen()迭代器时，一旦抛出ConnectionError，必须新建pubsub实例并重新subscribe() - Java 的
Lettuce需监听ConnectionEvents.CONNECTED，再触发StatefulRedisPubSubConnection.sync().subscribe(...)
别把 Redis Pub/Sub 当作消息队列用
它没有持久化、没有 ACK、不保证顺序、不支持消费者组——这些限制在跨语言场景下会被放大。例如 Go 服务快速发布 10 条消息，Python 订阅者因 GC 暂停错过中间 3 条，Redis 不会重发。
性能影响：单个 Redis 实例 pub/sub 吞吐量可达 10w+ QPS，但所有订阅者共享同一份内存广播，客户端越多，CPU 和带宽压力越大。
- 仅用于实时性要求高、允许少量丢失的场景（如聊天室在线状态、监控告警推送）
- 需要可靠投递时，必须上层加补偿逻辑（如落库 + 定时扫描未确认事件）或换用 Kafka/RocketMQ
- 避免在频道名中拼接动态 ID（如
user:12345:notify），会导致订阅者爆炸式增长，改用通配符PSUBSCRIBE user:*:notify并在消费端过滤
跨语言 Pub/Sub 真正难的不是连上 Redis，而是让不同团队写的客户端在断网、乱码、解包失败、频道漏订这些边界条件下表现一致——这得靠明确的接入规范文档，而不是指望某个“通用客户端库”。
