Protobuf序列化+反序列化速度普遍比JSON快2–5倍，内存占用低30%–60%，但需结构稳定且有预定义schema；临时配置或调试用JSON更省事。
Redis String存对象，JSON和Protobuf谁更快？
直接说结论：Protobuf序列化+反序列化速度普遍比JSON快 2–5 倍，内存占用低 30%–60%，但前提是对象结构稳定、有预定义 schema。如果只是临时存个配置或调试用的 Map，JSON 更省事，别硬上 Protobuf。
json.dumps() vs protobuf.SerializeToString() 实测差异点
Python 下用 redis-py 存一个含 10 个字段的用户对象（含嵌套地址、时间戳），反复压测 10 万次：
-
json.dumps()平均耗时约 85 μs/次，生成字符串平均长度 320 字节 -
protobuf.SerializeToString()平均耗时约 22 μs/次，生成字节流平均长度 126 字节 - 反序列化差距更大：JSON 需解析+类型推断，Protobuf 直接按 schema 填字段，快 4 倍以上
- 注意：
json.dumps()默认不处理datetime，会抛TypeError；Protobuf 的timestamp字段必须用google.protobuf.timestamp_pb2.Timestamp转换，否则写入失败
Redis里存Protobuf要注意的三个硬限制
Protobuf 本身不校验数据合法性，但 Redis String 是纯字节容器，出错往往在边界上：
- 必须用
bytes写入 Redis，不能传str——r.set("user:123", pb_data)对，r.set("user:123", pb_data.decode())错，会触发UnicodeDecodeError - Protobuf 没版本兼容性自动降级机制：v1 消息加了新字段后，v0 客户端反序列化会静默丢弃该字段；JSON 则能读出所有 key，只是 v0 代码没定义对应字段而已
- Redis 不支持类型元信息，
GET user:123返回 raw bytes，你得自己记住这个 key 存的是UserProto还是OrderProto，建议 key 命名带前缀，比如proto:user:123
什么时候该坚持用 JSON？
不是所有场景都适合换 Protobuf，尤其当开发节奏快、结构常变、或需人工查 Redis 数据时：
- 调试阶段用
redis-cli GET user:123看值，JSON 可读，Protobuf 是乱码——除非你装了protoc --decode_raw - 前端直连 Redis（如某些边缘网关场景）需要解析，JSON 天然支持，Protobuf 得额外配解码逻辑
- 对象字段类型动态（比如 value 是
dict或list混合嵌套），Protobuf 要写oneof或Any，复杂度陡增，JSON 一行json.dumps(obj, default=str)就搞定
Protobuf 的优势在服务间高频、定结构、低延迟通信，而不是替代 JSON 做通用序列化。存进 Redis 只是手段，别让序列化方式绑架了业务迭代节奏。
