json.unmarshal必须传指针，否则解析结果为零值；结构体字段需加json tag才能匹配json键名；类型不匹配会报错，忽略err或缺少tag导致静默失败。
json.Unmarshal 传入的必须是指针
传 json.Unmarshal 一个普通变量（比如 var u User），它不会报错，但解析结果永远是零值。因为 Go 是值传递，函数内部只能修改副本。
正确做法永远是传地址：&u。哪怕结构体字段全是导出的、类型完全匹配，不传指针就白解析。
- 错误写法：
json.Unmarshal(data, u)→ 字段全为零值 - 正确写法：
json.Unmarshal(data, &u) - 如果解析到 map 或 slice，也要传指针：
json.Unmarshal(data, &m)或json.Unmarshal(data, &s)
struct 字段没加 json tag 就无法反序列化
Go 的 json 包默认只处理导出字段（首字母大写），且要求字段名与 JSON key 完全一致（大小写敏感）。实际 JSON 常用小写下划线命名（如 user_name），不加 tag 就对不上。
别指望“自动转驼峰”——标准库不干这事，第三方库才可能支持。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- JSON 中是
"user_id"，结构体字段得写UserID int `json:"user_id"` - 字段想忽略就用
json:"-"；想允许空字符串或 null 赋值给 string，用json:",omitempty"（注意：它只影响序列化，不影响反序列化） - 嵌套结构体字段也要逐层加 tag，漏一层就解析失败
反序列化时类型不匹配导致静默失败或 panic
json.Unmarshal 对类型不匹配的容忍度很低：数字进 string、bool 进 int、null 进非指针字段，都会直接返回 json.UnmarshalTypeError 错误。但很多人忽略 err 检查，结果变量还是零值，还以为数据丢了。
- 常见错误现象：
json: cannot unmarshal number into Go struct field X of type string - string 类型字段收到
null？必须改成*string才能接住（否则报错） - 整数字段收到浮点数（如
123.0）？Go 默认允许，但精度可能丢失；想严格校验就得先用json.RawMessage手动解析 - 切片字段收到非数组值（比如
null或对象）？会报错，不是变成空切片
性能和兼容性：不要反复 Unmarshal 同一段 data
每次调用 json.Unmarshal 都要重新解析整个字节流，开销不小。如果同一段 []byte 要解析成多个结构体（比如先看 type 字段再分发），别重复调用。
更稳妥的做法是先解析成 map[string]interface{} 或 json.RawMessage，再按需转换。虽然内存多占一点，但避免了重复词法分析。
- 高频场景（如 API 网关）建议用
json.RawMessage延迟解析关键子字段 - 注意：
json.RawMessage保存的是原始字节引用，如果原始[]byte被复用或释放，它会失效 - 标准库不支持流式解析（不像 Python 的 ijson），大 JSON 必须全加载进内存
最常被跳过的其实是错误检查和字段 tag 的一致性——写完 struct 不顺手补上 tag，或者把 err 写成 _，后面排查时就得一行行打日志。JSON 反序列化看着简单，崩起来悄无声息。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
