Go中goroutine panic必须在内部用defer+recover捕获，recover仅在defer函数内有效；可预期错误应通过error channel传递，不可预期崩溃才用recover兜底并记录堆栈、清理后退出。
Go 中的 goroutine 一旦发生未捕获的 panic，会直接终止该协程，并且不会传播到主 goroutine，但若没做任何处理，panic 信息会打印到标准错误、程序可能看似“静默失败”，严重时还会引发资源泄漏或服务不可用。关键不是“能不能捕获”，而是必须在每个可能出错的 goroutine 内部主动设防。
用 defer + recover 捕获 panic
这是应对未知崩溃（比如空指针、越界、向已关闭 channel 发送数据）的唯一可靠方式。recover 只在当前 goroutine 的 defer 函数中有效，离开 defer 就失效。
- recover 必须写在 defer 函数里，且要直接调用（不能包在另一个函数里再调）
- 建议统一记录 panic 值 + 堆栈，方便排查：用
runtime.Stack获取完整调用链 - 不要在 recover 后继续执行高风险逻辑，通常只做日志、告警、清理，然后退出
用 error channel 传递业务错误
对于可预期的错误（如网络超时、校验失败、数据库查不到），应避免 panic，改用 error 类型 + channel 回传。这是 Go 并发错误处理的推荐模式。
- 创建带缓冲的 error channel（容量 ≥ goroutine 数量），防止发送阻塞导致 goroutine 卡住
- 主 goroutine 通过
range或select接收错误，配合sync.WaitGroup等待全部完成 - 多个任务中只要一个失败就要中断其余？那就结合
context.WithCancel，出错时调用 cancel()
封装安全启动函数
重复写 defer+recover 很繁琐，可以抽象成工具函数，让并发更健壮、更一致。
- 定义
goSafe(func())，内部自动包裹 recover 日志逻辑 - 可扩展支持传入 logger、trace ID、超时控制等上下文信息
- HTTP handler、定时任务、消息消费等入口处默认用 goSafe 启动子协程
别踩这些坑
很多 goroutine 错误问题其实源于设计疏忽，而不是语法不会用。
- 主 goroutine 的 defer 永远捕获不到子 goroutine 的 panic —— 这是常见误解
- 向已关闭的 channel 发送数据会 panic，读已关闭 channel 是安全的（返回零值+false）
- 不要用 recover 替代 error 处理：正常业务流程出错就该返回 error，不是抛 panic
- recover 后不加日志、不释放资源、也不退出，容易掩盖问题并引发状态不一致
基本上就这些。核心就两条：可预期的错走 error channel，不可预期的崩靠 defer+recover 守住底线。两者不冲突，常一起用。
