Go 的 error 接口默认不支持 JSON 序列化，直接传递 []error 会导致空对象或无效输出；需自定义类型实现 json.Marshaler，兼顾标准错误字符串与自定义错误的结构化 JSON 表达。
go 的 error 接口默认不支持 json 序列化，直接传递 `[]error` 会导致空对象或无效输出；需自定义类型实现 `json.marshaler`，兼顾标准错误字符串与自定义错误的结构化 json 表达。
在 Go Web 开发中（例如使用 Gin 框架），常需将校验失败的错误列表以 JSON 格式返回给客户端（如 HTTP 状态码 422 Unprocessable Entity）。但直接将 []error 写入 c.JSON() 会得到类似 {"errors":"[{}]"} 的异常结果——这是因为 Go 的 error 是接口类型，而标准库的 encoding/json 不会自动调用 Error() 方法，也不识别未实现 json.Marshaler 的错误值，最终导致空序列化或 panic。
根本原因在于：json.Marshal() 对接口值（如 error）仅尝试调用其 MarshalJSON() 方法（若存在），否则按底层具体类型处理；而 errors.New() 创建的 *errors.errorString 并未实现该方法，且 []error 本身也不是可直接 marshal 的基础类型。
✅ 正确解法是定义一个可序列化的错误切片包装类型，并显式实现 json.Marshaler：
import "encoding/json"
type JSONErrs []error
func (je JSONErrs) MarshalJSON() ([]byte, error) {
res := make([]interface{}, len(je))
for i, e := range je {
if m, ok := e.(json.Marshaler); ok {
res[i] = m // 使用自定义 MarshalJSON
} else {
res[i] = e.Error() // 回退到字符串表示
}
}
return json.Marshal(res)
}
使用时只需将原始 []error 转换为 JSONErrs：
errList := person.Validate()
c.JSON(422, gin.H{"errors": JSONErrs(errList)})
? 进阶优势：该设计天然支持混合错误类型。例如，你可定义带上下文的结构化错误：
type ValidationError struct {
Field string `json:"field"`
Msg string `json:"message"`
Code int `json:"code"`
}
func (e ValidationError) Error() string { return e.Msg }
func (e ValidationError) MarshalJSON() ([]byte, error) {
return json.Marshal(struct {
Field string `json:"field"`
Msg string `json:"message"`
Code int `json:"code"`
}{e.Field, e.Msg, e.Code})
}
此时 JSONErrs{errors.New("basic"), ValidationError{"name", "required", 1001}} 将被序列化为：
["basic", {"field":"name","message":"required","code":1001}]
⚠️ 注意事项：
- 不要使用
[]string替代[]error后再转 JSON —— 这会丢失错误类型的语义和扩展能力（如嵌套、字段携带、HTTP 状态映射等）； - 若错误类型实现了
UnmarshalJSON，也建议一并实现以保持双向一致性（虽本场景通常只需序列化）； - Gin 的
c.JSON()内部调用json.Marshal()，因此上述JSONErrs可无缝集成，无需修改框架逻辑。
通过这一模式，你既能保持 Go 错误处理的惯用风格，又能为 API 提供清晰、灵活、符合 REST 规范的错误响应格式。
