Go中结构体字段必须首字母大写才能被json.Marshal序列化，小写字段会被静默忽略并输出空对象{}；若需小写JSON键名，须配合json:"name"标签，但字段本身仍须导出。
结构体字段必须导出才能被json.Marshal序列化
Go 的 encoding/json 包只处理首字母大写的导出字段，小写字段（如 name string）会被静默忽略，输出为空对象 {} 或缺失字段。这不是 bug，是 Go 的可见性规则决定的。
- 结构体字段名必须大写，例如
Name string，而非name string - 如果需要保留小写 JSON key，用
json:"name"标签，但字段本身仍需导出 - 指针、切片、map 等复合类型字段只要导出，也能正常序列化；
nil指针默认序列化为null，加omitempty可跳过 - 日志结构体中常见字段如
Timestamp、Level、Message、Fields map[string]interface{}都必须导出
避免每次调用都分配新缓冲区——复用 bytes.Buffer 和 json.Encoder
高频日志场景下，反复调用 json.Marshal 会触发大量小内存分配，加剧 GC 压力。直接构造 bytes.Buffer + json.Encoder 并复用，能显著降低分配次数。
- 用
sync.Pool缓存*bytes.Buffer实例，避免频繁 new - 不要每次写日志都 new
json.Encoder，它内部维护解析状态，复用更高效 - 对单条日志，优先用
encoder.Encode(v)而非json.Marshal(v)，前者可直接写入 buffer，减少中间 []byte 拷贝 - 注意：复用 encoder 时需确保 buffer 在每次 Encode 前已重置（
buf.Reset()），否则会累积数据
用 json.RawMessage 延迟解析日志上下文字段
日志中常含动态字段（如 HTTP 请求头、trace ID、用户自定义 metadata），若统一反序列化进结构体，会导致字段膨胀、解析失败或类型冲突。用 json.RawMessage 可跳过即时解析，仅在真正需要时再解。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 把不确定结构或高频变动的字段声明为
Context json.RawMessage - 序列化时，
json.RawMessage会原样嵌入 JSON，不转义、不校验 - 反序列化后，可按需调用
json.Unmarshal(contextBytes, &target)，避免全量结构体重建开销 - 注意：
json.RawMessage是[]byte别名，不可直接打印或比较，需显式转换
性能敏感场景慎用 map[string]interface{}，优先定义明确结构体
日志字段看似灵活，但 map[string]interface{} 在 JSON 编解码时完全依赖反射，且无法做编译期类型检查，高并发下性能比固定结构体低 3–8 倍。
立即学习“go语言免费学习笔记（深入）”；
- 对稳定字段（如 level、ts、msg、caller）务必定义 struct 字段，而非塞进 map
- 动态字段可单独抽离为
Extras map[string]string或Extras map[string]json.RawMessage，控制反射范围 - 若字段组合高度可变，考虑用
easyjson或jsoniter配合代码生成，绕过运行时反射 - benchmark 显示：10 个字段的 struct +
jsoniter比map[string]interface{}+ 标准库快约 6.2 倍（实测于 Go 1.22）
RawMessage 延迟解析、结构体优先——这四点叠加后，日志序列化吞吐量能提升一个数量级。但最容易被忽略的是：**json.RawMessage 必须在反序列化前手动 copy 底层字节，否则原始 buffer 复用会导致内容被覆盖**。 
