panic会中断程序执行，但可通过defer中的recover捕获并恢复，避免崩溃；在HTTP中间件中使用recover可防止单个请求panic导致服务终止；recover仅在当前goroutine有效，需在每个可能panic的协程内单独设置；不应滥用recover，仅用于处理不可控的异常情况，如第三方库错误或插件执行，常规错误应使用error处理。
在Go语言中，panic 是程序遇到无法继续执行的错误时触发的机制。它会中断正常流程并开始堆栈展开，逐层退出函数调用。但通过 recover，可以在 defer 函数中捕获 panic，实现安全恢复，避免程序崩溃。
理解 defer 和 recover 的协作机制
recover 只能在 defer 修饰的函数中生效。当 panic 发生时，被 defer 的函数会被执行，此时调用 recover 可以阻止 panic 继续向上蔓延。
基本模式如下：
func safeRun() { defer func() { if r := recover(); r != nil { log.Printf("recovered: %v", r) } }() panic("something went wrong") }在这个例子中，程序不会崩溃，而是打印错误信息后继续执行后续代码。
立即学习“go语言免费学习笔记（深入）”；
在 HTTP 服务中安全处理 panic
Web 服务常使用 recover 避免单个请求导致整个服务中断。典型做法是在中间件中封装 recover 逻辑。
示例：
func recoverMiddleware(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { defer func() { if r := recover(); r != nil { log.Printf("panic: %v\n", r) http.Error(w, "Internal Server Error", 500) } }() next(w, r) } }这样即使某个处理函数 panic，也能返回 500 错误，而不是让服务器退出。
JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也
避免滥用 recover
recover 不应作为常规错误处理手段。只在以下场景考虑使用：
- 第三方库可能引发 panic，而你无法控制其行为
- 必须保证服务长期运行（如后台守护进程）
- 执行不可信代码（如插件系统）
对于可预期的错误，应使用 error 返回值处理。recover 应用于“异常”而非“错误”。
注意 recover 的作用范围
recover 只能恢复当前 goroutine 的 panic。如果在新 goroutine 中发生 panic，外层的 defer 无法捕获。
正确做法是每个可能 panic 的 goroutine 内部都设置 recover：
go func() { defer func() { if r := recover(); r != nil { log.Println("goroutine panic recovered:", r) } }() // 可能 panic 的操作 }()否则，未捕获的 panic 会导致整个程序退出。
基本上就这些。合理使用 recover 能提升程序健壮性，但关键在于明确边界：只在必要时恢复，且恢复后应记录上下文以便排查问题。
