Go 默认的 http.Get 不设超时，若网络延迟或目标不可达，请求会无限阻塞，导致协程挂起、爬虫整体停滞；必须显式配置 http.Client 的 Timeout 字段来保障程序健壮性。
go 默认的 `http.get` 不设超时，若网络延迟或目标不可达，请求会无限阻塞，导致协程挂起、爬虫整体停滞；必须显式配置 `http.client` 的 `timeout` 字段来保障程序健壮性。
在构建高并发网络爬虫时，未受控的 HTTP 请求超时是导致程序“静默挂起”（即无 panic、无日志、goroutine 卡死）的常见原因。你描述的现象——连续 20+ 次 CSS 资源请求超时后程序停止响应——并非控制台日志丢失，而是由于 http.Get 底层复用了默认的 http.DefaultClient，而该客户端的 Timeout 字段为零值（0），意味着无限等待。一旦某个资源（如第三方 CDN 托管的 CSS）长期无响应，对应 goroutine 将永久阻塞，若所有工作协程均陷入此类状态，主流程便无法继续消费任务通道，整个爬虫实质上“冻结”。
正确做法是：始终使用自定义 http.Client 并显式设置 Timeout。该超时涵盖连接建立、TLS 握手、请求发送与响应头读取全过程（即“全周期超时”）。示例代码如下：
package main
import (
"fmt"
"net/http"
"time"
)
func fetchWithTimeout(urlStr string) (*http.Response, error) {
client := &http.Client{
Timeout: 10 * time.Second, // 推荐 5–30 秒，根据业务容忍度调整
}
return client.Get(urlStr)
}
func main() {
sites := []string{
"https://example.com",
"https://bad-cdn.example/css/style.css", // 可能超时的资源
}
for _, site := range sites {
resp, err := fetchWithTimeout(site)
if err != nil {
fmt.Printf("❌ 请求失败 (%s): %v\n", site, err)
continue // 错误处理后继续，不中断流程
}
defer resp.Body.Close()
fmt.Printf("✅ 请求成功 (%s): %d\n", site, resp.StatusCode)
}
}⚠️ 关键注意事项：
- Timeout 是硬性截止时间，不可分段配置（如单独设连接超时或读取超时需改用 Transport）；
- 若需更精细控制（例如连接超时 3s + 读取超时 15s），应构造自定义 http.Transport 并赋值给 Client.Transport；
- defer resp.Body.Close() 必须在确认 err == nil 后调用，否则可能 panic；
- 在并发场景中，建议将 client 实例复用（而非每次新建），它本身是并发安全的；
- 超时错误类型为 *url.Error，其 Err 字段常为 net/http: request canceled (Client.Timeout exceeded)，可据此做针对性日志或重试策略。
总结：Go 的 HTTP 客户端设计强调显式性——没有默认超时，等于没有安全保障。将 http.Client{Timeout: ...} 作为爬虫基础组件纳入初始化流程，是避免“悄无声息挂起”的第一道也是最关键的防线。
