recover必须在defer函数中直接调用才有效，仅用于捕获同goroutine内未处理的panic；panic不是error替代品，仅适用于程序启动失败、断言失败等不可恢复错误，常规错误应返回error。
Go里没有try/catch，panic和recover不是替代error的常规错误处理手段，而是专用于不可恢复的严重故障或框架级防护——用错地方反而会让逻辑更难维护。
recover必须在defer函数里直接调用
recover()只在defer注册的匿名函数或命名函数内部有效，且必须是“直接调用”，不能包在另一层函数里。一旦写成defer func() { handleRecover() }()，而handleRecover里再调recover()，就失效了。
-
recover()返回nil时，说明没捕获到panic，常见原因是调用位置不对，或panic已传播出当前goroutine - 如果
defer注册在子函数里，但panic发生在更外层，recover依然能捕获——只要它还在同一goroutine内 - 别在循环里反复注册
defer func() { recover() }，这不会多捕获几次，只会白占资源
panic触发后defer仍会执行，但顺序容易误判
panic发生时，当前函数立即停止，但所有已注册的defer按“后进先出”顺序执行——注意，这个“注册顺序”是指defer语句出现的位置，不是执行位置。
- 参数在
defer声明时求值，比如defer fmt.Println(x)中x的值是defer那行代码执行时的快照，不是panic发生时的值 - 如果多个
defer都含recover()，只有最内层（即最后注册的那个）能真正捕获，其余返回nil - 不要依赖
defer里修改外部变量来“传递状态”，因为闭包捕获的是变量引用，不是值拷贝
HTTP中间件中recover的典型写法
Web服务里，单个请求panic不能让整个server挂掉，中间件里加defer+recover是最常见做法，但要注意日志、状态码、响应体的一致性。
立即学习“go语言免费学习笔记（深入）”；
- 必须在
http.HandlerFunc开头就注册defer，否则panic可能发生在中间件之后，无法拦截 -
recover()拿到的是interface{}，常用r.(string)或fmt.Sprint(r)转成可读字符串，避免类型断言失败崩溃 - 别只打印日志就完事，要明确返回
http.Error(w, "...", http.StatusInternalServerError)，否则客户端收不到响应 - 生产环境建议把panic堆栈写入结构化日志（如
zap），而不是仅靠debug.PrintStack()
什么时候该用panic，而不是return error
panic不是错误处理的快捷方式，它是“程序已经无法继续”的信号。滥用会导致调用方无法判断哪些路径可能中断，破坏接口契约。
- 适合场景：初始化失败（如配置加载异常）、不可恢复的约束违反（如空指针解引用、类型断言失败）、全局状态损坏
- 不适合场景：I/O失败、业务校验不通过、网络超时——这些都应该走
error返回路径 - 库作者尤其要谨慎：对外暴露的API尽量不用
panic，除非文档明确说明这是“断言式接口” - 测试中可以用
panic模拟极端情况，但生产代码里每处panic都应有对应recover兜底，或确保它真会终止进程
真正难的不是写对recover，而是判断哪里不该用panic——多数健壮性问题，根源不在异常捕获，而在边界没守好、错误没提前暴露。
