gin的recovery中间件对json/protobuf解析失败无效，因其仅捕获panic，而解码错误返回error；需通过统一解析中间件（如bindjsonmiddleware）提前拦截并返回400错误，避免错误埋入业务层。
复杂数据转换（比如 JSON 解析、Protobuf 反序列化、结构体映射）出错时，不能靠 if err != nil 一层层手动兜底——它会把错误埋进业务逻辑深处，导致日志无上下文、错误码不收敛、前端无法区分是格式错还是字段缺。必须用框架级拦截机制统一收口。
为什么 Gin 的 recovery 中间件对转换失败完全无效
recovery 只捕获 panic，而 json.Unmarshal、proto.Unmarshal 这类操作失败时返回的是 error，不是 panic。你看到的 invalid character 或 unknown field 错误，根本不会触发 recovery。
- 常见现象：POST 一个非法 JSON，handler 里
json.NewDecoder(r.Body).Decode(&req)返回 error，但你没检查，后续直接用空 struct 访问字段 → 触发 nil dereference → 这时才 panic，且堆栈已丢失原始解析位置 - 真正该拦截的是「解码失败」本身，而不是它引发的二级 panic
- 别在每个 handler 里写重复的
if err != nil { c.AbortWithStatusJSON(...) }，既难维护又容易漏
Gin 中统一拦截请求体解析异常的实操方式
核心是把解码提前到中间件，失败就终止，不交给 handler。
- 定义统一解析中间件，例如
BindJSONMiddleware： - 在中间件中调用
c.ShouldBindJSON(&req)或手动json.NewDecoder(c.Request.Body).Decode()，失败立即c.AbortWithStatusJSON(400, ...) - 成功后把解析结果存到
c.Set("parsed_body", req)，handler 里用c.MustGet("parsed_body").(*MyRequest)取 - 注意：必须在路由注册前
r.Use(BindJSONMiddleware())，且顺序要在recovery之后（否则 panic 会打断中间件链） - 不要复用
c.Request.Body多次——HTTP Body 是流式读取，第二次读就是空。需要重放时用io.NopCloser(bytes.NewReader(buf))包装
gRPC 场景下 Protobuf 解包失败怎么透传原始错误码
Protobuf 反序列化失败（如字段类型不匹配、required 字段缺失）默认转成 status.Code = InvalidArgument，但客户端拿到的是 Unknown —— 因为 gRPC server 默认不校验，等业务逻辑用到字段时才 panic。
- 必须启用
grpc.UnsafeDisableUpstreamStreaming（不推荐）或更稳妥的做法：在UnaryServerInterceptor中提前调用proto.Unmarshal，捕获proto.Error后用status.Errorf(codes.InvalidArgument, "%v", err)显式返回 - 切记不要用
fmt.Errorf包装，否则客户端status.FromError(err)拿不到codes.InvalidArgument - 如果用了自定义错误类型（如
*AppError），需在 interceptor 中判断并转成status.Error，否则会被序列化成Unknown - 流式 RPC（
stream）要单独配StreamServerInterceptor，否则第一个消息解析失败就会断连
容易被忽略的跨层错误污染点
从 HTTP 层接收到的错误，经 service 层、DAO 层再抛回，很容易变成多层 errors.Wrap 堆叠。最终日志里看到的是「failed to create user: failed to insert into db: pq: duplicate key」，但前端只关心最外层是 409 还是 500。
- 业务层不该用
fmt.Errorf("xxx: %w", err)无差别包装，而是根据错误类型做分类：数据库唯一约束 →status.Errorf(codes.AlreadyExists, ...)；网络超时 →status.Errorf(codes.Unavailable, ...) - HTTP 中间件里统一用
status.FromError(err)解包，再映射到 HTTP 状态码：codes.InvalidArgument → 400，codes.NotFound → 404，codes.Internal → 500 - 日志记录时别只打
err.Error()，要加status.Convert(err).Message()和status.Convert(err).Code()，否则查问题时分不清是客户端错还是服务崩了
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
