sonic不是encoding/json的即插即用替代品，需适配Go版本≥1.21.10、启用CGO、避免Alpine环境；time.Time需显式注册格式，错误类型和strict mode行为不兼容；深度嵌套结构体需限制递归深度，避免map[string]interface{}滥用。
sonic 不是 encoding/json 的 drop-in 替代品，直接改 import 就跑，90% 会 panic、丢字段、编译失败——它快，但只对配得准、用得对的场景快。
sonic 编译失败：找不到 github.com/bytedance/sonic/loader
v1.9.0+ 版本引入 go:embed 和运行时代码生成，对构建环境敏感。常见于三类情况：
- Go 版本低于 1.21.0（比如 1.21.0-rc2 或 1.20.x），必须用稳定版如
go1.21.10 - 构建时设置了
CGO_ENABLED=0——sonic 核心解析器依赖 CGO，哪怕你没写任何 C 代码，底层 JIT 也会触发 - 使用 Alpine 镜像或精简 Go 发行版（如 apk add go），缺少
gcc和glibc支持
若必须纯静态链接（如嵌入式容器），降级到 v1.8.3（最后一个无 embed 依赖的版本），但会丢失 time.Time 直接格式化等特性。
sonic.Unmarshal 字段为空或 panic 的三个高频爆点
不是数据错，而是行为不兼容。标准库能过，sonic 报错，基本都栽在这儿：
立即学习“go语言免费学习笔记（深入）”；
-
time.Time默认输出纳秒整数（如"2024-01-01T12:00:00.123456789Z"→1704110400123456789），需在 init 中显式注册：sonic.RegisterTimeFormat("2006-01-02T15:04:05Z07:00") - 错误类型不同：标准库返回
json.UnsupportedTypeError，sonic 返回sonic.InvalidCharacterError；检查必须用errors.As(err, &sonic.InvalidCharacterError{})，不能只写err != nil - strict mode 默认跳过未导出字段 + tag 格式错误（如
json:"name,"多了个逗号），而标准库有时会容忍
sonic.Marshal 比 json.Marshal 还慢？那是 JIT 在“瞎编译”
不是 sonic 慢，是 JIT 对你的结构体“用力过猛”：
- 深度嵌套结构体（如 5 层以上）触发大量重复汇编生成，首请求延迟飙升；用
go build -gcflags="-m"看输出，若频繁出现compiler: generated encoder for struct XXX，说明正在做无意义重复编译 - 显式限制递归深度：
sonic.Config{CompileOptions: option.CompileOptions{RecursiveDepth: 3}}（90% 的业务结构体 ≤3 层） - 禁用冗余指令集标签：构建时只加
-tags "amd64 avx2"，别留着sse4、neon等不用的标签 - 避免在 hot path 上反复对同一 struct 类型调用
sonic.Marshal——它和标准库一样不缓存反射结果
map[string]interface{} 是 sonic 的性能黑洞
传 map[string]interface{} 给 sonic.Marshal，它立刻退化到最慢路径：失去所有结构体信息，全程走泛型分支，比标准库还慢。
真实业务中，80% 的 JSON 有稳定 schema，优先定义明确 struct：
type User struct {
Name string `json:"name"`
Age int `json:"age"`
}
若必须用 map（如通用网关），至少在 init 里预热一次：sonic.Marshal(map[string]interface{}{"a": 1})，让 JIT 缓存基础泛型逻辑；但更推荐用 sonic.Get / sonic.Set 做局部提取，避开全量 marshal。
最容易被忽略的一点：sonic 对输入编码极其严格——BOM、控制字符（\x00）、非 UTF-8 字节（如 GBK 混入）都会直接 panic invalid character，而标准库有时反而能跳过。上线前务必加 utf8.Valid(data) 校验，或前置剥离 BOM。
