gin.recovery()不返回json错误响应，因为它仅打印panic堆栈并调用c.abort()中止请求，既不写响应体、也不设状态码或调用c.abortwithstatusjson()，前端收到的是gin内部兜底生成的{"error":"internal server error"}而非可控json。
为什么 gin.Recovery() 不返回 JSON 错误响应
因为 gin.Recovery() 只做两件事：调用 log.Printf 打印 panic 堆栈，然后调用 c.Abort() 中止请求——它**不写响应体、不设状态码、不调用 c.JSON() 或 c.AbortWithStatusJSON()**。你看到的 {"error": "Internal Server Error"} 是 Gin 内部兜底逻辑写的，不是你可控的响应。
这意味着：前端 fetch 会收到 500 状态码但空 body，超时卡住；日志里有堆栈，但用户和监控系统得不到结构化错误信息。
- 别用
gin.Default()，它自动注册了这个“半残” recovery - 改用
gin.New()+ 手动注册自定义中间件 - 确保你的 recovery 中间件在所有业务中间件之后注册（比如在
auth、logger之后）
自定义 Recovery 中间件必须包裹 c.Next() 才生效
panic 必须发生在 c.Next() 执行期间，recover() 才能捕获到。常见失效场景是：defer 写晚了、c.Next() 漏写、或 panic 出现在 c.Next() 之前（比如解包空指针、强制类型断言失败）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
defer必须紧贴函数入口，写在c.Next()之前 -
recover()必须放在defer的匿名函数内部，不能拆成独立函数调用 - 如果用了
gin.BasicAuth或其他前置中间件，确保CustomRecovery在它们之后注册，否则 panic 可能发生在 recovery 作用域外
c.AbortWithStatusJSON() 和 c.JSON() + c.Abort() 的区别
c.AbortWithStatusJSON(500, data) 是原子操作：设状态码、写 JSON body、调用 c.Abort() 阻断后续中间件。而 c.JSON(500, data) + c.Abort() 是两步，中间可能被其他中间件覆盖或重复写响应。
- 用
c.AbortWithStatusJSON()，不要分开写 - 别在 recover 后调
c.Next()或继续执行 handler 逻辑——panic 已发生，流程必须终止 - 生产环境响应体必须脱敏：
err.(type)判断后统一返回泛化提示，禁用原始fmt.Sprintf("%v", err)
异步 goroutine 中的 panic 无法被中间件捕获
Gin 的 recovery 中间件只作用于 HTTP 请求主 goroutine。你在 go func() { ... }() 里触发的 panic，完全绕过中间件，直接导致整个进程崩溃（K8s 重启、告警轰炸）。
- 绝对避免在 goroutine 里调
c.JSON()、c.String()等操作响应的方法 - 真要异步，必须在 goroutine 内部自己加
defer+recover()，并单独记录日志或上报监控 - 别指望一个中间件“一劳永逸”——goroutine 是独立调度单元，异常处理边界必须对齐
c.Next() 调用链内；任何跳出这个边界的 panic，都得靠各自 goroutine 自己兜底。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
