error 是可预期、可恢复的业务失败结果，作为函数返回值需显式检查；panic 是程序不可继续时的紧急终止机制，触发后默认崩溃goroutine，recover仅用于顶层兜底而非替代error。
error 和 panic 不是“两种错误处理方式”，而是两类根本不同性质的信号：一个是业务流程中可预期、可检查、可恢复的失败结果；另一个是程序已陷入不可继续状态的紧急终止指令。
error 是函数返回的“合法结果”
它本质是一个接口值，只要实现了 Error() string 方法，就能当 error 用。Go 鼓励把可能出问题的操作设计成“多返回值函数”，显式带一个 error 出来：
- 调用方必须主动判断 if err != nil，不检查就编译通过但逻辑危险
- error 可以层层向上传递，中间层可以加 context（如用 fmt.Errorf("read header: %w", err)）
- 适合文件打开失败、网络超时、JSON 解析错误、用户输入校验不通过等——这些情况程序完全能继续跑
panic 是运行时触发的“程序熔断”
它不是函数返回值，而是一种控制流中断机制，像踩下急刹，立刻停止当前 goroutine 的执行，并开始执行已注册的 defer 函数：
- 由运行时自动触发（如数组越界、nil 指针解引用、map 并发写），也可由开发者手动 panic("xxx")
- 除非在 defer 中调用 recover()，否则一定会导致当前 goroutine 崩溃，最终整个程序退出
- 适用场景极窄：启动失败（配置加载错、DB 连不上）、严重逻辑矛盾（本该非空却为 nil）、或测试中故意触发验证兜底逻辑
recover 只是 panic 的“事后补救”，不是 error 替代品
recover() 必须在 defer 函数里调用才有效，它的作用不是“把 panic 当成普通错误处理”，而是做最后的资源清理或日志记录：
- recover 后程序能继续执行，但 panic 发生点之后的代码已跳过，上下文可能已损坏
- 绝不该用 recover 来掩盖本该用 error 处理的业务失败（比如把“用户密码错误” panic 再 recover，属于严重误用）
- 真实服务中，recover 通常只放在最外层 HTTP handler 或 goroutine 起始处，防止单个请求崩溃整个服务
基本上就这些。记住一句话：error 是流程的一部分，panic 是流程的终结者。
