不会直接崩溃主程序，但未recover的panic会终止该goroutine并打印错误日志，主程序继续运行；需用channel（如chan error）将错误传回主线程，避免竞态。
goroutine 里 panic 会直接崩溃主程序吗
不会自动崩溃，但也不会被上层捕获——panic 在 goroutine 内部发生时，若没用 recover 拦截，会终止该 goroutine，并把 panic 信息打印到 stderr（带 stack trace），主程序继续运行。这是常见误解的根源：以为“没崩”就等于“安全”，其实错误已被吞掉，调用方完全不知情。
典型现象：go func() { panic("oops") }() 执行后程序看似正常，但日志里突然冒出一行 panic trace，上游逻辑却收不到任何失败信号。
- 必须显式处理：要么在 goroutine 内用
defer+recover捕获并转为错误值 - 要么避免在 goroutine 里 panic，改用返回
error - 标准库如
http.Server的 handler 就是后者——它要求 handler 函数自己处理错误，不依赖 panic
怎么把 goroutine 的 error 传回主线程
靠 channel 最直接：定义一个 chan error，goroutine 执行完把结果（或错误）发进去，主线程用 select 或 <font color="red">recv</font> 等待。别用全局变量或闭包赋值——竞态风险高，且无法判断是否已写入。
示例：
立即学习“go语言免费学习笔记（深入）”；
errCh := make(chan error, 1)
go func() {
errCh <- doSomething()
}()
// 主线程阻塞等待
if err := <-errCh; err != nil {
log.Println("failed:", err)
}- channel 容量至少为 1，防止 goroutine 因发送阻塞而卡死
- 如果可能有多个 goroutine，用带缓冲的 channel +
for range，或用sync.WaitGroup配合单个error变量（需加锁） - 注意超时：用
select包一层，避免无限等待
使用 errgroup.Group 时 error 被覆盖怎么办
errgroup.Group 的 Go 方法只保留第一个非 nil 错误，后续错误全丢弃。这在并发请求场景下很危险——比如调用 3 个下游服务，第二个失败了，第三个也失败了，但你只能看到第二个的错误。
原因在于它的内部实现是原子写入首个错误，不聚合。
- 如果需要所有错误，别用
errgroup，改用sync.WaitGroup+ 切片收集error - 或者封装一层：每个 goroutine 把
error发到统一的chan error，主线程收集全部再判断 - 注意
errgroup.WithContext的 cancel 行为：任一子任务出错，context 会被 cancel，其他还在跑的 goroutine 可能提前退出——这不是错误覆盖，是主动中止
defer + recover 在 goroutine 中为什么有时不生效
最常见原因是 recover 放错了位置：它必须和 panic 在同一个 goroutine，且必须在 defer 函数里调用。如果 recover 写在另一个函数里、或 defer 没包住 panic 路径，就完全无效。
错误写法：
go func() {
defer safeRecover() // safeRecover 里写了 recover()，但没 return，也没输出
panic("boom")
}()正确写法：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("recovered in goroutine: %v", r)
}
}()
panic("boom")
}()-
recover()只在 defer 函数中有效，且仅对当前 goroutine 的 panic 生效 - recover 后不处理或不记录，等于白写——错误信息仍丢失
- 不要在 defer 里再 panic，除非你明确要向上传播，否则会掩盖原始 panic
真正难的是设计错误传播路径：goroutine 不是函数调用栈，它天生异步、隔离。错误要出来，得靠显式通道、共享状态或 context 取消，没有“自动向上抛”的机制。这点和同步代码完全不同，容易被忽略。
