微服务解析复杂JSON应分层控制深度与内存开销：优先用json.RawMessage处理动态字段，流式场景用json.NewDecoder配合真实流源，结构体字段须显式加短标签并避免omitempty和,string转换。
微服务里解析复杂 JSON，别硬套 struct 或死磕 map[string]interface{} —— 关键是分层控制解析深度和内存开销。
json.Unmarshal 解析嵌套结构体时 panic: invalid memory address
常见于字段类型不匹配或指针未初始化。比如 json.Unmarshal 传入一个 nil 指针（如 &v 中的 v 是 nil），或者结构体字段声明为 *string 却收到 JSON null，而没做容错处理。
- 确保所有接收变量已声明且非 nil，尤其嵌套结构体字段：用
new(T)或显式初始化 - 对可能为 null 的字段，统一用指针类型（
*string、*int）并配合omitempty标签 - 避免在顶层结构体中混用
map[string]interface{}和 struct 字段——类型断言容易漏判，导致运行时 panic
字段名动态、类型不固定时怎么安全取值
比如 API 返回的 "data" 有时是对象，有时是数组，甚至可能是字符串；或 key 名由前端自由拼接（如 "custom_field_123"）。这时强绑定 struct 会频繁改代码，而全用 map[string]interface{} 又难维护。
- 优先用
json.RawMessage接收不确定字段：它只拷贝字节引用，不触发反序列化，内存和 CPU 开销极低 - 对多态字段，定义 wrapper 类型并实现
UnmarshalJSON([]byte)方法，在方法内根据首字符（{/[/"）分支处理 - 若必须用
map[string]json.RawMessage，记得校验 key 长度（防超长恶意 key）和 value 字节数上限（防单个字段膨胀）
大 JSON 流（如日志推送、文件导入）OOM 或卡死
json.Unmarshal 把整个 JSON 加载进内存再解析，几百 MB 的 payload 直接触发 GC 压力或 OOM；json.Decoder 虽支持流式，但用法不对照样白搭。
立即学习“go语言免费学习笔记（深入）”；
- 真正有效的流式解析必须配真实流源头：用
os.Open+bufio.NewReader，或 HTTP response.Body 直接传给json.NewDecoder - 禁止把大 byte slice 包进
bytes.NewReader再喂给json.NewDecoder—— 这只是 API 换了，内存占用没变 - 深层嵌套（>100 层）或超宽字段（如 base64 图片）会导致递归栈溢出或单次
Decode卡顿，此时应设Decoder.DisallowUnknownFields()并搭配RawMessage跳过无关块
性能敏感场景下结构体标签怎么写才不拖慢解析
反射是 encoding/json 的主要开销来源，尤其字段多、嵌套深时。标签本身不耗性能，但某些写法会隐式增加反射负担。
- 所有字段必须显式加
json:"xxx"标签，避免运行时反射读取字段名；字段名越短越好（如json:"id"而非json:"user_id"） - 慎用
omitempty：它需在编码/解码时判断零值，对 slice、map、指针额外做 nil 检查，简单字段可省则省 - 避免
json:",string"这类转换标签——字符串 ↔ 数字的 runtime 转换比直接解析慢 2~3 倍
复杂点不在语法，而在权衡：哪些字段真要结构化，哪些只需字节切片，哪些必须流式跳过。一上来就定义完整 struct，往往最后发现 70% 字段根本没用，还拖慢性能、增加维护成本。
