go网络数据序列化应按场景选择：jsON适用于跨语言、可读性要求高的场景；binary（如gob）适用于Go同构系统高性能通信；protobuf等适合跨语言且需向后兼容的高吞吐场景。
Go 语言处理网络数据序列化，核心在于根据场景选对方式：json 适合人可读、跨语言交互；binary（如 encoding/gob 或自定义二进制协议）适合高性能、同构 Go 系统间通信。关键不是“哪个更好”，而是“哪个更合适”。
JSON 序列化：简单、通用、易调试
Go 内置 encoding/json 包开箱即用，结构体字段需导出（首字母大写），并推荐加 JSON 标签明确映射关系。
常见写法示例：
type User Struct { ID int `json:"id"` Name string `json:"name"` Email string `json:"email,omitempty"` // 空值不序列化 Active bool `json:"active"` } data, err := json.Marshal(User{ID: 1, Name: "Alice", Email: ""}) // 输出：{"id":1,"name":"Alice","active":false}注意点：
立即学习“go语言免费学习笔记（深入）”；
- 非导出字段（小写开头）不会被序列化
-
omitempty对零值字段跳过，但要注意它也跳过空字符串、0、nil 切片等 - 反序列化时字段名必须匹配（或靠 tag），类型要兼容，否则静默失败或报错
- 性能中等，解析涉及反射和字符串操作，大数据量或高频调用时有开销
Binary 序列化（以 gob 为例）：快、紧凑、Go 原生
encoding/gob 是 Go 官方提供的二进制序列化方案，专为 Go 类型设计，无需 schema 定义，支持 struct、slice、map、Interface{}（有限制）等，且自动处理类型信息。
基本用法：
var buf bytes.Buffer enc := gob.NewEncoder(&buf) err := enc.Encode(User{ID: 1, Name: "Alice"}) var u User dec := gob.NewDecoder(&buf) err := dec.Decode(&u) // 类型必须一致，且结构体需已注册（如果含 interface{} 或自定义类型）关键特性：
- 比 JSON 小 30%–50%，序列化/反序列化速度快 2–5 倍（实测取决于数据结构）
- 不 human-readable，无法直接查看或手工编辑
- 仅限 Go 生态，gob 文件不能被 python/JS 直接解析
- 升级结构体需谨慎：新增字段建议设默认值，删除字段可能导致解码失败；跨进程版本不一致时建议显式注册类型（
gob.register()）
如何选择？看这三点
不必纠结“技术先进性”，从实际约束出发：
- 对外 API、配置文件、日志输出 → 选 JSON（可读、可验、易集成）
- 微服务内部 rpc、消息队列 payload、缓存 value（如 redis 存 struct）→ gob 或更轻量的
encoding/binary（需自己定义格式） - 极致性能要求（如每秒万级小对象传输）、带宽敏感（iot 设备）→ 考虑 Protocol Buffers（protobuf）或 FlatBuffers，它们提供跨语言 + 高效二进制 + 向后兼容能力，比 gob 更适合长期演进的系统
小提醒：别忽略错误处理和边界
无论用哪种方式，网络数据不可信。务必：
- 检查
Marshal/Encode和Unmarshal/Decode的返回错误，尤其反序列化失败常导致 panic 或静默数据丢失 - 对 JSON 输入做字段白名单校验（或用
json.RawMessage延迟解析），防恶意超长字符串、深层嵌套触发栈溢出 - gob 解码前确认数据来源可信——它不校验类型安全性，伪造数据可能引发 panic 或内存异常
基本上就这些。JSON 和 binary 不是互斥选项，而是一组工具里的不同螺丝刀——拧什么钉子，就拿哪一把。