java序列化选型核心是场景匹配：微服务内部高频调用选protobuf（体积小、速度快、跨语言），对外rest api选json（可读性强、生态成熟），单jvm内临时缓存才考虑java原生（严禁跨网络）。

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 压力大）

Feishu calendar sync, local ics to json data for AI agent

将ICS日历文件转为JSON格式，用于飞书日历导入导出及数据集成。

下载

原因很实在：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免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南