自定义 marshaljson 有时更慢，因字段少或未规避反射时，标准库 go 1.19+ 对 flat struct 的 codegen 优化优于手写；频繁调用 json.marshal 会触发多次小对象编码和字符串拼接，增加内存分配与逃逸。
为什么自定义 MarshalJSON 有时反而更慢？
直接结论：当字段数量少、结构简单、或未规避反射开销时，自定义 MarshalJSON 往往比标准库自动序列化更慢。Go 的 encoding/json 在 Go 1.19+ 对 flat struct 做了深度优化，底层用 codegen 避免反射；而手写 MarshalJSON 若频繁调用 json.Marshal 或拼接字符串，会触发额外内存分配和逃逸。
- 常见错误：在自定义函数里对每个字段都调用
json.Marshal（比如json.Marshal(v.Name)），导致多次小对象编码 + 字符串拼接 - 正确做法：用
json.Encoder写入bytes.Buffer，或手动构造字节切片（如用strconv.AppendInt处理数字） - 性能临界点：实测显示，仅含 3–4 个字段的 struct，手写
MarshalJSON开销通常高出 20%–40%；字段超 10 个且含嵌套/条件逻辑时，才可能反超
MarshalJSON 中如何避免 json.Marshal 递归调用？
递归调用 json.Marshal 是最常见性能陷阱——它会重新走一遍反射路径，丢失编译期优化，还容易引发栈溢出（尤其循环引用未处理时）。
- 替代方案：对内嵌 struct 或 map 手动展开，用
encoder.Encode写入已有bytes.Buffer，而非生成中间[]byte - 数字/布尔/字符串字段：直接用
strconv.AppendInt、strconv.AppendBool、bytes.ReplaceAll等零分配操作写入 buffer - 必须调用
json.Marshal的场景（如动态 map）：提前复用sync.Pool中的bytes.Buffer，避免每次 new
字段级控制：什么时候该用 json:",omitempty" 而不是手写逻辑？
多数“按条件省略字段”的需求，其实不需要自定义 MarshalJSON。标准 tag 已足够，且无运行时开销。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
omitempty在 encode 前由 json 包静态判断，不进反射 hot path；而手写逻辑里 if 判断 + 字段跳过，反而增加分支预测失败概率 - 例外场景：需根据上下文（如请求头、全局 flag）动态决定是否输出某字段——这时才值得引入自定义逻辑，但应把判断逻辑前置，缓存结果
- 注意：
omitempty对指针/接口/切片判空严格，但对自定义类型（如type UserID int64）默认不生效，需显式实现IsZero() bool
基准测试时容易被忽略的逃逸点
写完自定义 MarshalJSON 后跑 go test -bench 结果不准，往往是因为没压测真实内存压力场景。
- 关键检查：
go build -gcflags="-m" your_file.go看是否出现... escapes to heap—— 尤其是返回值为[]byte且内部用了fmt.Sprintf或strings.Builder.String() - buffer 复用必须跨 goroutine 安全：若用
sync.Pool，确保Get()后清空 buffer（b.Reset()），否则残留数据污染后续请求 - 别信单次 benchmark：用
-benchmem观察 allocs/op，比 ns/op 更反映真实瓶颈；若 allocs/op > 0，说明有堆分配，大概率还没榨干性能
真正收益明显的场景，是字段逻辑复杂（如敏感字段脱敏、时间格式强定制、嵌套结构扁平化），且 QPS 过万——此时那几纳秒差异才会累积成可观延迟。其他情况，先写清楚再优化，别过早手写 MarshalJSON。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
