Go的json.Marshal对nil指针字段默认跳过，既不输出键也不输出null；需通过自定义类型实现MarshalJSON方法（如NullableString）才能输出"field": null。
Go struct字段为nil指针时，JSON默认不输出该字段
Go 的 json.Marshal 对 nil 指针字段默认直接跳过，既不序列化为 null，也不输出键名。这不是 bug，是标准库的明确行为：它把 *T(nil) 当作“零值未设置”，等同于未赋值的字段。
常见错误现象：json.Marshal 后发现本该存在的字段彻底消失，前端收不到 "field": null，连 key 都没了；调试时打印 struct 看起来字段是 <nil></nil>，但 JSON 里根本找不到它。
- 使用场景：API 响应需显式区分“未提供”（省略）和“明确为空”（
null），比如 PATCH 接口、表单部分更新、与 TypeScript 的undefined/null语义对齐 - 根本原因：Go 的 JSON 包对指针类型的零值判断逻辑是
v.IsNil()，然后直接跳过，不走MarshalJSON流程 - 参数差异：没有开关控制全局行为，必须逐字段或逐类型干预
用omitempty标签不能解决nil指针输出null的问题
omitempty 是反向操作——它让非零值才出现，而你恰恰需要的是“零值（nil）也要出现并为 null”。加了 omitempty 只会让 nil 字段更彻底地消失。
正确做法是去掉 omitempty，并确保字段本身参与编码。但光这样还不够，因为默认指针 nil 仍被跳过。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 典型错误写法：
Field *string `json:"field,omitempty"`→ 字段彻底消失 - 正确起点：
Field *string `json:"field"`（无omitempty），但还需额外处理 - 性能影响：无额外开销；兼容性无问题，所有 Go 版本一致
给指针字段实现MarshalJSON方法是最可靠的方式
覆盖默认行为的唯一通用手段，就是让该指针类型自己决定怎么序列化。不是给 struct 加方法，而是给底层指针类型（如 *string）加，但 Go 不允许为内建类型别名以外的类型定义方法，所以得包装一层。
实操建议：为需要精确控制的字段定义新类型，并实现 MarshalJSON。
type NullableString struct {
*string
}
func (n NullableString) MarshalJSON() ([]byte, error) {
if n.string == nil {
return []byte("null"), nil
}
return json.Marshal(n.string)
}
- 使用场景：用户模型中
Nickname允许显式设为空，需返回"nickname": null - 注意点：必须用嵌入
*string而非string，否则无法保持原始语义；解码时仍可用原生*string接收（只要没自定义UnmarshalJSON） - 容易踩的坑：忘了导出字段名（
string小写 → 无法序列化）、返回json.Marshal(nil)（会 panic）
用json.RawMessage或第三方库属于权衡选择
如果项目已用 gjson 或大量动态 JSON 处理，json.RawMessage 可临时绕过，但它是延迟序列化，不解决结构体字段语义问题；easyjson 或 go-json 等高性能库默认行为一样，仍需手动干预。
-
json.RawMessage示例：Field json.RawMessage `json:"field"`，然后手动赋值json.RawMessage([]byte("null"))—— 灵活但易错，不适合常规字段 - 第三方库如
mapstructure或copier不改变 JSON 编码逻辑，别指望它们自动修复nil指针行为 - 真正容易被忽略的点：HTTP handler 中直接
json.NewEncoder(w).Encode(v)和json.Marshal行为完全一致，别以为换写法就能绕过
