在 Go 中，即使结构体定义良好，json.Marshal 仍可能因自定义 MarshalJSON 方法、循环引用、不支持类型或 nil 指针等问题返回错误；忽略该错误违背 Go 的显式错误处理原则，存在隐蔽运行时风险。
在 go 中，即使结构体定义良好，`json.marshal` 仍可能因自定义 `marshaljson` 方法、循环引用、不支持类型或 nil 指针等问题返回错误；忽略该错误违背 go 的显式错误处理原则，存在隐蔽运行时风险。
Go 的 encoding/json 包设计遵循“显式优于隐式”的哲学，json.Marshal 的签名 func Marshal(v interface{}) ([]byte, error) 明确表明它是一个可能失败的操作——无论输入结构体看似多么简单或“安全”。虽然对纯字段结构体（如仅含基础类型、无自定义方法）的序列化在多数场景下确实不会出错，但这不构成可忽略错误的充分理由。
⚠️ 错误可能发生的典型场景
-
自定义 MarshalJSON 方法主动返回错误
只要类型实现了 json.Marshaler 接口（即定义了 MarshalJSON() ([]byte, error) 方法），json.Marshal 就会调用该方法。开发者可在其中插入任意逻辑，包括条件性失败：func (e *Employee) MarshalJSON() ([]byte, error) { if e.Id == 0 { return nil, fmt.Errorf("invalid Employee ID: cannot be zero") } return json.Marshal(struct { ID int `json:"id"` }{ID: e.Id}) }此时 json.Marshal(&Employee{Id: 0}) 必然失败，且编译期无法检测。
嵌套结构中存在不可序列化字段
即使 Employee 本身干净，若其字段包含 func、chan、map[interface{}]interface{} 或未导出的非零值字段（且无自定义 marshaler），也会触发运行时错误。-
循环引用（如树形结构未正确处理）
type Node struct { Value int Parent *Node `json:",omitempty"` }若 Parent 形成环，json.Marshal 将返回 json: invalid recursive type Node 错误。
nil 指针或接口值为 nil
对 *Employee 为 nil 时调用 json.Marshal 会返回 null（合法），但若嵌套 *time.Time 等类型且其为 nil，可能触发 panic 或错误（取决于具体实现和版本）。
✅ 正确实践：始终检查错误，但可合理封装
Go 社区共识是：绝不使用 _ 忽略 json.Marshal 的错误。这不是过度防御，而是维护程序健壮性的底线。不过可通过以下方式降低冗余：
-
封装可信赖的序列化函数（带 panic 或日志）：仅适用于绝对可控、无外部输入的内部场景（如配置序列化）：
func mustMarshal(v interface{}) []byte { b, err := json.Marshal(v) if err != nil { panic(fmt.Sprintf("JSON marshal failed: %v", err)) } return b } -
使用辅助函数统一处理错误（推荐用于业务代码）：
func writeJSON(w http.ResponseWriter, v interface{}) { w.Header().Set("Content-Type", "application/json") if err := json.NewEncoder(w).Encode(v); err != nil { http.Error(w, "Internal Server Error", http.StatusInternalServerError) log.Printf("JSON encode error: %v", err) } }
? 总结
json.Marshal 的错误返回不是理论上的“可能性”，而是实际工程中必须应对的现实。依赖“结构体简单=永不失败”是一种危险假设，会掩盖由重构（如新增 MarshalJSON）、依赖升级或数据污染引发的静默故障。Go 的错误处理机制正是为了让你在问题发生时明确知道、明确响应——而非在生产环境凌晨三点排查一个本可编译期捕获的 500 Internal Server Error。坚持检查错误，既是语言约定，更是专业素养的体现。
