recover中间件必须包裹c.next()才能生效，panic仅在c.next()执行期间发生才被捕获；前置中间件需在recovery之后注册，goroutine内panic需单独defer recover处理，且panic不等于业务错误，应区分使用。
recover中间件必须包裹c.Next()才能生效
panic只有在c.Next()执行期间发生，才会被defer里的recover()捕获。常见错误是把c.Next()写在defer外面、漏写、或放在recover逻辑之后——这时panic直接穿透，服务崩溃。
正确结构只有一种顺序：
- 先
defer func()定义recover逻辑 - 紧接着调用
c.Next() - panic只能出现在
c.Next()之后的handler链中（比如路由函数、业务逻辑里）
如果前置中间件（如gin.BasicAuth）抛panic，而Recovery注册顺序靠前，它就捕获不到——务必确保Recovery在所有可能panic的中间件之后注册。
goroutine内panic不会被外层recover捕获
HTTP handler里起的goroutine（比如异步发消息、延迟清理）一旦panic，外层Recovery中间件完全无感。这是最常被忽略的盲区。
必须单独处理：
- 每个goroutine入口手动加
defer func(){ recover() }() -
recover()后必须调用debug.Stack()，仅fmt.Sprint(r)会丢失堆栈位置 - 捕获后应上报监控（如Prometheus的
error_count计数器）+ 写日志，不能静默吞掉
别指望一个中间件管住所有goroutine——它们是独立的执行单元，recover作用域不跨协程。
http.Error和c.AbortWithStatusJSON行为差异
两者都终止响应，但语义和后续流程不同：
-
http.Error(w, msg, code)：直接写入ResponseWriter并结束HTTP流程，Gin中间件链继续执行（c.Next()之后的逻辑仍可能跑） -
c.AbortWithStatusJSON(code, data)：写响应 + 调用c.Abort()，强制中断中间件链，后续c.Next()不再执行
混用会导致响应格式不一致（比如有时返回纯文本，有时返回JSON），前端解析失败。如果你已定义统一Response结构体，就坚持只用c.AbortWithStatusJSON；裸net/http项目才用http.Error。
panic不是业务错误，不该用来表达校验失败
把panic("user_id is empty")当错误提示是反模式。panic代表程序级崩溃（nil解引用、切片越界、map未初始化写入），业务错误应该走error返回路径。
真正值得recover的panic极少：
- 第三方库内部不可控panic（比如模板渲染时
reflect.Value.Interface()崩溃） - 底层API调用触发的未预期崩溃（如
unsafe操作失败） - 运行时环境异常（极少）
日常参数校验、DB记录不存在、权限不足——全该返回AppError或类似封装错误，由中间件统一转成JSON响应。recover不是兜底，而是最后防线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
