抓取新数据的快慢，多半卡在入口那一层

采集任务跑起来，CPU 闲着，带宽也闲着，进度条就是不动——这画面见得太多。抓取新数据这件事，真正慢的地方常常不在你手里那台机器上，而在你和数据源之间那道入口：域名解析、连接建立、认证换取、限流放行，每一道都要时间，串起来就是你感觉到的慢。

抓取新数据，慢的往往不是采集程序

采集程序本身消耗真不算大。解析响应、正则匹配、写库，这些都是本地 CPU 干的活，机器加一档基本就压下去了。可要是慢在入口，加多少台机器都只是几十个线程一起干等。等的样子还各不相同：等 DNS 回包、等 TLS 握手、等 token、等限流窗口、等源站把游标翻到下一页。表现倒是一致——进程活着，没产出。

土办法最好使：在采集机上开个终端，单独请求同一个地址，看首字节什么时候到。首字节迟迟不来，锅多半不在代码里。

入口那一层到底指什么

从一个请求发出，到第一块数据回到你手上，中间至少经过这么几段：DNS 解析、TCP 连接、（HTTPS 时）TLS 握手、请求发出、源站或它前面的 CDN 与网关排队校验、首个字节回传。哪一段堵住，后面全等。入口层就是前面这几段，跟你的数据库、解析函数关系不大。

不少人对入口的理解只停在带宽，带宽只是传输那一段。带宽再足，一次握手来回几十到几百毫秒，成千上万个短连接叠起来就是一笔大账，跨境、跨运营商时更明显。具体差多少，得看链路，别拿别人的数当自己的。

短连接和握手，最容易白等的地方

每个请求新开一条连接，是最顺手的写法，也是最常见的坑。TCP 要握手，TLS 还要再来一轮，证书链一长、算法一换，成本又不一样。链路越远，这笔开销越扎眼。

能复用就复用。HTTP/1.1 的 keep-alive、HTTP/2 的多路复用、客户端里的连接池，都是干这个的。把连接池大小调到跟并发匹配，比换机器管用得多。反过来，池子开太大，入口那头先被你的并发打到限流，反而更慢。

限流和认证，入口上的两道闸

源站不欢迎高频访问，这是常态，不是刁难。单 IP 的 QPS 上限、短时间窗口内的计数、可疑 UA 拦截、验证码挑战，基本都在入口做。你这边看到的现象是请求忽然变慢，或者返回 429、403，代码里一点异常都抓不到。

认证同样占时间。有些接口要先换 token 再调，有效期短，采集进程就得反复去换，每换一次都是一趟完整往返。能不能缓存、能不能批量换、有没有长效凭证，先看接口文档和服务商说明，别自己猜。

出口 IP 也算入口的一部分。整段 IP 被拉黑的时候，换个 IP 池，成功率就忽高忽低。这跟采集框架写得好不好没半点关系。

分页和游标，藏在源站那边的慢

抓列表数据，越往后翻越慢，很多人第一反应是自己网络不行。实际是源站那边的分页实现：偏移量越深，要扫的行越多，回第一页的时间自然长。换成游标分页、按更新时间做增量，比猛加并发有效。

这条严格讲是源站慢，但它就发生在入口，你能做的只有换拉法、缓存没变化的部分、把大任务切小。

用分段计时把锅分清

别凭感觉。curl 就够用：curl -w “dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n” -o /dev/null -s https://目标地址 —— 这串数把 DNS、连接、TLS、首字节、总耗时分开摆出来。哪一段占大头，就改哪一段，别一上来就换高配。

多采几个样本，不同时段、不同目标各来几次。入口的问题经常是波动的，单次看不出来。在日志里给每段打点也行，至少能分清是在等连接还是在等首字节。

调整顺序，从入口往回收

顺序大概是：先确认哪一段慢，能复用连接就复用，然后控制并发、加退避重试，再看限流规则，降频率或者分散出口，接着把认证凭证缓存住，最后才是改抓取逻辑和加机器。反过来做，钱花了，问题还在。

还有一条容易被忘：数据不是拉得越多越好。全量重跑一遍，大量时间耗在那些根本没变的内容上。能按更新时间增量拉、能靠哈希比对跳过的，先把这个做上，入口压力立刻下去一截。

下次进度条不动，先别急着下单加配置。开个终端，把 DNS、连接、TLS、首字节的耗时一段段量出来，答案多半就藏在那几个数字里，剩下的才轮到改代码。