json.Marshal高并发变慢因反射开销大、GC压力高；应避免map[string]interface{}、用struct替代，并注意sonic替换的兼容性与配置优化。
为什么 json.Marshal 在高并发场景下突然变慢
Go 标准库的 json.Marshal 默认使用反射 + interface{} 路径，每次调用都要动态解析结构体字段、检查标签、分配临时 map/slice。在 QPS 过万、结构体嵌套深或字段多的服务中，GC 压力和 CPU 消耗会明显上升，pprof 里常看到 reflect.Value.Interface 和 encoding/json.(*encodeState).marshal 占比很高。
- 别在 hot path 上对同一结构体反复调用
json.Marshal—— 即使结构体没变，标准库也不会缓存反射结果 - 避免用
map[string]interface{}接收并转发 JSON，它强制走最慢的通用编码路径 - 如果字段名固定、类型稳定，优先用 struct 而非 map；编译期可确定的字段访问比运行时反射快 3–5 倍
用 sonic 替换标准库前必须确认的三件事
sonic 是字节开源的零拷贝 JSON 库，底层用 C++ 编写、通过 CGO 调用，性能通常比标准库高 2–4 倍，但不是“开箱即用”的平替。
- 你的 Go 版本得 ≥ 1.16，且构建时不能加
-tags purego（否则自动退回到慢速纯 Go 实现） - 确保部署环境允许 CGO：Docker 镜像需带
gcc和libc-dev，Alpine 用户得切到cgruntime或改用sonic-go（纯 Go 分支，性能打七折） -
sonic默认禁用浮点数精度保护（如1.0000000000000001可能被序列化为1），若业务依赖精确浮点表示，得显式传sonic.UseFloat64Precision()
sonic.Marshal 和 json.Marshal 的参数行为差异
两者函数签名看似一致，但底层处理逻辑不同，尤其在 nil 处理、时间格式、错误返回上容易翻车。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
nil *struct{}：标准库输出null；sonic默认 panic，需提前判空或用sonic.Config{EnsureASCII: false, NoNullSliceOrMap: true} -
time.Time：标准库按RFC3339Nano输出；sonic默认不格式化，直接输出 Unix 纳秒时间戳，得手动注册自定义 marshaler：sonic.RegisterTimeFormat("2006-01-02T15:04:05Z07:00") - 错误类型：标准库错在字段 tag 就返回
json.UnsupportedTypeError；sonic错在序列化中途可能返回sonic.InvalidCharacterError，需统一用errors.As检查，不能只看err != nil
实测发现最影响 sonic 性能的两个隐藏配置
很多人直接 import "github.com/bytedance/sonic" 就跑，但默认配置在某些场景反而比标准库还慢。
立即学习“go语言免费学习笔记（深入）”；
- 开启
sonic.OptionNoQuoteTextMarshaler：如果你的 struct 实现了encoding.TextMarshaler，默认会多一次字符串引号包裹，关掉后可省 10%–15% 时间 - 禁用
sonic.OptionValidateUTF8：当输入数据已确定是合法 UTF-8（比如来自数据库或内部 RPC），跳过校验能再提速 8% 左右；但上游不可信时务必保留 - 注意：这些 Option 必须在首次调用
sonic.Marshal前设置，之后修改无效 —— 它们影响的是全局 encoder 初始化逻辑
真正卡住性能的往往不是选 sonic 还是 stdlib，而是没意识到 struct 字段顺序、tag 冗余、嵌套深度这些静态特征，在 sonic 里会被编译成固定指令流，一旦写错就再也优化不动了。
