c.error()仅将错误加入c.errors队列，不中断执行、不设置状态码、不发送响应；真正返回错误需用c.abortwithstatusjson()或c.abortwitherror()，且统一错误中间件须置于router.use()链末尾。
c.Error() 不会中断执行，也不发送 HTTP 响应
很多人以为调用 c.Error() 就等于返回了错误，结果客户端收不到任何数据，甚至拿到空 200。这是因为 c.Error() 只是把 error 追加进 c.Errors 切片，供后续中间件（比如日志、监控）消费，它完全不碰响应体、不设状态码、不终止 handler 流程。
- 如果你在 handler 里写
c.Error(fmt.Errorf("invalid id"))后又执行c.JSON(200, data)，最终响应仍是 200 + data，错误被彻底掩盖 -
c.Errors是按顺序追加的，c.Errors.Last()通常是你业务层最后抛出的那个，适合做“最终错误判定” - 想让错误真正生效，必须显式调用
c.AbortWithStatusJSON()或c.AbortWithError()
panic 和业务错误必须用不同方式捕获
Gin 默认的 gin.Recovery() 中间件只捕获主 goroutine 的 panic，并返回空白 500 页面——它不走你的错误格式，也不调用 c.AbortWithStatusJSON()。而业务错误（如参数校验失败、资源未找到）根本不会触发 panic，gin.Recovery() 对它们完全无感。
- 必须禁用默认 recovery：用
gin.New()替代gin.Default()，再手动注册自定义 recovery 中间件 - 异步 goroutine（如
go func() {}()）里的 panic 不会被任何 Gin 中间件捕获，必须在子 goroutine 内部defer/recover - 业务错误靠
c.Error()+ 统一中间件兜底；panic 靠自定义recover()拦截——两者不能混用一套逻辑
ShouldBind 和 BindJSON 的错误行为差异极大
c.BindJSON() 在类型不匹配时（比如 JSON 传 "id": "abc"，结构体字段是 int），会静默跳过该字段，导致结构体字段为零值，后续逻辑可能 panic 或返回错误结果；而 c.ShouldBind() 会在类型转换失败时明确报错，且错误信息可解析。
- 永远优先用
c.ShouldBind()，它不自动 abort，给你控制权去构造统一错误响应 -
c.Bind()系列方法（BindJSON、BindQuery）一旦失败，会直接调用c.AbortWithError(400, err)，但错误格式不可控，且无法区分是类型错还是校验错 - 若需精确识别 “字符串传给 int 字段” 这类问题，得先用
json.Unmarshal解析到map[string]interface{}，再逐字段校验类型
统一错误中间件必须放在 router.Use() 链的末尾
中间件执行顺序决定谁“最后说话”。如果你把统一错误处理中间件写在 gin.Logger() 或鉴权中间件前面，后者仍可能覆盖响应——比如鉴权中间件调用了 c.AbortWithStatusJSON(401, ...)，你的中间件就再也拿不到错误了。
- 务必确保它是
router.Use()中最后一个注册的中间件 - 中间件内必须用
c.AbortWithStatusJSON()，而不是c.JSON() + c.Abort()；后者可能被后续中间件再次修改响应头或 body - 错误映射要分层：用
errors.Is(err, ErrNotFound)匹配哨兵错误，而不是字符串匹配，避免文案微调导致逻辑失效
c.Error()（记录）、不调 c.JSON()（响应）的习惯——控制权必须收束到一处，否则错误格式永远无法真正统一。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
