字段含time.Time未注册自定义encoder会导致每次序列化触发反射调用，比直接Format()慢3–5倍；应在init阶段全局注册，避免handler中重复Froze()重建缓存。
字段含 time.Time 却没注册自定义 encoder，性能损失来自隐式反射调用
不是时间格式本身慢，而是未显式注册时，json.Marshal 或 jsoniter.Config{}.Froze() 会 fallback 到默认的 time.Time 反射路径：每次序列化都触发 reflect.Value.Interface() + 类型断言 + RFC3339 字符串拼接。这比直接调用 .Format() 慢 3–5 倍，且无法内联。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须提前注册：
jsoniter.RegisterTypeEncoder(reflect.TypeOf(time.Time{}), yourTimeEncoder)（jsoniter）或实现MarshalJSON()方法（标准库） - 避免在 handler 中重复注册——全局 init 一次即可，否则每次新建
Config都重走反射注册逻辑 - 若用
jsoniter.ConfigCompatibleWithStandardLibrary，它已预注册基础类型，但你自定义的 time 子类型（如type CreatedAt time.Time）仍需手动注册
jsoniter.Config{}.Froze() 在 HTTP handler 中调用等于重启反射缓存
每次调用 Froze() 都重建整个反射元数据缓存（包括字段索引、tag 解析、encoder 查表），相当于把本该只做一次的初始化塞进每秒上千次的请求热路径里。实测比全局复用一个 frozen config 慢 40% 以上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 声明全局变量：
var json = jsoniter.ConfigCompatibleWithStandardLibrary，后续直接用json.Marshal() - 若需定制（如开启
Unsafe），也在 init 阶段完成：var json = jsoniter.Config{Unsafe: true}.Froze() - 绝不要在 handler 函数体内写
jsoniter.Config{}.Froze().Marshal(...)—— 这是高频反射的典型误用
自定义 encoder 内部仍调用 reflect.ValueOf 就白优化了
很多人以为写了 MarshalJSON() 就绕过反射，结果在 encoder 里又调用 reflect.ValueOf(t).FieldByName("sec") 或 fmt.Sprintf，反而引入新一层反射和字符串分配。真正的零反射 encoder 应直接访问结构体字段地址。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对简单包装类型（如
type MyTime time.Time），直接转成基础类型再格式化：return []byte(t.Format("2006-01-02")) - 若需处理嵌套字段（如
type Event struct { At MyTime }），用代码生成工具（如easyjson或msgp）生成专用 marshal 函数，彻底避开reflect - 检查你的 encoder 是否逃逸：用
go build -gcflags="-m"确认返回的[]byte是否分配在堆上；若频繁分配，改用预分配 buffer +strconv.AppendInt类函数
真正省时间的，往往是绕过序列化本身
很多接口响应慢，根本不是 time.Time 格式化拖累，而是你在 hot path 上做了冗余转换：比如把数据库查出的 int64 时间戳反复转成 time.Time，再转回字符串；或在日志打点时对每个字段都调一次 json.Marshal。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 数据库层直接返回格式化字符串（如 PostgreSQL 的
to_char(created_at, 'YYYY-MM-DD')），跳过 Go 层解析 - 对固定结构的响应体，用结构体字段硬编码序列化逻辑（如
buf.WriteString(`{"at":"`); buf.WriteString(t.Format(...))），不依赖任何反射库 - 监控真实瓶颈：用
pprof看 CPU profile，确认reflect.Value.FieldByName或time.Time.Format是否真在 top 3；如果不是，优化它毫无意义
reflect.ValueOf 调用。 
