必须在echo.New()后立即调用e.Use(middleware.Recover())，否则panic会导致goroutine终止、HTTP连接挂起、前端无响应；该中间件是Echo唯一能捕获runtime panic的全局兜底机制，且仅能注册一次。
必须在echo.New()后立即调用e.Use(middleware.Recover())
不加这句，线上任何panic都会直接终止 goroutine，HTTP 连接挂起，前端收不到响应，日志里往往只剩一行 stack trace。这不是偶发问题，是上线即高危的配置缺失。
middleware.Recover() 是 Echo 唯一能捕获 runtime panic 的中间件；e.HTTPErrorHandler 完全不接管 panic，它只处理框架层错误（比如 c.JSON() 序列化失败）。
- 顺序不能错：必须在
echo.New()之后、任何路由注册之前调用e.Use(middleware.Recover()) - 不能依赖自定义
HTTPErrorHandler来兜住 panic - 开发期可设
e.Debug = true查看详细堆栈，但生产环境必须关掉 - 如果用了自定义
http.Server，还要确保server.ErrorLog配置到位，否则 panic 日志可能被静默丢弃
别在子分组或路由级重复注册Recover
Recover 是全局兜底机制，不是按业务域划分的功能中间件。在 e.Group("/api") 或某个 e.GET() 上再调一次 Use(middleware.Recover()) 不仅无效，还可能干扰正常错误传播链。
3-Tier Auto-Backup Daily Snapshots, Drive Mirror & Emergency Recovery
下载
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
- 一个 Echo 实例只需且只能注册一次
middleware.Recover() - 嵌套分组（如
e.Group("/v1").Group("/users")）不会继承或覆盖 recover 行为，但重复注册会浪费资源并增加调试复杂度 - 若需不同 panic 处理逻辑（如管理后台暴露堆栈、API 接口返回统一错误），应通过自定义
Recover回调实现，而非多实例注册
生产环境要配好Recover的回调函数
默认 middleware.Recover() 只打印 stack trace 到标准错误，不记录日志、不返回结构化响应，也不触发告警。线上服务必须显式定制行为。
立即学习“go语言免费学习笔记（深入）”；
- 用
middleware.RecoverWithWriter()指定日志输出目标（如zap.L().Desugar()封装的io.Writer） - 传入自定义
recoveryFunc，在 panic 捕获后做关键动作：记录 error ID、上报监控、返回c.JSON(500, ...) - 避免在回调里执行耗时操作（如调用外部 API），防止阻塞 HTTP worker
- 不要在回调中再次 panic —— 这会导致 recover 失效，连接彻底挂死
Recover 不能替代业务层防御性编程
它只解决“程序崩溃”，不解决“业务出错”。handler 里没校验参数、DB 查询失败没判空、map 访问前没检查 key 存在……这些都不会触发 panic，但会导致 500 或脏数据。
-
c.Bind()和c.Validate()只做结构合法性检查，不是业务守门员 - 字段存在 ≠ 业务合法（例如邮箱格式对，但已被注册）
- 跨字段校验（如 password / confirm_password 一致性）必须在 service 层完成
- recover 日志里看到
reflect.Value.Interface: panic或invalid memory address，大概率是 handler 直接用了未初始化指针或 nil map
Recover 后仍遇到“前端卡死”，最后发现是写在了 e.Group(...).Use(...) 里，或者被某个封装函数悄悄覆盖掉了。它不报错，只是沉默失效。 
