panic 和 recover 不是异常处理机制，而是应对不可恢复崩溃的紧急制动手段；它们不能替代 error，仅限初始化失败、HTTP 处理器兜底等少数场景使用。
panic 和 recover 不是 Go 的“异常处理机制”，而是用于应对真正不可恢复的崩溃场景的紧急制动与兜底手段。 它们不能替代 error 返回值，也不该出现在常规业务逻辑中——一旦滥用，会让错误流变得隐晦、难以调试、性能下降，甚至掩盖真正的 bug。
panic 是什么：不是“抛异常”，而是“程序已无法继续”
当 Go 遇到运行时错误（如 nil 指针解引用、切片越界、向已关闭 channel 发送数据）或你主动调用 panic() 时，当前 goroutine 立即停止执行，所有已注册的 defer 函数按后进先出顺序触发，然后 panic 向上蔓延。若无人拦截，进程退出并打印堆栈。
- 它不支持 try/catch 那样的嵌套捕获，也没有 finally 语义
-
panic的参数类型是interface{}，常见为string或error，但框架中建议统一用error方便后续处理 - 调用
os.Exit()会跳过所有defer和recover，它就是硬退出
recover 怎么用：必须在 defer 里，且只能捕获本 goroutine
recover() 只有在 defer 函数体内直接调用才有效；写在普通函数体里、或者 defer 中再套一层普通函数调用，都会失效。
- 它不会“修复”问题，只是让程序有机会做清理、记录日志、返回错误响应
- 每个 goroutine 的 panic 必须由自己内部的
defer+recover捕获；外层 goroutine 的recover对子 goroutine 的 panic 完全无效 - 典型错误写法：
defer func() { recover() }()—— 这能运行但永远捕不到，因为没接返回值；正确写法是if r := recover(); r != nil { ... }
什么时候该用：只限初始化失败、HTTP 处理器兜底等少数场景
90% 的错误都应该走 error 返回路径。只有当你确认“这个错误发生，程序就绝对不该再往前走一步”时，才考虑 panic。
