Protobuf在性能和数据体积上优于JSON，因其为二进制协议且避免反射，适用于内部服务通信；JSON因可读性和兼容性，更适合对外API。
在Golang中进行数据序列化时，Protobuf与JSON的性能对比是一个老生常谈的话题，但其核心结论依然明确：在绝大多数需要高性能和数据紧凑性的场景下，Protobuf的表现要远优于JSON。 这不仅仅体现在序列化和反序列化的速度上，更在于最终数据包的体积。究其原因，Protobuf是一种二进制协议，而JSON是文本协议，两者在底层处理机制上有着本质的区别。
解决方案： 理解Protobuf和JSON在Golang中的工作机制，是做出选择的基础。JSON作为文本格式，其优势在于人类可读性强、跨语言兼容性好（无需预定义schema）、以及与Web生态的无缝结合。在Golang中，标准库的
encoding/json
Protobuf（Protocol Buffers）则完全不同。它要求你先定义一个
.proto
protoc
我个人认为，选择哪种序列化方式，很大程度上取决于你的应用场景和对性能的敏感度。如果你的服务主要面向Web前端或需要高度可读性、易调试的API，JSON无疑是更合理的选择。但如果是在内部微服务之间进行RPC调用，或者需要将大量数据高效地存储或传输，Protobuf的优势就非常明显了。别为了所谓的“性能提升”，上来就给自己挖坑，除非你真的知道你在做什么。
在Golang中实现这两种序列化方式，各有其特点和常用模式。
立即学习“go语言免费学习笔记（深入）”；
对于JSON，这算是Go开发者最熟悉的了。你通常会定义一个结构体，然后利用
json.Marshal
json.Unmarshal
package main
import (
"encoding/json"
"fmt"
"log"
)
type User struct {
ID int `json:"id"`
Name string `json:"name"`
Email string `json:"email,omitempty"` // omitempty表示如果为空值则不序列化
}
func main() {
// JSON 序列化
user := User{ID: 1, Name: "Alice", Email: "alice@example.com"}
jsonData, err := json.Marshal(user)
if err != nil {
log.Fatalf("JSON Marshal error: %v", err)
}
fmt.Println("JSON data:", string(jsonData))
// JSON 反序列化
var newUser User
err = json.Unmarshal(jsonData, &newUser)
if err != nil {
log.Fatalf("JSON Unmarshal error: %v", err)
}
fmt.Printf("JSON Unmarshaled: %+v\n", newUser)
// 演示omitempty
userNoEmail := User{ID: 2, Name: "Bob"}
jsonDataNoEmail, err := json.Marshal(userNoEmail)
if err != nil {
log.Fatalf("JSON Marshal error: %v", err)
}
fmt.Println("JSON data (no email):", string(jsonDataNoEmail))
}这段代码直观易懂，
json
而Protobuf则需要多一步：定义
.proto
user.proto
syntax = "proto3";
package example;
option go_package = "./;example"; // 指定Go包名和路径
message User {
int32 id = 1;
string name = 2;
string email = 3;
}然后，使用
protoc
protoc --go_out=. --go_opt=paths=source_relative user.proto
user.pb.go
接着，在你的Go代码中就可以使用这些生成的结构体和方法了：
package main
import (
"fmt"
"log"
// 导入生成的Protobuf包
"google.golang.org/protobuf/proto" // 确保你已经安装了 go get google.golang.org/protobuf
"example" // 对应 user.pb.go 中的 package example
)
func main() {
// Protobuf 序列化
user := &example.User{
Id: 1,
Name: "Alice",
Email: "alice@example.com",
}
protoData, err := proto.Marshal(user)
if err != nil {
log.Fatalf("Protobuf Marshal error: %v", err)
}
fmt.Println("Protobuf data (binary):", protoData) // 打印出来是字节切片
// Protobuf 反序列化
var newUser example.User
err = proto.Unmarshal(protoData, &newUser)
if err != nil {
log.Fatalf("Protobuf Unmarshal error: %v", err)
}
fmt.Printf("Protobuf Unmarshaled: %+v\n", newUser)
}Protobuf的序列化和反序列化通过
proto.Marshal
proto.Unmarshal
本文档主要讲述的是Android 本地数据存储；对于需要跨应用程序执行期间或生命期而维护重要信息的应用程序来说，能够在移动设备上本地存储数据是一种非常关键的功能。作为一名开发人员，您经常需要存储诸如用户首选项或应用程序配置之类的信息。您还必须根据一些特征（比如访问可见性）决定是否需要涉及内部或外部存储器，或者是否需要处理更复杂的、结构化的数据类型。跟随本文学习 Android 数据存储 API，具体来讲就是首选项、SQLite 和内部及外部内存 API。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以
0
在Golang中，序列化性能并非单一因素决定，它是一个多方面影响的综合结果。我个人在实践中总结了几点关键因素：
encoding/json
encoding/json
jsoniter
gogo/protobuf
unsafe
在我看来，如果你发现序列化成为了你的性能瓶颈，那么深入理解这些因素，并结合具体的业务场景进行优化，是必不可少的。
在实际项目中，选择Protobuf还是JSON，从来都不是一个简单的“哪个更快就用哪个”的问题。它更像是一场权衡艺术，需要综合考虑性能、开发效率、可维护性、兼容性以及团队熟悉度等多个维度。
对于对外接口（Public APIs）或Web服务： 我个人认为，JSON几乎是唯一的选择。原因很简单：
你很难想象一个对外提供Protobuf二进制流的Web API，那会让前端和第三方集成方崩溃的。所以，对外接口，JSON是没得选的，因为它就是事实标准，好调试，兼容性好。
对于内部微服务通信（Internal Microservices/RPC）： 这是Protobuf大放异彩的舞台。
.proto
我个人是倾向于在服务间通信时无脑上Protobuf的，除非有特别的理由，比如某个服务确实非常简单，数据量极小，或者为了快速迭代而暂时放弃强类型约束。
其他考量：
.proto
protoc
最终的选择，往往是基于对项目需求、团队技能栈和未来扩展性的综合评估。没有银弹，只有最适合的方案。
以上就是Golang序列化性能对比 protobufvsJSON的详细内容，更多请关注php中文网其它相关文章！
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
233
收藏
