Go 的 json.Marshal 遇到 nil 指针字段默认输出 null；需加 omitempty 标签才省略，但仅判断字段是否为零值，不穿透检查嵌套内容；反序列化时 null 赋给非指针类型会 panic，应优先用指针接收。
Go 的 json.Marshal 遇到 nil 指针会输出 null
当你把一个结构体字段声明为指针（比如 *string），而该字段值是 nil，json.Marshal 默认会把它序列化成 JSON 的 null，而不是跳过它或报错。
这很常见，但容易误以为“字段没传就该消失”，其实不是——只要字段在 struct 里定义了，且类型是指针，nil 就对应 null。
- 如果想让
nil指针字段完全不出现，得加omitempty标签：json:"name,omitempty" -
omitempty对指针有效，但对零值非指针类型（如int、string）也生效，这点容易混淆 - 注意：
omitempty不影响顶层nil指针变量本身——比如你传json.Marshal((*MyStruct)(nil))，会直接 panic，错误是json: Marshal(nil *MyStruct)
反序列化时 json.Unmarshal 对 null 的处理逻辑
JSON 中的 null 反序列化到 Go 指针字段时，会把对应指针设为 nil；但如果目标字段是非指针类型（比如 string），就会报错：json: cannot unmarshal null into Go value of type string。
这是最常踩的坑：前端传了个 {"name": null}，后端用 type User struct { Name string } 接收，直接炸。
立即学习“go语言免费学习笔记（深入）”；
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 安全做法是统一用指针字段接收可能为 null 的字段：
Name *string - 如果必须用非指针类型，得自定义
UnmarshalJSON方法，或用第三方库（如github.com/mitchellh/mapstructure）做宽松解析 - 空对象（
{}）和null是两回事：{}表示对象存在但字段全缺，null表示那个字段明确为空——反序列化时前者会让指针保持nil（如果没显式赋值），后者也会设为nil，但语义不同
嵌套结构中指针字段的 omitempty 行为陷阱
当结构体嵌套，且内层字段是指针，omitempty 不会“穿透”判断内层是否真有值。它只看当前字段是否为零值（对指针就是是否为 nil），不关心 nil 指针指向的对象本身有没有意义。
比如：type Req struct { Data *Inner `json:"data,omitempty"` }，即使 Data 指向一个 &Inner{Field: ""}（所有字段都是零值），只要 Data != nil，data 字段仍会出现在 JSON 中，内容是 {"field":""}。
- 想实现“深层空则省略”，得手动在
MarshalJSON里判断内层字段是否全为零 - 别依赖
omitempty来隐藏业务上的“无效对象”，它只认 Go 的零值规则 - 测试时容易漏掉这种 case：用
new(Inner)初始化再赋值为零值，结果发现字段还在 JSON 里
接口字段（interface{}）与指针混用时的反序列化风险
如果你用 map[string]interface{} 或 interface{} 接收未知结构，JSON 中的 null 会被解成 Go 的 nil，但它的类型是 <nil></nil>，不是 *string 或其他具体指针类型。
后续如果强制类型断言为 *string，会 panic：panic: interface conversion: interface {} is nil, not *string。
- 务必先用
if v != nil判断，再做类型断言 - 更稳妥的方式是用
json.RawMessage延迟解析，或者用json.Unmarshal直接进具体结构体 - 别在
interface{}上做指针解引用操作——它根本不知道自己是不是指针
