JSON序列化慢主因是标准库默认反射开销大，涉及字段遍历、tag解析、nil检查、UTF-8转义等；优化方案包括用jsoniter预编译反射信息或easyjson生成无反射代码，但根本在于结构体设计合理性。
为什么 json.Marshal 会慢得明显？
不是因为 Go 的 JSON 库本身烂，而是默认行为太“老实”：它要反射遍历每个字段、检查 tag、处理 nil 指针、做类型动态判断，还强制做 UTF-8 安全转义（比如把 " 变成 \"）。只要结构体嵌套深、字段多、含指针或 interface{}，性能就肉眼可见掉下去。
- 高频 API 返回结构体？别直接
json.Marshal(resp)，尤其 resp 含map[string]interface{}或interface{}字段时，反射开销翻倍 - 字段名全是小写但 tag 写了
json:"user_name"？tag 解析本身就有额外字符串匹配成本 - 用
json.RawMessage缓存已序列化的字节？注意它不校验内容合法性，json.Unmarshal时出错才暴露，容易漏测
用 jsoniter 替换标准库真的有用吗？
有用，但不是无脑换。jsoniter 是兼容 stdlib 接口的 drop-in 替代，核心优势是预编译反射信息 + 更少的内存分配 + 可选跳过 escape。但它对 struct 的首次加载仍有反射开销，且不支持所有 stdlib 边界行为（比如某些自定义 MarshalJSON 的调用顺序）。
- 替换只需两行：
import jsoniter "github.com/json-iterator/go"，然后把json.Marshal改成jsoniter.ConfigCompatibleWithStandardLibrary.Marshal - 若确定字段名固定、无运行时动态结构，启用
jsoniter.Config{EscapeHTML: false}能省掉 HTML 实体转义（如→\u003c），提升 5%–10% 吞吐 - 别在 init 函数里反复调用
jsoniter.Config创建新配置——复用单例实例，否则 GC 压力反升
MarshalJSON 方法里手写字符串拼接靠谱吗？
靠谱，但只适合字段少、结构稳定、不常变的场景。手写能彻底绕过反射，避免分配，甚至可复用 bytes.Buffer。可一旦字段增减或类型变更，极易漏改、格式错位、引号/逗号缺失，调试时看到一长串无结构的 JSON 字符串，比 panic 还难定位。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须严格按 JSON 规范：字符串字段需双引号包裹、特殊字符手动转义（
"→\"）、数值字段不能加引号、布尔和 null 直接写小写 - 别用
fmt.Sprintf拼接，用buf.WriteString+strconv.AppendInt等零分配函数，否则失去优化意义 - 如果结构体含 slice 或嵌套 struct，手写逻辑迅速失控——这时不如上
easyjson自动生成代码
什么时候该考虑 easyjson 自动生成？
当你有 3+ 个高频序列化的 struct，且字段数量 > 5、含嵌套或 slice，又不愿维护手写 MarshalJSON 时。easyjson 在 build 阶段生成专用序列化函数，完全消除反射，性能接近手写，还能保证正确性。
- 安装后加一行注释：
//easyjson:json放在 struct 上方，再跑easyjson -all xxx.go - 生成的代码依赖
easyjson/jwriter，它内部用预分配 buffer，比标准库bytes.Buffer更轻量 - 注意 tag 冲突：如果 struct 已有
json:"name,omitempty"，easyjson会照常解析，但omitempty逻辑需在生成代码里确认是否生效（某些旧版本有 bug）
真正卡点不在工具选型，而在结构体设计本身——字段要不要指针、time.Time 存不存纳秒、map 键是不是总是字符串，这些决定着后续所有优化的上限。没理清数据契约之前，换库或生成代码都只是在补漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
