如何使用Go语言recover防止爬虫任务意外终止-Golang-PHP中文网

recover必须在每个可能panic的goroutine内部用defer调用才有效，仅捕获本协程panic，跨goroutine无效；需配合显式资源清理与前置校验，不可替代错误处理。

如何使用go语言recover防止爬虫任务意外终止

recover 在爬虫 goroutine 中根本不起作用？

直接在启动爬虫的 goroutine 里 defer recover() 是无效的——Go 的 recover() 只对**当前 goroutine 内 panic** 生效，且必须在 defer 中调用。如果爬虫逻辑在子 goroutine（比如 go crawlPage(url)）里 panic，主 goroutine 的 recover() 完全捕获不到。

常见错误写法：

go func() {
    defer recover() // ❌ 这里 recover 永远不执行，因为 panic 发生在别的 goroutine
    crawlPage("https://example.com")
}()

正确做法是：每个可能 panic 的 goroutine 内部，自己做 defer recover()。

如何给每个爬虫 goroutine 加上独立 recover

把 recover 包裹成可复用的“安全执行器”，避免重复写 defer 模板。关键点是：recover 后别吞掉错误，至少要 log；同时确保 panic 不扩散、不阻塞调度。

用匿名函数封装，传入实际任务函数和参数
recover() 必须紧跟在 defer 后，且不能被 if/else 等打断
恢复后建议 sleep 短暂时间（如 time.Sleep(100 * time.Millisecond)），避免高频 panic 导致 CPU 打满
不要在 recover 里重试原任务——那可能造成无限 panic 循环

示例：

func safeGo(f func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("panic recovered: %v", r)
                time.Sleep(100 * time.Millisecond)
            }
        }()
        f()
    }()
}

调用：safeGo(func() { parseHTML(resp.Body) })

GitHub Actions Retry Recovery Audit

审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。

下载

哪些地方最容易 panic 导致爬虫崩掉

不是所有 panic 都来自业务逻辑，很多源于 HTTP 和 HTML 处理的边界情况。这些地方不加 recover，一次异常就 kill 整个 goroutine：

json.Unmarshal(nil, &v) → panic: "invalid memory address"
doc.Find("div.item").Each(...) 中 doc 为 nil（比如 goquery.NewDocumentFromReader(nil)）
resp.Body.Read(...) 前没检查 resp == nil || resp.Body == nil
正则匹配空字符串：regexp.MustCompile("").FindStringSubmatch(...) 不 panic，但 MustCompile 传空串会直接 panic
并发 map 写：多个 goroutine 同时写一个未加锁的 map[string]int