不该 panic；应返回 HTTP 400 错误、记录脱敏日志、用 json.RawMessage 分层解析、校验必填字段、避免 silent fail、处理 float64 精度丢失。
json.Unmarshal 返回 error 时，到底该不该 panic
绝大多数新手会直接 if err != nil { panic(err) }，这在 CLI 工具或测试中看似省事，但在线上服务里等于把解析失败变成 500。真实场景中，JSON 来自用户输入、第三方 API 或日志文件，字段缺失、类型错位、嵌套过深都极常见——json.Unmarshal 的 error 是预期内的业务异常，不是程序 bug。
- 用
http.Error(w, "bad request", http.StatusBadRequest)替代 panic，配合日志记录原始 payload（注意脱敏） - 对关键字段做防御性检查：比如先用
json.RawMessage解析顶层结构，确认type字段存在且合法，再分发到具体 struct - 避免在 defer 中 recover panic 来“兜底”——它无法区分是 JSON 错误还是 goroutine 崩溃
struct 字段 tag 写错导致 silent fail
Go 的 JSON 解析不会报错，但字段永远为零值。最常见的是拼写错误或大小写不匹配：json:"user_id" 对应 struct 字段 UserId int 没问题，但写成 UserID int 就失效（因为 Go 要求导出字段首字母大写，而 UserID 对应的 JSON key 是 "userID"，不是 "user_id"）。
- 统一用
json:"user_id,omitempty"，omitempty不影响解析，只控制序列化 - 用 IDE 的 struct tag 自动补全（如 GoLand 的 Alt+Enter），别手敲
- 对必填字段，在 unmarshal 后手动校验：比如
if req.Name == "" { return errors.New("name is required") }
嵌套对象解析失败却没提示具体路径
原生 json.Unmarshal 错误信息类似 json: cannot unmarshal string into Go struct field User.Age of type int，但如果你的 struct 有 5 层嵌套，根本不知道是哪个 User 实例出问题。这时候需要封装一层带上下文的解析。
func UnmarshalWithTrace(data []byte, v interface{}) error {
// 先用 json.RawMessage 解析顶层，获取 type 字段做路由
var raw map[string]json.RawMessage
if err := json.Unmarshal(data, &raw); err != nil {
return fmt.Errorf("parse root: %w", err)
}
// 再根据 raw["type"] 选择具体 struct，逐层解
return json.Unmarshal(data, v)
}
- 不要依赖第三方库自动加 path（如
gojsonq），它们通常牺牲性能换可读性 - 对高频接口，提前定义好
map[string]func() interface{}类型映射表，避免运行时反射 - 日志中打印前 100 字节的原始 data，比错误信息更有助于定位
float64 精度丢失和整数溢出的实际影响
JSON 标准没有整数/浮点区分，所有数字都按 float64 解析。当后端期望接收 int64 的 ID 字段，而前端传了 9223372036854775807（int64 最大值），Go 会先转成 float64，再转 int64——但 float64 无法精确表示所有 int64 值，导致末尾几位变成 0 或错误值。
立即学习“go语言免费学习笔记（深入）”；
- 对 ID、时间戳等敏感字段，强制用
json.Number：声明字段为ID json.Number，再用id.Int64()或id.Float64()显式转换 - 用
json.Decoder.UseNumber()全局启用，但注意后续所有数字字段都得手动转，否则 runtime panic - 前端传字符串 ID（
"1234567890123456789"）是最稳妥方案，后端用strconv.ParseInt处理
真正麻烦的不是语法错误，而是那些解析成功但值已失真的 case——它们潜伏在线上流量里，直到某天财务对账不平才被发现。
