Gin需手动组合recover()和c.Error()实现全局异常处理：禁用默认gin.Recovery()，自建recover中间件并置于Use链首位，调用c.AbortWithStatusJSON()终止流程；c.Error()仅存错需配c.Abort()，统一响应中间件应置于倒数第二位，解析失败等非panic错误须前置拦截。
直接说结论：Gin 没有“开箱即用”的全局异常处理，必须手动组合两套正交机制——recover() 捕获 panic，和 c.Error() 注入业务错误，再由中间件统一消费。只做其中一种，必然漏掉一半错误。
panic 恢复必须自己写中间件，不能用 gin.Recovery()
默认的 gin.Recovery() 只打印日志、返回空白 500 页面，不调用 c.AbortWithStatusJSON()，也不透出错误详情。它会抢在你自定义 recover 前吞掉 panic，导致你写的 defer 完全无效。
- 必须禁用默认 recovery：用
gin.New()替代gin.Default()，或显式调用r.Use()时不注册gin.Recovery() - 中间件要放在
r.Use()链最前面，确保它第一个执行（defer包住c.Next()） -
recover()后必须立刻调用c.AbortWithStatusJSON()，不能只写c.JSON()+c.Abort()，否则可能被后续中间件二次写响应 - 堆栈要用
debug.Stack()获取并记录，但绝不返回给前端；生产环境错误信息一律脱敏为固定字符串（如"internal server error"）
c.Error() 不等于报错，只是把错误塞进队列
很多人在 handler 里写 c.Error(errors.New("xxx")) 就以为客户端能收到响应，其实不会。它只是把错误推入 c.Errors 切片，完全不中断流程、不写 HTTP 响应体、不设状态码。
- 调用
c.Error()后必须显式c.Abort()或直接return，否则后续逻辑照常执行，可能造成重复响应或空 200 - 常见错误现象：
http: multiple response.WriteHeader calls或前端收不到任何 JSON - 参数校验、DB 查询失败、第三方调用超时等，都该走
c.Error()而非直接c.JSON(400, ...)，保持错误出口统一 - 建议预定义错误变量（如
var ErrValidation = errors.New("validation failed")），方便后续用errors.Is()分类
统一响应中间件必须放在所有业务中间件之后
这个中间件负责检查 c.Errors 并输出标准 JSON，但它必须在请求生命周期末尾执行，否则可能被后续中间件覆盖响应。
立即学习“go语言免费学习笔记（深入）”；
- 注册顺序很关键：应放在
r.Use()链的倒数第二位，紧挨着gin.Logger()之后、gin.Recovery()之前（如果你还留着它） - 核心逻辑是
c.Next()后立即判断len(c.Errors) > 0，然后取c.Errors.Last()（最新注入的通常是业务层错误） - 状态码要分层：HTTP 状态码（如
http.StatusNotFound）决定网关行为，业务 code（如10001）供前端识别，两者不能混用 - 别用
switch err.Error()做类型判断，脆弱且难测试；优先用errors.As()或类型断言提取自定义错误结构
JSON 解析失败这类错误，recover 根本捕不到
json.Unmarshal()、c.ShouldBindJSON() 失败返回的是 error，不是 panic。recovery 中间件对它们完全无效。这类错误必须提前拦截，不能等它流入业务逻辑。
- 必须写解析中间件（如
BindJSONMiddleware），在c.ShouldBindJSON(&req)失败时立刻c.AbortWithStatusJSON(400, ...) - 中间件注册顺序：要在
gin.Recovery()之后（否则 panic 会打断链路），但在所有业务 handler 之前 - HTTP Body 只能读一次，中间件里解码后若需在 handler 中再次使用，得用
io.NopCloser(bytes.NewReader(buf))包装重放 - gRPC 场景同理，Protobuf 解包失败也得在 interceptor 层提前捕获，用
status.Errorf()显式返回，不能等业务逻辑触发 panic
真正麻烦的不是写代码，而是错误出口的分散性：panic、c.Error()、c.AbortWithError()、c.ShouldBind 失败、甚至 panic 引发的二级 nil dereference —— 它们触发时机、上下文、可恢复性全都不一样。一个中间件不可能兜底全部，必须按类型分层拦截、按顺序排布位置、按语义统一渲染。
