上個(gè)月我把一個(gè)跑了幾百個(gè)頁(yè)面的同步爬蟲腳本扔到服務(wù)器上等了大概四十多分鐘才出結(jié)果當(dāng)時(shí)我一度以為程序死了。后來(lái)拆開日志去看發(fā)現(xiàn)百分之九十幾的時(shí)間都卡在等待網(wǎng)絡(luò)響應(yīng)上CPU幾乎在摸魚。翻了很多資料試了各種寫法最終從單線程改到基于asyncio的異步方案同樣這批頁(yè)面從四十多分鐘直接跑進(jìn)十幾秒穩(wěn)定到我自己都不敢信。這篇就把這套寫法和場(chǎng)景下的完整代碼、優(yōu)化思路、遇到的坑一次講清楚希望幫你少走彎路。如果你現(xiàn)在的爬蟲還是老老實(shí)實(shí)一個(gè)請(qǐng)求等到返回再去發(fā)下一個(gè)請(qǐng)求那這篇文章大概率能幫你省下大把時(shí)間。無(wú)論是批量采集公開數(shù)據(jù)、做接口巡檢還是處理大量帶網(wǎng)絡(luò)請(qǐng)求的重復(fù)任務(wù)異步方案都有機(jī)會(huì)帶來(lái)數(shù)量級(jí)的提升。內(nèi)容會(huì)從異步的原理、環(huán)境準(zhǔn)備、完整代碼一直到反爬應(yīng)對(duì)和誤用陷阱盡量做到看完就能照著改。1. 為什么異步爬蟲能把速度拉高幾十倍事件循環(huán)才是核心1.1 爬蟲其實(shí)是一門等待的藝術(shù)做過(guò)爬蟲的都知道真正拖慢速度的不是解析數(shù)據(jù)不是寫文件而是網(wǎng)絡(luò)請(qǐng)求期間那段時(shí)間發(fā)一個(gè)請(qǐng)求出去然后干等著服務(wù)器響應(yīng)。這個(gè)等待時(shí)間里你的程序基本什么正事都沒(méi)干線程空轉(zhuǎn)CPU占用率低得可憐。我用單線程跑某個(gè)公開數(shù)據(jù)頁(yè)面時(shí)平均一個(gè)請(qǐng)求耗時(shí)大約 0.35 到 0.6 秒。你算一下1000 個(gè)頁(yè)面按照每個(gè) 0.5 秒算那就是 500 秒將近九分鐘。如果中間加個(gè)重試、加個(gè)限速時(shí)間直接翻倍。這也是很多人感覺同步爬蟲慢到窒息的根本原因——不是機(jī)器不如別人是等待網(wǎng)絡(luò)響應(yīng)的方式不對(duì)。很多人第一反應(yīng)是上多線程這個(gè)思路沒(méi)錯(cuò)但線程本身是有成本的。線程的創(chuàng)建、切換、銷毀都要消耗資源而且在 Python 里還有全局解釋器鎖GIL的問(wèn)題真正同時(shí)執(zhí)行的字節(jié)碼指令并沒(méi)有那么多。雖然爬蟲場(chǎng)景里網(wǎng)絡(luò)等待會(huì)讓出 GIL但大量線程的管理開銷依然不少。線程數(shù)百個(gè)之后調(diào)度切換的成本會(huì)讓你明顯感到力不從心。異步就不一樣了。它讓你在發(fā)起一個(gè)請(qǐng)求后立刻轉(zhuǎn)頭去發(fā)起下一個(gè)請(qǐng)求等哪個(gè)請(qǐng)求的響應(yīng)回來(lái)了再回頭繼續(xù)處理那個(gè)請(qǐng)求。這樣?個(gè)進(jìn)程就能同時(shí)維護(hù)幾百上千個(gè)進(jìn)行中的請(qǐng)求時(shí)間的利用率自然翻倍。1.2 事件循環(huán)一個(gè)人干一堆活的秘訣異步的核心是事件循環(huán)event loop。你可以把它想象成一個(gè)非常忙碌的餐廳服務(wù)員同時(shí)給好幾桌客人下單、傳菜、結(jié)賬靠的不是叫很多服務(wù)員一起上而是這一位服務(wù)員記住每張桌子的狀態(tài)哪個(gè)桌的菜好了就趕緊送過(guò)去哪個(gè)桌還要等就先去招呼別的桌。asyncio就是 Python 官方提供的事件循環(huán)實(shí)現(xiàn)。你在代碼里寫的async def函數(shù)會(huì)生成一個(gè)協(xié)程對(duì)象把協(xié)程提交給事件循環(huán)后事件循環(huán)會(huì)負(fù)責(zé)調(diào)度它們遇到await關(guān)鍵字就代表這里要等某個(gè) I/O 操作完成我可以先去做別的事。網(wǎng)絡(luò)響應(yīng)回來(lái)后事件循環(huán)再回到這個(gè)協(xié)程繼續(xù)往下執(zhí)行。這樣一來(lái)單進(jìn)程單線程就能同時(shí)并發(fā)處理非常多的請(qǐng)求。對(duì)于爬蟲這種典型的 I/O 密集型任務(wù)異步幾乎就是為它量身定做的方案。1.3 不是簡(jiǎn)單貼個(gè) async/await 就有用很多人看過(guò)異步教程但自己動(dòng)手寫爬蟲時(shí)發(fā)現(xiàn)也沒(méi)快多少原因是只學(xué)了語(yǔ)法沒(méi)理解模式。我見過(guò)有人寫這種代碼async def fetch_page(session, url): async with session.get(url) as resp: return await resp.text() for url in urls: fetch_page(session, url) # 這樣根本無(wú)法并發(fā)在 for 循環(huán)里逐個(gè)調(diào)用協(xié)程協(xié)程根本沒(méi)有交付給事件循環(huán)去調(diào)度效果跟同步差不多。正確的是要把所有協(xié)程包裝成 task 列表用asyncio.gather或asyncio.as_completed統(tǒng)一交給事件循環(huán)。理解了這一點(diǎn)后面給出的代碼才看得懂。一句話記住使用姿勢(shì)協(xié)程只是生成器交給事件循環(huán)調(diào)度才是異步。2. 性能實(shí)測(cè)數(shù)據(jù)單線程、多線程與異步的真實(shí)差距2.1 測(cè)試場(chǎng)景與條件說(shuō)明你說(shuō)1000 個(gè)頁(yè)面 12 秒極速抓完但不是隨口一句口號(hào)得有可復(fù)現(xiàn)的條件。這次實(shí)測(cè)我選取的是某個(gè)目標(biāo)站點(diǎn)的公開詳情頁(yè)每次并發(fā)請(qǐng)求之間設(shè)置了合理的間隔目標(biāo)頁(yè)面響應(yīng)時(shí)間約 150 到 300 毫秒測(cè)試機(jī)器是本機(jī)開發(fā)環(huán)境網(wǎng)絡(luò)帶寬穩(wěn)定在 100MPython 版本 3.10aiohttp版本 3.9。需要說(shuō)明的是不同目標(biāo)站點(diǎn)、不同網(wǎng)絡(luò)環(huán)境、不同服務(wù)器負(fù)載下成績(jī)必然不同。如果你的目標(biāo)站點(diǎn)本身要 2 秒才能返回那異步再厲害也變不出 12 秒。異步提升的是并發(fā)度和等待時(shí)間利用效率不是讓某個(gè)請(qǐng)求的響應(yīng)時(shí)間變莫測(cè)。2.2 三種方案跑同一批 1000 個(gè)頁(yè)面的對(duì)比我在同樣的 1000 個(gè)頁(yè)面上分別用同步、多線程、異步三種方案跑過(guò)數(shù)據(jù)和體感如下方案總耗時(shí)秒說(shuō)明同步 requests487一個(gè)接一個(gè)幾乎完全取決于單請(qǐng)求延遲多線程50 線程21有提升但線程切換和資源消耗明顯asyncio aiohttp200 并發(fā)12.6事件循環(huán)調(diào)度單進(jìn)程資源占用極低這個(gè) 12.6 秒是在默認(rèn)不加額外限速策略的情況下跑出來(lái)的。如果你把并發(fā)數(shù)再降低一點(diǎn)或者加上更保守的限速與重試退避耗時(shí)會(huì)長(zhǎng)一些比如 200 并發(fā)左右跑到 15 到 20 秒都正常。實(shí)際項(xiàng)目里我不建議一上來(lái)就把并發(fā)拉滿先測(cè)出目標(biāo)站點(diǎn)的承受能力再?zèng)Q定并發(fā)值。2.3 12 秒背后的限制因素很多人會(huì)問(wèn)既然異步這么強(qiáng)為什么不是一秒跑完其實(shí)關(guān)鍵限制不在客戶端而在幾個(gè)方面TCP 連接建立與 TLS 握手即使復(fù)用連接池初次建連和加密握手依然有固定開銷。目標(biāo)服務(wù)器處理能力和帶寬服務(wù)器響應(yīng)我們單個(gè)請(qǐng)求也需要時(shí)間和資源并發(fā)太高會(huì)觸發(fā)限流甚至封禁?？蛻舳说谋镜刭Y源比如句柄數(shù)、內(nèi)存、DNS 解析速度。合理的采集頻率限制實(shí)踐里要尊重目標(biāo)站點(diǎn)正常服務(wù)能力不能一味追求極限。所以說(shuō)1000 個(gè)頁(yè)面 12 秒是一個(gè)在特定條件下的理論最好成績(jī)而不是一個(gè)到處適用的承諾。這套代碼的價(jià)值在于它讓并發(fā)能力掌握在你手里你可以按目標(biāo)情況調(diào)并發(fā)數(shù)在速度和穩(wěn)定性之間找平衡。3. 環(huán)境準(zhǔn)備與工具選型aiohttp 比重寫整個(gè)網(wǎng)絡(luò)層靠譜3.1 最小依賴清單跑這套異步方案不需要裝一大堆重型框架我用到的核心庫(kù)就這幾個(gè)Python 3.9推薦 3.10 或以上aiohttp提供異步 HTTP 客戶端相關(guān)能力asyncioPython 標(biāo)準(zhǔn)庫(kù)直接內(nèi)置aiodns異步 DNS 解析減少解析等待lxml或BeautifulSoup4解析頁(yè)面用按需安裝安裝命令很簡(jiǎn)單pip install aiohttp aiodns lxml beautifulsoup4如果你用 Windowsaiodns偶爾有兼容問(wèn)題裝不上也不用慌aiohttp 會(huì)退回普通的線程 DNS 解析性能略降但功能正常。3.2 為什么不用 requests concurrent.futures之前我就是用requests配合concurrent.futures.ThreadPoolExecutor做多線程爬蟲的跑起來(lái)體感也不錯(cuò)。但問(wèn)題在于requests是同步庫(kù)一個(gè)請(qǐng)求在等待期間雖然會(huì)讓出 GIL但每個(gè)請(qǐng)求還是占一個(gè)線程線程多了內(nèi)存占用和調(diào)度切換都不好看。換成aiohttp之后一個(gè)進(jìn)程里跑幾百個(gè)并發(fā)請(qǐng)求都還游刃有余。它不是把requests換成異步就完事了而是通過(guò)事件循環(huán)統(tǒng)一調(diào)度連接池復(fù)用也更順手。因此實(shí)際項(xiàng)目里我更傾向于 aiohttp。3.3 第一次跑通的最小骨架在給完整代碼前先寫一個(gè)最樸素的異步請(qǐng)求骨架感受一下事件循環(huán)的流程import asyncio import aiohttp async def fetch_one(session, url): async with session.get(url) as resp: return await resp.text() async def main(): async with aiohttp.ClientSession() as session: html await fetch_one(session, https://httpbin.org/) print(len(html)) asyncio.run(main())這串代碼其實(shí)已經(jīng)包含了事件循環(huán)、協(xié)程、請(qǐng)求會(huì)話三個(gè)關(guān)鍵概念。asyncio.run(main())創(chuàng)建并運(yùn)行事件循環(huán)session.get是真正的異步請(qǐng)求方法await resp.text()表示等待響應(yīng)體讀取完。如果這串在你的環(huán)境運(yùn)行正常說(shuō)明 aiohttp 和 asyncio 都健在接下來(lái)就可以直接上并發(fā)邏輯了。4. 核心代碼實(shí)戰(zhàn)1000 個(gè)頁(yè)面并發(fā)抓取的完整實(shí)現(xiàn)4.1 先設(shè)計(jì)架構(gòu)再寫代碼寫異步爬蟲不是簡(jiǎn)單把所有函數(shù)都改成async def而是要梳理任務(wù)流程用asyncio.Semaphore控制最大并發(fā)數(shù)防止把目標(biāo)站點(diǎn)打掛。用同一個(gè)ClientSession復(fù)用連接池和請(qǐng)求頭。把每個(gè) URL 封裝成一個(gè)抓取任務(wù)。通過(guò)asyncio.gather提交所有任務(wù)。每個(gè)任務(wù)內(nèi)部具備重試、異常處理等兜底邏輯。下面這份代碼就是按照這個(gè)思路寫的我在自己項(xiàng)目里多次使用過(guò)直接復(fù)制后替換 URL 列表即可運(yùn)行。4.2 完整代碼import asyncio import logging import random import time from urllib.parse import urlparse import aiohttp logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) logger logging.getLogger(__name__) # 目標(biāo)頁(yè)面列表按實(shí)際需求替換 URLS [ https://httpbin.org/html for _ in range(1000) ] HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, } SEMAPHORE_COUNT 200 # 并發(fā)控制數(shù) RETRY_TIMES 3 # 請(qǐng)求失敗重試次數(shù) BASE_DELAY 1 # 重試基礎(chǔ)退避時(shí)間秒 async def fetch_with_retry(session, url, semaphore, retry_timesRETRY_TIMES): 帶信號(hào)量控制和重試機(jī)制的抓取任務(wù)。 async with semaphore: for attempt in range(1, retry_times 1): try: async with session.get(url, timeout10) as response: if response.status 200: return await response.text() elif response.status in (429, 503): retry_after response.headers.get(Retry-After) wait_time int(retry_after) if retry_after else BASE_DELAY * attempt logger.warning(收到 %s等待 %.1f 秒后重試, response.status, wait_time) await asyncio.sleep(wait_time) else: logger.warning(請(qǐng)求 %s 返回狀態(tài) %s, url, response.status) except (aiohttp.ClientError, asyncio.TimeoutError) as exc: logger.error(第 %s 次請(qǐng)求 %s 失敗%s, attempt, url, exc) # 指數(shù)退避 隨機(jī)抖動(dòng)避免同時(shí)重試風(fēng)暴 sleep_time BASE_DELAY * (2 ** (attempt - 1)) random.uniform(0, 0.5) if attempt retry_times: await asyncio.sleep(sleep_time) return async def batch_fetch(urls, headersNone, semaphore_countSEMAPHORE_COUNT): 批量抓取入口返回 url - 頁(yè)面內(nèi)容的字典。 semaphore asyncio.Semaphore(semaphore_count) results {} async with aiohttp.ClientSession(headersheaders or HEADERS) as session: tasks { url: asyncio.create_task(fetch_with_retry(session, url, semaphore)) for url in urls } for url, task in tasks.items(): results[url] await task return results async def main(): start time.perf_counter() page_data await batch_fetch(URLS) elapsed time.perf_counter() - start success_count len([v for v in page_data.values() if v]) failed_count len(page_data) - success_count logger.info(總請(qǐng)求數(shù)%d成功%d失敗%d總耗時(shí)%.2f 秒, len(page_data), success_count, failed_count, elapsed) if __name__ __main__: asyncio.run(main())4.3 代碼里每個(gè)關(guān)鍵選擇的理由并發(fā)控制用的是asyncio.Semaphore(200)。信號(hào)量像一個(gè)門禁限制最多同時(shí)有 200 個(gè)協(xié)程在真正發(fā)請(qǐng)求。如果你不加信號(hào)量一口氣把 1000 個(gè)任務(wù)全丟給事件循環(huán)短時(shí)間內(nèi)會(huì)同時(shí)建立大量連接目標(biāo)服務(wù)器很容易返回 429 或直接斷連。ClientSession必須放在async with里。session 內(nèi)部維護(hù) TCP 連接池和 cookie 信息用同一個(gè) session 發(fā)請(qǐng)求能復(fù)用連接減少建連開銷。如果你每個(gè)請(qǐng)求都新建 session異步優(yōu)勢(shì)會(huì)大打折扣TCP 握手和 TLS 握手都會(huì)重復(fù)執(zhí)行。我的 fetch 函數(shù)里用了退避重試機(jī)制參考了很多優(yōu)化實(shí)踐中的思路第一次失敗后等 1 秒多第二次等 2 秒多第三次等 4 秒多并加入隨機(jī)抖動(dòng)避免所有任務(wù)在同一個(gè)時(shí)間點(diǎn)重試導(dǎo)致服務(wù)器雪崩。重試策略不是無(wú)限重試三次到頭就放棄防止某個(gè)已失效的頁(yè)面拖慢整體進(jìn)度。4.4 如何運(yùn)行與看結(jié)果代碼默認(rèn) URL 是 1000 個(gè)重復(fù)的 httpbin 頁(yè)面這是為了跑通而準(zhǔn)備的。真實(shí)項(xiàng)目中你把URLS替換成實(shí)際采集地址列表即可。運(yùn)行python async_spider.py日志會(huì)輸出總請(qǐng)求數(shù)、成功數(shù)、失敗數(shù)和總耗時(shí)。如果你想看到每個(gè)頁(yè)面的正文可以把results[url]寫進(jìn)文件或數(shù)據(jù)庫(kù)。跑完這個(gè)流程你就擁有一個(gè)最小可用的異步爬蟲底座后面加 URL 去重、頁(yè)面解析、入庫(kù)都是水到渠成的事。5. 反反爬實(shí)戰(zhàn)從 UA 池到限速策略不靠對(duì)抗靠規(guī)范5.1 反爬機(jī)制到底在防什么反爬聞起來(lái)像技術(shù)對(duì)抗本質(zhì)上其實(shí)是一套風(fēng)險(xiǎn)控制系統(tǒng)防止機(jī)器行為影響服務(wù)器穩(wěn)定、防止頻繁訪問(wèn)拖垮數(shù)據(jù)庫(kù)、防止惡意采集和重復(fù)注冊(cè)。理解了目標(biāo)是在保護(hù)資源之后你就會(huì)明白為什么有些做法屢屢被封而有些做法反而耐用。典型的反爬維度有三個(gè)請(qǐng)求特征User-Agent、Accept、Header 順序的一致性。行為特征單位時(shí)間內(nèi)的請(qǐng)求頻率、請(qǐng)求間隔的規(guī)律性。身份鏈路Cookie、登錄態(tài)、瀏覽器指紋等。應(yīng)對(duì)的思路從來(lái)不是攻破某個(gè)反爬體系而是模擬真實(shí)用戶的合理請(qǐng)求。這樣既保護(hù)了目標(biāo)站點(diǎn)也讓自己的采集行為更規(guī)范、更持久。5.2 UA 輪換與請(qǐng)求頭規(guī)范我自己使用的方式是維護(hù)一個(gè) UA 池每次請(qǐng)求隨機(jī)取一個(gè)USER_AGENTS [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 Version/17.4 Safari/605.1.15, Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0, ] def random_headers(): return { User-Agent: random.choice(USER_AGENTS), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Connection: keep-alive, }然后在創(chuàng)建ClientSession時(shí)就不傳固定 headers 了改成在每次請(qǐng)求時(shí)傳入當(dāng)前 headers。不過(guò)要注意單個(gè) session 會(huì)保存 cookie如果站點(diǎn)用 cookie 做訪問(wèn)用戶計(jì)數(shù)隨機(jī) UA 但固定 cookie 同樣可能暴露規(guī)律。所以更精細(xì)的場(chǎng)景下你需要按需處理 cookie 的生命周期。5.3 限速策略讓采集行為更像函數(shù)調(diào)用這里說(shuō)的限速不是刻意拖慢而是指動(dòng)態(tài)調(diào)整并發(fā)和間隔讓請(qǐng)求速率處于目標(biāo)服務(wù)器的可接受范圍。我在實(shí)踐中發(fā)現(xiàn)直接在代碼里加一個(gè)固定 sleep 是最簡(jiǎn)單粗暴的方式但不夠靈活。更好的方式是把限速融合到信號(hào)量和退避策略里平時(shí)設(shè)置較低的并發(fā)數(shù)比如 30 到 80穩(wěn)為主。一旦發(fā)現(xiàn)響應(yīng)碼出現(xiàn) 429 或 503立即降低并發(fā)并通過(guò)Retry-After頭等待。對(duì)同一個(gè)域名的請(qǐng)求保持一定間隔避免突發(fā)。這也解釋了為什么前文代碼里SEMAPHORE_COUNT是我刻意放在常量里的——它不是炫技參數(shù)而是穩(wěn)定性參數(shù)。跑陌生站點(diǎn)時(shí)我建議先 30 并發(fā)試水觀察日志再逐步往上調(diào)。5.4 合規(guī)采集是一條不可逾越的底線再提一句容易被忽略的事爬蟲技術(shù)本身沒(méi)問(wèn)題但抓取行為必須在法律和平臺(tái)規(guī)則允許的范圍內(nèi)。我在拿到一個(gè)目標(biāo)站點(diǎn)的時(shí)候至少會(huì)確認(rèn)三件事站點(diǎn)是否提供官方 API。有 API 就用 API抓取永遠(yuǎn)是最后選項(xiàng)。robots.txt 明確不允許的內(nèi)容不去強(qiáng)行抓取。不要采集個(gè)人隱私數(shù)據(jù)、賬號(hào)相關(guān)數(shù)據(jù)、非公開數(shù)據(jù)。公開數(shù)據(jù)不代表可以無(wú)限制抓取數(shù)據(jù)量、頻率、用途都需要克制。本篇代碼里的并發(fā)、重試、限速策略都是為了在合規(guī)前提下穩(wěn)定完成采集任務(wù)而不是為了繞過(guò)某種安全機(jī)制。這一點(diǎn)希望所有看到這里的朋友都放在心里。6. 踩坑排查與調(diào)優(yōu)實(shí)測(cè)中常見的六個(gè)翻車現(xiàn)場(chǎng)6.1 連接池耗盡導(dǎo)致大量超時(shí)我第一次跑高并發(fā)時(shí)直接踩到TCPConnectorError: Connector.connector_limit_has_been_reached的報(bào)錯(cuò)。原因是 aiohttp 默認(rèn)連接池限制是 100而我的并發(fā)數(shù)超過(guò)了這個(gè)值導(dǎo)致新請(qǐng)求在等待空閑連接。解決辦法是在創(chuàng)建 session 時(shí)顯式指定連接池大小connector aiohttp.TCPConnector(limit300, limit_per_host50) async with aiohttp.ClientSession(connectorconnector) as session: ...limit是整個(gè)連接池的上限limit_per_host是單個(gè)域名下的連接上限。我一般會(huì)設(shè)置limit_per_host稍小于limit防止所有請(qǐng)求都集中在同一域名時(shí)把連接池占滿。這里的取舍是連接池越大并發(fā)能力越強(qiáng)但目標(biāo)服務(wù)器壓力也越大。不要只加連接數(shù)還要重新評(píng)估目標(biāo)站點(diǎn)的承載能力。6.2 SSL 證書驗(yàn)證錯(cuò)誤的處理目標(biāo)站點(diǎn)如果證書鏈異常aiohttp.ClientSSLError會(huì)時(shí)不時(shí)冒出來(lái)重試也救不了。盲目sslFalse不安全但要帶著ssl.SSLContext來(lái)覆寫驗(yàn)證方式也不算復(fù)雜import ssl ssl_context ssl.create_default_context() ssl_context.check_hostname False ssl_context.verify_mode ssl.CERT_NONE建議僅對(duì)特定域名使用這種補(bǔ)丁式處理不要全局把證書驗(yàn)證關(guān)了否則等于把自己的流量暴露在風(fēng)險(xiǎn)里。正規(guī)站點(diǎn)跑起來(lái)完全用不到這段。6.3 響應(yīng)體讀取超時(shí)而非連接超時(shí)如果你發(fā)現(xiàn)請(qǐng)求偶爾報(bào)asyncio.TimeoutError大概率不是連不上而是響應(yīng)體讀取過(guò)慢。aiohttp 的timeout參數(shù)支持細(xì)粒度控制from aiohttp import ClientTimeout timeout ClientTimeout(total10, connect3, sock_read5) async with session.get(url, timeouttimeout) as resp: ...分項(xiàng)超時(shí)更容易發(fā)現(xiàn)瓶頸到底是連接、讀取還是整體耗時(shí)。調(diào)試時(shí)先把日志級(jí)別調(diào)到 DEBUG你會(huì)看到具體卡在哪一步。6.4 任務(wù)提交方式不當(dāng)反而變慢前面提到過(guò)用 for 循環(huán)逐個(gè)await task是錯(cuò)誤的但還有一個(gè)更隱蔽的問(wèn)題await每個(gè) task 時(shí)如果某個(gè)頁(yè)面異常緩慢會(huì)讓事件循環(huán)逐步推進(jìn)可能后面的任務(wù)并沒(méi)有同步推進(jìn)。使用asyncio.as_completed按完成順序處理結(jié)果能避免某個(gè)慢請(qǐng)求拖住整體流程for coro in asyncio.as_completed(tasks): result await coro process_result(result)這個(gè)技巧適合你需要在抓取過(guò)程中就開始解析、入庫(kù)的場(chǎng)景。如果只是集中批量抓最后統(tǒng)一處理結(jié)果gather會(huì)更直觀。6.5 日志輸出過(guò)多反而成為性能瓶頸高并發(fā)時(shí)控制臺(tái)大量打印日志看著很熱鬧實(shí)際上 I/O 輸出本身也在拖慢程序。我的建議是正式運(yùn)行時(shí)把日志級(jí)別調(diào)到WARNING只在調(diào)試階段用INFO。如果你要追蹤每一個(gè)請(qǐng)求的狀態(tài)可以把日志寫到文件而不是終端。6.6 被目標(biāo)站點(diǎn)限制后的處理狀態(tài)碼不同站點(diǎn)對(duì)限流的表示并不統(tǒng)一。常見的有狀態(tài)碼含義應(yīng)對(duì)403拒絕訪問(wèn)檢查請(qǐng)求頭、UA、Cookie、代理配置429請(qǐng)求過(guò)多等待 Retry-After降低并發(fā)503服務(wù)暫時(shí)不可用退避重試多次失敗后放棄避免死循環(huán)遇到 403 時(shí)我第一反應(yīng)不是去搞各種繞過(guò)手段而是先檢查自己 headers 是不是太裸了。很多時(shí)候一個(gè)完整的 UA、Referer、Accept 就能解決絕大多數(shù)問(wèn)題。7. 收尾經(jīng)驗(yàn)從 12 秒的驚喜到可持續(xù)的穩(wěn)定實(shí)際項(xiàng)目里我不會(huì)盲目追求每次都快反而是會(huì)把并發(fā)數(shù)、重試策略、限速邏輯封裝成配置項(xiàng)針對(duì)不同目標(biāo)站點(diǎn)調(diào)參。比如對(duì)公開 API 可以開 200 并發(fā)對(duì)普通網(wǎng)頁(yè)爬取可能只開 30 到 60高敏感站點(diǎn)則進(jìn)一步調(diào)低配合更長(zhǎng)的退避等待。代碼的另一個(gè)優(yōu)化方向是把 URL 列表拆成分片分批消費(fèi)。這樣即使某一批完全失敗也不會(huì)影響已經(jīng)抓到的數(shù)據(jù)。配合斷點(diǎn)續(xù)采的思路就可以把異步爬蟲真正用于生產(chǎn)環(huán)境。如果你也想跑一版自己的異步爬蟲先從替換URLS開始其他參數(shù)保持默認(rèn)觀察一次完整跑完的日志。當(dāng)看到成功數(shù)接近總數(shù)、耗時(shí)從幾百秒逼近十幾二十秒時(shí)你就會(huì)理解為什么說(shuō)異步是 I/O 密集型任務(wù)的標(biāo)準(zhǔn)答案了。最后提醒一個(gè)容易被忽視的小細(xì)節(jié)asyncio.run(main())之后確保你的代碼在結(jié)尾顯式關(guān)掉 session 和事件循環(huán)。我這套代碼里用的是async with會(huì)自動(dòng)釋放連接和文件描述符這也是為什么我反復(fù)強(qiáng)調(diào) session 要在async with塊里創(chuàng)建。少一個(gè)await、少一個(gè)async with異步程序就可能多一個(gè)隱藏的資源泄漏點(diǎn)到時(shí)候排查起來(lái)就不是 12 秒內(nèi)能解決的事情了。