本文详解如何使用 goroutine 工作池模式替代无节制的并发 http 请求，通过固定 worker 数量、正确关闭响应体、统一错误处理和资源管控，彻底解决因 socket 耗尽导致的 tcp 错误与文件描述符泄漏问题。
本文详解如何使用 goroutine 工作池模式替代无节制的并发 http 请求，通过固定 worker 数量、正确关闭响应体、统一错误处理和资源管控，彻底解决因 socket 耗尽导致的 tcp 错误与文件描述符泄漏问题。
在 Go 中并发抓取大量网站时，常见误区是为每个 URL 启动一个 goroutine（如原代码中 go func(url string) { ... }(url)），这极易引发系统级资源瓶颈：未限制并发数 → 瞬间建立数百 TCP 连接 → 耗尽文件描述符（too many open files）、触发 dial tcp: lookup failed 或 i/o timeout 等 TCP 层错误。根本原因并非“没调用 resp.Body.Close()”（原代码已调用），而在于缺乏并发控制机制——即使单个请求正确释放资源，海量并发仍会压垮操作系统网络栈。
✅ 正确方案是采用 Worker Pool（工作池）模式：预设固定数量的 goroutine（如 10 个），共享消费任务队列，实现可控、可扩展、资源友好的并发模型。
以下是重构后的核心逻辑（关键改进点已标注）：
// 1. 定义工作池大小（建议 5–20，依目标站点响应延迟与服务器负载调整）
const workerCount = 10
// 2. 启动固定数量 worker，每个 worker 循环从任务索引中取 URL
for w := 0; w < workerCount; w++ {
go func() {
for {
// 原子化获取下一个待抓取 URL 索引（线程安全）
requestMu.Lock()
i := requestCount
requestCount++
requestMu.Unlock()
if i >= len(seedUrls) {
return // 所有任务完成，worker 退出
}
url := seedUrls[i]
fmt.Printf("Worker %d fetching: %s\n", w, url)
// 3. 发起 HTTP 请求（推荐使用自定义 http.Client 控制超时）
client := &http.Client{
Timeout: 10 * time.Second,
}
resp, err := client.Get(url)
if err != nil {
fmt.Printf("❌ %s: %v\n", url, err)
data <- &HTTPResponse{URL: url, HTML: "", Err: err}
continue
}
// ✅ 必须立即关闭 Body —— 即使后续读取失败也需保证
defer resp.Body.Close() // 注意：此处 defer 在 goroutine 内生效，但更推荐显式 close（见下文说明）
// 4. 安全读取响应体（避免 ioutil.ReadAll 的内存风险，推荐 io.CopyN 或 streaming）
body, err := io.ReadAll(resp.Body)
if err != nil {
fmt.Printf("⚠️ %s: read body failed: %v\n", url, err)
data <- &HTTPResponse{URL: url, HTML: "", Err: err}
continue
}
data <- &HTTPResponse{URL: url, HTML: string(body)}
}
}()
}
// 5. 主协程接收结果（确保接收全部 len(seedUrls) 条结果）
for i := 0; i < len(seedUrls); i++ {
select {
case result := <-data:
emails := findEmails(result.HTML, filters)
row := []string{result.URL, strings.Join(emails, ",")}
if err := writer.Write(row); err != nil {
log.Fatalf("CSV write error: %v", err)
}
writer.Flush() // 及时刷盘，避免缓冲区溢出
}
}? 关键注意事项与最佳实践：
- resp.Body.Close() 必须显式调用：defer resp.Body.Close() 在 goroutine 中有效，但更推荐在 io.ReadAll 后立即调用 resp.Body.Close()（而非 defer），避免因 panic 或提前 return 导致遗漏。
-
禁用 http.DefaultClient 的默认连接复用陷阱：生产环境应创建自定义 http.Client 并配置 Transport，例如限制最大空闲连接数：
transport := &http.Transport{ MaxIdleConns: 10, MaxIdleConnsPerHost: 10, IdleConnTimeout: 30 * time.Second, } client := &http.Client{Transport: transport} - 避免正则表达式过度匹配邮箱：当前 emailRE 易产生误报（如匹配 "contact@us"）。建议改用成熟库如 mailparser 或结合 HTML 解析器（如 golang.org/x/net/html）提取 <a href="mailto:..."> 链接。
- 错误处理需区分类型：网络错误（net.OpError）、DNS 失败（*net.DNSError）、HTTP 状态码（如 403/429）应分类记录，便于后续重试或限流策略。
- CSV 写入需加锁或使用 channel 序列化：原代码中多个 goroutine 同时调用 writer.Write() 是非线程安全的。工作池模式下由主 goroutine 单独写入，天然规避此问题。
总结：高并发 HTTP 客户端的健壮性不取决于“是否关闭 Body”，而在于整体架构设计——固定 worker 数、可控连接复用、明确生命周期管理、防御性错误处理。遵循此模式，即可稳定支撑数千 URL 的批量解析任务，同时保障系统资源可持续性。
