json字段名需用json tag重命名且字段必须首字母大写导出；omitempty对nil指针生效但对空字符串无效；大小写不一致时需预处理或自定义unmarshaljson；json.rawmessage可延迟解析避免冲突。
JSON字段名不匹配时，直接用json tag改名
Go默认把结构体字段名转成小写驼峰（如UserName → username）做JSON键，但API往往要user_name或userId这种。别动结构体名，加json tag就行。
常见错误是漏掉json后面的冒号，或者写成json:"user_name,"多打了个逗号——会静默忽略tag，输出还是username。
-
json:"user_name"：强制指定字段名，不带逗号就是纯重命名 -
json:"user_name,omitempty"：值为空（0、""、nil等）时整个字段不出现 -
json:"-"：该字段完全不参与序列化/反序列化 - 如果字段是
*string且为nil，omitempty会让它消失；但""（空字符串）不会消失，除非你额外判断
嵌套结构体里字段名没生效？检查是否漏了导出首字母
Go的JSON包只处理**导出字段**（首字母大写），type User struct { name string }里的name永远进不了JSON，无论你加多少json tag都没用。
典型场景：从HTTP请求解析JSON到结构体，结果字段全是零值，打印出来却是{}——八成是字段没导出。
- 必须写成
Name string `json:"name"`，小写name无效 - 嵌套结构体同理：
Profile ProfileInfo `json:"profile"`，其中ProfileInfo内部字段也得大写+加tag - 如果用
map[string]interface{}临时接数据再转结构体，字段导出问题就绕过去了，但失去类型安全
反序列化时字段名大小写敏感，但API返回可能混用
JSON标准不规定大小写，但Go的json.Unmarshal严格按json tag匹配。遇到API既返回user_id又偶尔返回userId，单靠tag搞不定。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
这时候不能硬扛，得在反序列化前统一处理原始字节流，或者用自定义UnmarshalJSON方法。
- 简单方案：用
bytes.ReplaceAll把"userId"替换成"user_id"再解析（仅限明确知道哪些字段会乱写） - 稳妥方案：给结构体实现
UnmarshalJSON([]byte)，里面手动查键名，兼容userId、user_id、USER_ID - 注意：如果用了
omitempty，反序列化时字段不存在会设为零值，不是保持原值——这点和yaml不同
用json.RawMessage跳过中间解析，避免字段名冲突
当结构体字段名和JSON键名撞车（比如都有id字段），或者某段JSON结构不确定、要延迟解析，json.RawMessage是唯一不触发自动转换的类型。
它把一段JSON原样存成[]byte，不碰字段名，也不校验格式，等到真要用时再json.Unmarshal一次。
- 声明字段：
Data json.RawMessage `json:"data"` - 后续解析：
var v map[string]interface{}; json.Unmarshal(user.Data, &v) - 坑点：如果
Data在JSON里是null，RawMessage会是nil切片，直接Unmarshal会panic，得先判空 - 性能上比直接解析两层结构略慢，但换来了灵活性，适合Webhook、第三方API等不可控场景
字段名这事看着小，但一旦涉及多个服务联调、历史字段兼容、前端约定，很容易卡住半天。最常被忽略的是导出规则和omitempty对空指针的处理逻辑——这两处一错，日志里根本看不出JSON哪丢了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
