Go 的 json.Unmarshal 本身不 panic，真正触发 panic 的是手动 panic(err) 或对零值/nil 字段非法解引用；防范核心是源头拦截：用 http.Error 返回 400、校验必填字段、使用指针类型区分空值、分段解析定位错误、启用 DisallowUnknownFields 和 json.Valid 预检。
Go 的 json.Unmarshal 本身不会 panic，真正触发 panic 的，几乎都是你手动写的 panic(err)，或者后续对零值/nil 字段的非法解引用（比如 *req.Name 而 req.Name == nil）。防范的核心不是“捕获 panic”，而是从源头掐断 panic 的路径。
别在 handler 里写 if err != nil { panic(err) }
这是最常见、也最危险的习惯。HTTP handler 是用户输入的第一道门，json.Unmarshal 失败是业务常态——字段缺失、类型错位、嵌套过深、UTF-8 损坏，全都在预期范围内。
- 用
http.Error(w, "bad request", http.StatusBadRequest)直接返回 400，而不是让整个 goroutine 崩溃 - 记录原始 payload（注意脱敏），比如只记前 200 字节 + 字段名，别把用户手机号全打日志里
- 别依赖
recovery中间件兜底：它只抓 panic，而解析失败返回的是error，根本进不去 recovery
结构体字段 tag 写错导致静默失败
json.Unmarshal 不报错不等于成功。字段名拼错、大小写不一致、没导出（首字母小写），都会让对应字段永远为零值，后续逻辑一用就 panic。
- 检查
json:"user_id"对应的 struct 字段是否是UserId int（正确）还是UserID int（错误，因为后者映射 JSON key 是"userID"） - 用 IDE 自动补全 tag（如 GoLand 的
Alt+Enter），别手敲 - 必填字段解析后必须手动校验：
if req.Name == "" { return errors.New("name is required") }
用指针字段区分 “未提供” 和 “提供了空值”
非指针字段（string、int）无法区分 JSON 里字段缺失、字段为 null、字段为 "" 或 0 —— 全都变成零值，容易误判。
立即学习“go语言免费学习笔记（深入）”；
- 改用
*string、*int64：解析{"name":"bob"}后req.Name != nil；解析{"name":null}后req.Name == nil -
omitempty只影响序列化，不影响反序列化行为，放心加 - 访问前务必判空：
if req.Age != nil && *req.Age > 120，别直接写*req.Age
嵌套解析失败时定位不到具体路径
原生错误信息像 json: cannot unmarshal string into Go struct field User.Age of type int，但如果你的 struct 有 User 数组、Profile 嵌套、Settings map[string]interface{}，根本不知道是哪个实例、哪个层级出的问题。
- 用
json.RawMessage分段解析：先解顶层type字段，再按类型分发到不同 struct - 对关键字段单独解码：
json.Unmarshal(data["config"], &config)，错误范围立刻缩小 - 启用
DisallowUnknownFields()：提前拦截字段名拼写错误，避免静默丢弃 - 对用户输入，先调
json.Valid(data)快速预检，避免解析器卡在断裂 JSON 上
最易被忽略的一点：HTTP Body 只能读一次。中间件里解析完，handler 里再读就是空的——需要重放时得用 io.NopCloser(bytes.NewReader(buf)) 包装，否则你会看到 “unexpected end of JSON input” 这种毫无上下文的错误。
