跨语言使用 Redis Pub/Sub 可行但需手动对齐编码、序列化等细节；Python 消息 Java 收不到主因是 payload 解码失败或频道名不匹配；JSON 序列化是唯一靠谱方案；连接断开后需手动重订阅并加延时；频道命名应统一小写加下划线，慎用通配符。
跨语言使用 Redis Pub/Sub 是可行的，但必须手动对齐编码、序列化、频道命名和重订阅逻辑——Redis 本身不提供跨语言适配层，所有“兼容”都靠开发者约定。
为什么 Python 发的消息 Java 收不到？
常见错误不是连接失败，而是 payload 解码失败或频道名不匹配。Redis 只管转发原始字节流，不做任何转换。
-
SUBSCRIBE和PUBLISH传输的是 raw bytes，客户端库默认行为差异极大：Python 的redis-py默认 decode 响应为 str（UTF-8），Go 的go-redis默认返回[]byte，Java 的Lettuce在StringRedisTemplate中尝试 UTF-8 解码，失败则静默丢弃 - 中文乱码往往源于发送端用了系统默认编码（如 GBK），而接收端强制用 UTF-8 解码；或发送端
json.dumps(..., ensure_ascii=True)把中文转成\u4f60\u597d，接收端又没做json.loads() - 频道名大小写敏感：
Order.Created和order.created是两个频道；Java 客户端订阅order.created，Python 发到Order.Created，消息就丢了
JSON 序列化是唯一靠谱的跨语言方案
Protobuf、Avro 等二进制格式要求 schema 同步，实践中极易因版本错位导致解析崩溃；而 JSON 被所有主流语言原生支持，容错性强，调试直观。
- 发送前统一调用：
json.dumps(obj, ensure_ascii=False)（Python）、new ObjectMapper().writeValueAsString(obj)（Java）、json.Marshal()（Go） - 接收后必须用对应语言的 JSON 解析器反序列化，不能直接当字符串用；例如 Java 收到字节数组，要先
new String(bytes, StandardCharsets.UTF_8)再ObjectMapper.readTree() - 避免在 JSON 中塞 base64 图片或二进制 blob——体积膨胀、解析慢、易出错；改用传递
{"image_url": "https://..."}或 Redis key 引用
连接断开后订阅自动恢复？别信
Redis 服务器从不保存客户端订阅状态。TCP 连接断开即丢失全部 SUBSCRIBE，哪怕客户端库标着 “auto-reconnect”，也只是重建连接，不会自动 SUBSCRIBE 回去。
- Java Lettuce 需监听
ConnectionEvents.CONNECTED事件，手动调用pubSubCommands.subscribe("order.created") - Go
go-redis的PubSub.Listen()返回 error 时，必须显式重连 + 重新psubscribe或subscribe - Python
redis-py的pubsub.listen()在连接中断后会 raiseConnectionError，需捕获并重建pubsub实例、重新subscribe() - 务必在重订阅前加短延时（如 100ms），避免反复断连引发雪崩式重试
频道命名和模式订阅的实际约束
通配符 PSUBSCRIBE 看似灵活，但在跨语言场景下容易埋坑——不同客户端对 pattern 匹配行为不完全一致，且 Redis 不保证 pattern 订阅的顺序和可靠性。
- 坚持小写 + 下划线命名：用
user.registered，不用UserRegistered或userRegistered - 避免嵌套层级过深：
com.example.order.payment.confirmed比order.payment.confirmed更难维护，也无实际收益 - 慎用
PSUBSCRIBE *：全匹配会收到所有频道消息，包括运维频道（如__sentinel__:hello），增加解析负担和误处理风险 - 如果必须用 pattern，确保所有语言客户端都测试过相同 pattern 的匹配结果（例如
order.*是否匹配order.created和order.updated）
真正麻烦的从来不是发消息，而是让所有服务在断网、重启、部署更新后，还能同步地重新找到彼此——这需要每个客户端都把订阅当作有状态的生命周期来管理，而不是当成一次性的 setup 步骤。
