Java序列化选型核心是场景匹配：微服务内部高频调用选Protobuf（体积小、速度快、跨语言），对外REST API选JSON（可读性强、生态成熟），单JVM内临时缓存才考虑Java原生（严禁跨网络）。
看体积：JSON 比原生序列化大，但比 Protobuf 大得多
相同对象（如含 5 个字段的 User），实测典型体积比约为：
Protobuf ≈ 1x（基准）
JSON ≈ 3–5x（字段名重复、无压缩、纯文本）
Java 原生 ≈ 2–3x（二进制但含类信息、元数据冗余）
这意味着：带宽敏感场景（如移动端 API、高并发网关）、存储成本敏感（如 Kafka Topic 存储周期长），JSON 会明显推高带宽和磁盘压力；而 Java 原生虽比 JSON 略小，却仍远不如 Protobuf 紧凑。
- 字段越多、嵌套越深，JSON 体积劣势越放大（每个 key 都重复出现）
- Protobuf 的 varint 编码让 id=1 只占 1 字节，JSON 写成
"id":1至少占 6 字节 - Java 原生自带 class name、field descriptors、serialVersionUID 等元数据，不可省略
看速度：JSON 解析慢于 Protobuf，但快于 Java 原生
平均反序列化耗时排序（中小对象，JDK 17+）：
Protobuf 最快（快 3–5 倍于 Java 原生）
JSON 居中（Jackson 默认配置下约比 Java 原生快 1.5–2 倍）
Java 原生最慢（反射 + 类加载 + 完整对象图重建，GC 压力大）
原因很实在：Protobuf 是预编译强类型，直接内存拷贝；JSON 是字符串解析 + 动态映射；Java 原生要触发构造器、readObject()、甚至静态块——Log4j2 漏洞就出在这儿。
- 高频 RPC（如 Dubbo 3/gRPC 内部调用）必须选 Protobuf，延迟压到毫秒级以下
- 管理后台、开放 API、前端直连接口，JSON 的可读性 + Spring Boot 自动适配更省事
- Java 原生只适合单 JVM 内短时缓存（如 Guava Cache），绝不能走网络或跨进程
看兼容性：JSON 和 Protobuf 天然跨语言，Java 原生完全封闭
这是决定性一票——只要系统不止一个语言栈，Java 原生序列化直接出局。
- Python/Go/JS 客户端根本无法识别 Java 二进制流，连调试都做不到
- JSON 是浏览器、移动端、运维工具的通用语言，curl 就能看、Postman 直接发
- Protobuf 通过 .proto 文件定义契约，生成各语言代码，gRPC 生态已全覆盖
- Java 原生依赖 serialVersionUID，JDK 8 升 17 或加个 transient 字段就可能反序列化失败
怎么选？按场景三句话收口
微服务内部高频调用 → 用 Protobuf（配合 gRPC 或 Dubbo 3）
对外 REST API / 管理后台 / 第三方集成 → 用 JSON（Jackson + @JsonInclude(NON_NULL) 减体积）
单 JVM 内临时缓存（非持久、非跨线程）→ 可用 Java 原生，但需严格管控生命周期
别纠结“性能数字”，先问清楚：数据谁消费？走哪条链路？是否要人肉排查？这三个问题答完，选型自然清晰。
立即学习“Java免费学习笔记（深入）”；
