task.run + httpclient 不能直接堆数量跑爬虫，因 httpclient 共享连接池且默认连接上限低（.net framework 为2、core/5+为10），盲目并发会触发 socketexception 或 connection refused。
为什么 Task.Run + HttpClient 不能直接堆数量跑爬虫
因为 HttpClient 不是线程安全的实例，但更关键的是：它内部共享连接池，盲目开几百个 Task.Run 会迅速打满连接数、触发 SocketException: Too many open files 或 HttpRequestException: Connection refused。默认连接池上限（ServicePointManager.DefaultConnectionLimit）在 .NET Framework 是 2，在 .NET Core/5+ 是 10，远低于你想象的“并发数”。
实操建议：
- 复用单个
HttpClient实例（推荐声明为static readonly或注入IHttpClientFactory） - 用
SemaphoreSlim控制并发请求数，别依赖线程数——HTTP 请求大部分时间在等响应，不是 CPU 密集型 - 设置合理的
Timeout和MaxConnectionsPerServer（通过HttpClientHandler配置） - 避免在循环里 new
HttpClient，否则 DNS 缓存不生效、TCP 连接无法复用
HttpClient 配合 SemaphoreSlim 的最小可靠写法
这是真正能控并发、防崩、可重试的组合。重点不是“多线程”，而是“可控并发 HTTP 请求流”。
示例逻辑（.NET 6+）：
private static readonly HttpClient _client = new HttpClient(new HttpClientHandler
{
MaxConnectionsPerServer = 100
});
private static readonly SemaphoreSlim _semaphore = new SemaphoreSlim(10, 10); // 最多 10 个并发请求
<p>public async Task<string> FetchAsync(string url)
{
await _semaphore.WaitAsync();
try
{
var response = await _client.GetAsync(url, CancellationToken);
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsStringAsync();
}
finally
{
_semaphore.Release();
}
}</string></p>
注意点：
-
SemaphoreSlim必须是static，否则每个实例都独立计数，失去限流意义 -
CancellationToken要传入GetAsync，否则WaitAsync被取消时，请求还在后台发着 - 别用
Task.WaitAll等待一堆Task.Run，改用Task.WhenAll等待FetchAsync返回的Task
遇到 429 / 503 / DNS timeout 怎么办
这不是代码写错了，是目标站点在反爬或限流。硬扛只会让请求全挂，得主动降频、错峰、伪装。
实操建议：
- 检查响应头：
response.Headers.RetryAfter存在就按它给的秒数 sleep，别自己瞎猜 - 对 429 响应统一加退避逻辑（比如指数退避
await Task.Delay(100 * (int)Math.Pow(2, retryCount))） - DNS 失败（
HttpRequestException内嵌SocketExceptionwith code 11001）大概率是并发太高被运营商 DNS 限速，加随机 delay 或换 DNS（如 8.8.8.8）没用，本质要降并发 - 别只靠 User-Agent 伪装，加上
Accept、Accept-Language、Referer才像真实浏览器请求
要不要用 Parallel.ForEach 或 PLINQ
不要。它们面向 CPU 密集型任务，而爬虫是 I/O 密集型。用 Parallel.ForEach 启动 100 个 GetAsync，等于同时发起 100 个网络等待，不仅不提速，还会压垮连接池和本地端口（TIME_WAIT 爆满）。
正确姿势只有两个：
- 用
Task.WhenAll+ 限流（如上SemaphoreSlim） - 用
IAsyncEnumerable<t></t>+Channel<t></t>做生产者-消费者模型，适合持续抓取、动态增减 URL 场景
真正的瓶颈从来不在“线程够不够”，而在“连接能不能复用”“请求有没有被限”“DNS 和 TLS 握手是否稳定”。把这三个点盯死，比调任何线程参数都管用。
