微服务通信性能瓶颈八成源于序列化，首选grpc+protobuf；禁用json.marshal高频调用，避免map和gob跨服务使用，结构体标签需按层拆分，契约设计决定重构成本。
微服务间通信的性能瓶颈，八成出在序列化环节——不是代码写得不够好，而是选错了序列化方式或用错了结构体定义方式。
gRPC + Protobuf 是生产环境首选，不是因为它“高级”，而是它解决了根本问题
默认用 json.Marshal 传结构体？CPU 和带宽很快会报警。Protobuf 生成的二进制体积比 JSON 小 60%~80%，解析速度通常快 3~5 倍，且天然支持字段增删、版本兼容、多语言互通。
- 必须用
.proto文件定义消息，不能绕过 IDL 直接用 Go struct —— 这是契约前置，不是麻烦 - 避免使用
map<string string></string>这类弱类型字段；改用repeated KeyValue（自定义键值对 message），否则后续加校验、做 schema 演进会卡死 -
oneof字段在 Go 中生成的是interface{}，反序列化后必须显式type assert，否则 runtime panic 很难定位 - 启用
UseCustomCodec选项虽可插拔替换编解码器，但实际极少需要；别为了“可能的未来优化”增加当前复杂度
JSON 只该用在明确场景，且必须做三件事
HTTP API 对前端、调试接口、跨语言轻量交互——这些才是 JSON 的合理位置。但直接用标准库 json.Marshal 仍会拖慢高频调用。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
jsoniter.ConfigCompatibleWithStandardLibrary替换标准encoding/json，能提升 30%+ 编解码速度，且完全兼容原有 tag - 敏感字段必须打
json:"-"，数组里含密码哈希、ID、token 的字段绝不能靠业务层“手动删”，要靠 tag 从序列化源头过滤 - 时间字段统一转
UnixMilli()存int64，别传time.Time；json:"created_at,string"这种写法在跨服务时容易因时区/格式不一致出错
gob 只能在同构 Go 内部用，且要用对姿势
Redis 缓存 Session、Sidecar 与主进程通信、本地 IPC——这些是 gob 的安全区。跨服务、跨语言、长期演进的接口，gob 就是定时炸弹。
- 所有字段必须导出（首字母大写），嵌套结构也不能含未导出字段，否则
gob会 panic - 启动时必须调用
gob.Register()预注册所有可能传输的类型；没注册的类型，反序列化会静默失败或 panic，日志里还找不到线索 - 结构体字段增删或类型变更，旧版本服务反序列化直接失败——gob 没 schema 版本管理，靠人肉对齐
结构体标签污染是隐性技术债，早拆早轻松
一个 struct 上同时挂着 json:、bson:、xml:、pg: 标签？这不是“灵活”，是把数据契约和传输协议全揉进业务模型里。
- 按职责拆：API 层用
api.User（只带json:），DB 层用db.User（只带bson:或pg:），领域层用domain.User（零标签） - 转换用手动赋值，不用反射库；一行字段对应一行赋值，出错立刻定位，性能无损耗，IDE 自动补全也正常
- 新增输出格式（比如导出 Excel 需要
csv:）时，只加新 struct 和转换函数，不影响原有任何一层
真正难的不是选哪个序列化库，而是判断“这个数据此刻该以什么契约离开当前服务”。协议选错还能换，契约设计歪了，后期重构成本是指数级上升。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
