1. 為什么要離開Scrapy舒適圈學(xué)術(shù)論文采集的三個(gè)死穴先說結(jié)論這年頭如果還要從零搭建一個(gè)學(xué)術(shù)論文摘要采集系統(tǒng)閉眼選Scrapy 同步下載中間件的方案已經(jīng)不是最優(yōu)解了。我這次做某學(xué)術(shù)檢索平臺(tái)的論文摘要爬取項(xiàng)目從最初的全Scrapy架構(gòu)一路演進(jìn)到Playwright asyncio aiohttp為主體的異步采集鏈路中間踩了不少坑。把這段演進(jìn)過程完整整理出來希望對(duì)正在做學(xué)術(shù)數(shù)據(jù)采集、知識(shí)庫(kù)建設(shè)、論文元數(shù)據(jù)沉淀的團(tuán)隊(duì)有參考價(jià)值。學(xué)術(shù)論文摘要抓取和一般網(wǎng)站爬蟲有本質(zhì)區(qū)別。它不是一個(gè)能抓到內(nèi)容就行的活兒而是要長(zhǎng)期、穩(wěn)定、低封禁率地運(yùn)行。痛點(diǎn)集中在三個(gè)地方渲染鏈路深現(xiàn)代學(xué)術(shù)站點(diǎn)幾乎全面轉(zhuǎn)向JavaScript渲染早期純r(jià)equests時(shí)代的靜態(tài)HTML接口大量被廢棄或加密摘要正文、作者機(jī)構(gòu)、基金信息經(jīng)常要觸發(fā)多個(gè)異步請(qǐng)求之后才會(huì)出現(xiàn)在DOM里。Scrapy默認(rèn)架構(gòu)對(duì)這個(gè)場(chǎng)景是無能為力的因?yàn)槟隳玫降腞esponse里根本沒有渲染后的內(nèi)容。反爬策略復(fù)雜學(xué)術(shù)平臺(tái)普遍有指紋檢測(cè)、行為風(fēng)控、頻率限制。同一IP高頻訪問會(huì)導(dǎo)致整段網(wǎng)段被限制連正常的驗(yàn)證碼都不給直接給你一個(gè)黑洞頁面或空白響應(yīng)。這是純Scrapy方案最難處理的。數(shù)據(jù)非結(jié)構(gòu)化程度高摘要本身是自由文本但它和標(biāo)題、作者、DOI、關(guān)鍵詞、引用次數(shù)是鑲嵌在多個(gè)組件里的。解析的準(zhǔn)確率直接取決于你拿到的DOM有多完整。沒渲染完的頁面XPATH路徑會(huì)跳躍今天能跑通的表達(dá)式明天頁面改版就全廢。所以在項(xiàng)目立項(xiàng)階段我就決定了要做一次徹底的架構(gòu)演進(jìn)保留Scrapy在調(diào)度和去重上的成熟能力但在抓取端引入Playwright承擔(dān)瀏覽器渲染與動(dòng)態(tài)內(nèi)容提取同時(shí)把整套網(wǎng)絡(luò)IO切換為異步模型。最終落地的是一個(gè)兩層結(jié)構(gòu)底層是異步抓取引擎負(fù)責(zé)并發(fā)調(diào)度、代理池切換、重試與結(jié)果歸一上層是瀏覽器自動(dòng)化層負(fù)責(zé)登錄態(tài)維持、動(dòng)態(tài)頁面渲染、關(guān)鍵字段抽取。接下來我會(huì)把這套系統(tǒng)的設(shè)計(jì)思路和踩坑過程逐步拆開講。2. 系統(tǒng)全景與訴求拆解第一版架構(gòu)為什么注定不合格2.1 項(xiàng)目目標(biāo)它要采集什么、存什么、提供給誰這個(gè)項(xiàng)目本身是做一個(gè)內(nèi)部知識(shí)庫(kù)的前置數(shù)據(jù)管道——需要持續(xù)從多個(gè)學(xué)術(shù)檢索入口采集論文的題錄信息和摘要正文存成統(tǒng)一格式的結(jié)構(gòu)化記錄供下游做檢索、分類、趨勢(shì)分析。核心采集字段包括論文標(biāo)題、作者列表、作者機(jī)構(gòu)、通訊作者郵箱、摘要原文、DOI、期刊/會(huì)議名稱、發(fā)表年份、關(guān)鍵詞、引用次數(shù)、下載鏈接。這里面最難啃的其實(shí)不是摘要原文而是作者機(jī)構(gòu)和通訊作者郵箱——這兩個(gè)字段在很多檢索頁不會(huì)直接展示需要逐條爬進(jìn)詳情頁才能拿到等于把單論文的請(qǐng)求量翻了一倍。2.2 第一版技術(shù)路線傳統(tǒng)Scrapy同步中間件的組合第一版用的是典型的教科書式Scrapy組合scrapy.Spiderscrapy.RequestSelector配合自研的UA池和IP輪換Middleware。這套方案上線初期的表現(xiàn)勉強(qiáng)能用但隨著采集規(guī)模的提升和學(xué)術(shù)站點(diǎn)反爬的升級(jí)問題開始集中爆發(fā)。最直接的一個(gè)死穴是目標(biāo)站點(diǎn)把論文列表頁分成了輕量摘要版和完整詳情版。輕量摘要版首屏只渲染前20條滾動(dòng)到頁面底部之后才會(huì)通過接口請(qǐng)求加載后續(xù)數(shù)據(jù)。Scrapy的Selector解析的是第一個(gè)Response的靜態(tài)內(nèi)容永遠(yuǎn)拿不到滾動(dòng)加載后的條目——可以這么說跑了一圈每一個(gè)列表頁都只采到了五分之一的論文。第二個(gè)死穴是登錄態(tài)過期。學(xué)術(shù)平臺(tái)普遍要求登錄后才展示完整摘要。Scrapy方案里我用FormRequest模擬登錄但登錄態(tài)的Token是綁定瀏覽器指紋的服務(wù)端很容易識(shí)別出你不是同一個(gè)瀏覽器在操作導(dǎo)致頻繁被踢下線。2.3 為什么不能只在Scrapy上打補(bǔ)丁我最初也想過曲線救國(guó)給Scrapy加Selenium中間件把渲染交給瀏覽器把解析交給Scrapy。這樣做確實(shí)能讓第一版跑起來更順但代價(jià)很大。Scrapy的并發(fā)模型是Twisted異步框架本身不支持在抓取回調(diào)里阻塞等待瀏覽器渲染。官方推薦的scrapy-selenium中間件本質(zhì)上是開一個(gè)Chrome窗口用WebDriverWait做同步等待這就把整個(gè)爬蟲的吞吐量鎖死在了瀏覽器的響應(yīng)速度上。原本同一時(shí)間能并發(fā)5到10個(gè)請(qǐng)求現(xiàn)在只能串行等頁面加載。更麻煩的是scrapy的項(xiàng)目結(jié)構(gòu)里Spider、Item Pipeline、Middleware各層耦合很強(qiáng)加入瀏覽器自動(dòng)化的代碼往往會(huì)散落在各層調(diào)試成本陡增。我在第二版改造中途做過一次對(duì)比同一個(gè)列表頁ScrapySelenium方案平均耗時(shí)6到8秒而純Playwright異步方案只需要2到3秒——這不是調(diào)優(yōu)能補(bǔ)回來的差距是架構(gòu)思路的問題。所以在聽完三方意見后我下定決心只保留Scrapy的調(diào)度和導(dǎo)出邏輯抓取端整體重寫。3. 從Scrapy到Playwright的遷移路線三個(gè)關(guān)鍵決策的過程與理由3.1 抓取引擎為什么選Playwright而不是Selenium或純r(jià)equests選型這件事我其實(shí)糾結(jié)了將近一周。當(dāng)時(shí)候選方案有三個(gè)Playwright、Selenium、純r(jià)equests 接口逆向。最終選了Playwright理由有三個(gè)。第一Playwright的async API是一等公民。它的async_playwright上下文可以直接嵌入asyncio的事件循環(huán)不需要額外的線程橋接。對(duì)后續(xù)做異步并發(fā)來說是天然友好的。Selenium的異步支持一直是半吊子官方推薦方案還是要靠線程池這在高并發(fā)下資源開銷很夸張。第二Playwright對(duì)動(dòng)態(tài)渲染的處理更細(xì)。它自帶auto_wait機(jī)制元素定位時(shí)會(huì)自動(dòng)等待元素出現(xiàn)不需要手動(dòng)寫一堆time.sleep(5)。它還支持?jǐn)r截網(wǎng)絡(luò)請(qǐng)求、修改響應(yīng)內(nèi)容這對(duì)處理學(xué)術(shù)站點(diǎn)常見的XHR接口返回來說非常有用。我可以直接在瀏覽器里攔下JSON數(shù)據(jù)用json.loads處理而不一定非要在DOM里摳文本。第三是維護(hù)成本。Playwright的瀏覽器驅(qū)動(dòng)是自動(dòng)下載、自動(dòng)匹配版本的不用像Selenium那樣擔(dān)心Chrome升級(jí)之后chromedriver版本對(duì)不上。這一點(diǎn)在長(zhǎng)期運(yùn)行的系統(tǒng)里太重要了。3.2 異步技術(shù)棧怎么選asyncio為骨架aiohttp為傳輸Playwright為渲染確定Playwright之后我梳理了整套系統(tǒng)需要承載的并發(fā)需求每個(gè)檢索關(guān)鍵詞需要抓取分頁列表分頁數(shù)量平均20頁每個(gè)列表頁加載后需要進(jìn)入5到15個(gè)詳情頁抽取完整通信信息全站需要支持不低于50個(gè)并發(fā)任務(wù)的穩(wěn)態(tài)運(yùn)行。如果用同步HTTP請(qǐng)求線程池線程上下文切換的開銷會(huì)讓CPU一直在空轉(zhuǎn)。所以在網(wǎng)絡(luò)傳輸層引入了aiohttp。aiohttp負(fù)責(zé)所有不需要瀏覽器渲染的請(qǐng)求比如批量下載PDF、獲取純文本接口Playwright負(fù)責(zé)需要JS渲染的列表和詳情頁。實(shí)際運(yùn)行時(shí)的流程是asyncio協(xié)程調(diào)度器發(fā)出抓取任務(wù)如果任務(wù)特征是URL已知、內(nèi)容為靜態(tài)JSON就交給aiohttp直接抓取如果是需要瀏覽器環(huán)境、需要登錄態(tài)、需要JS渲染就打進(jìn)Playwright的異步上下文執(zhí)行。兩套傳輸層共用同一個(gè)代理池和重試隊(duì)列互不阻塞。3.3 改造大綱哪些保留、哪些刪除、哪些重寫改造之前有個(gè)很重要的工作把原有Scrapy項(xiàng)目里到底哪些代碼是真正有用的、哪些是牽一發(fā)動(dòng)全身的依賴全部盤清楚。我最終保留的只有三塊items.py里定義的數(shù)據(jù)模型基本沒改字段結(jié)構(gòu)依然合理settings.py中DOWNLOAD_DELAY、并發(fā)數(shù)、日志等級(jí)等基礎(chǔ)配置自研的ProxyMiddleware的代理池對(duì)接邏輯后來改造成異步版本后保留。刪除和重寫的部分所有Spider類全部廢棄換成基于asyncio的采集任務(wù)函數(shù)scrapy.Request及其回調(diào)邏輯改成async函數(shù)見后文Selector解析邏輯改成基于Playwright的locator或封裝函數(shù)所有Downloader Middleware和Item Pipeline的同步實(shí)現(xiàn)改成管道式的async處理函數(shù)。一個(gè)常見的誤解是要從零推翻重來但我的經(jīng)驗(yàn)是只要數(shù)據(jù)模型不變采集鏈路的改動(dòng)其實(shí)可以控制在一個(gè)可控范圍內(nèi)。數(shù)據(jù)模型是你的接口層采集實(shí)現(xiàn)是你的內(nèi)部實(shí)現(xiàn)兩者分開設(shè)計(jì)改造起來才不痛苦。4. 核心實(shí)現(xiàn)異步抓取鏈路到底怎么落地4.1 任務(wù)流轉(zhuǎn)與調(diào)度器設(shè)計(jì)系統(tǒng)采用一個(gè)簡(jiǎn)單的兩級(jí)任務(wù)隊(duì)列列表頁任務(wù)和詳情頁任務(wù)。列表頁任務(wù)由關(guān)鍵詞列表自動(dòng)生成詳情頁任務(wù)由列表頁的解析結(jié)果動(dòng)態(tài)產(chǎn)生。調(diào)度器用asyncio.Queue實(shí)現(xiàn)不需要引入Celery這樣重級(jí)別的分布式框架。原因有二單機(jī)并發(fā)50到100個(gè)任務(wù)時(shí)asyncio.Queue完全夠用調(diào)度基本沒有延遲引入外部消息隊(duì)列會(huì)多一層序列化和網(wǎng)絡(luò)開銷對(duì)這個(gè)場(chǎng)景來說是浪費(fèi)。調(diào)度器核心代碼大致是這樣的# 簡(jiǎn)化版任務(wù)調(diào)度核心 import asyncio from dataclasses import dataclass, field dataclass class FetchTask: task_type: str # list 或 detail url: str keyword: str retry_count: int 0 extra: dict field(default_factorydict) class TaskScheduler: def __init__(self, max_concurrency50): self.queue asyncio.Queue() self.max_concurrency max_concurrency self.sem asyncio.Semaphore(max_concurrency) async def put(self, task: FetchTask): await self.queue.put(task) async def get(self): return await self.queue.get() async def worker(self, fetcher): while True: task await self.get() async with self.sem: try: await fetcher.process(task) except Exception as exc: await self.handle_retry(task, exc)這里最關(guān)鍵的邏輯在handle_retry重試次數(shù)上限是3次超過3次就記錄到失敗日志并丟棄。需要注意的是重試時(shí)不能簡(jiǎn)單地重新入隊(duì)——如果是因?yàn)榇鞩P被封導(dǎo)致的失敗必須輪換代理之后再重試否則只會(huì)重復(fù)踩同一個(gè)坑。4.2 Playwright的異步上下文與并發(fā)控制Playwright本身支持多頁面共享一個(gè)瀏覽器上下文但學(xué)術(shù)采集場(chǎng)景有個(gè)特殊要求不同關(guān)鍵詞最好用不同的瀏覽器上下文。主要原因是學(xué)術(shù)平臺(tái)的登錄態(tài)、Cookie、localStorage是按會(huì)話維度存儲(chǔ)的如果兩個(gè)關(guān)鍵詞共用同一個(gè)上下文一個(gè)頁面的行為異常容易污染另一個(gè)頁面的會(huì)話。異步上下文管理我這樣實(shí)現(xiàn)# Playwright 異步上下文封裝 import asyncio from playwright.async_api import async_playwright class PlaywrightFetcher: def __init__(self, proxy_urlNone): self.proxy_url proxy_url self.playwright None self.browser None self.contexts {} async def start(self): self.playwright await async_playwright().start() self.browser await self.playwright.chromium.launch( headlessTrue, args[ --disable-blink-featuresAutomationControlled, --disable-dev-shm-usage, ], ) async def new_context(self, keyword: str): context await self.browser.new_context( viewport{width: 1280, height: 800}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36, proxy{server: self.proxy_url} if self.proxy_url else None, ) self.contexts[keyword] context return context async def fetch(self, task: FetchTask): ctx self.contexts.get(task.keyword) if not ctx: ctx await self.new_context(task.keyword) page await ctx.new_page() try: if task.task_type list: return await self.fetch_list(page, task) else: return await self.fetch_detail(page, task) finally: await page.close() async def close(self): for ctx in self.contexts.values(): await ctx.close() await self.browser.close() await self.playwright.stop()這段代碼里有幾個(gè)容易踩的坑我先說明args[--disable-blink-featuresAutomationControlled]是必須加的它可以隱藏navigator.webdriver標(biāo)記顯著降低被學(xué)術(shù)平臺(tái)識(shí)別為爬蟲的概率。每一個(gè)page用完之后一定要close()不能復(fù)用。復(fù)用頁面會(huì)累積內(nèi)存和DOM事件監(jiān)聽器跑幾萬條任務(wù)后內(nèi)存會(huì)膨脹到系統(tǒng)OOM。瀏覽器上下文使用字典緩存而不是為每一個(gè)任務(wù)創(chuàng)建這樣能讓每個(gè)關(guān)鍵詞的登錄態(tài)復(fù)用不會(huì)動(dòng)不動(dòng)要求重新登錄。4.3 列表頁的滾動(dòng)加載與字段抽取學(xué)術(shù)檢索平臺(tái)的一個(gè)典型交互是進(jìn)入了檢索結(jié)果頁頁面上只有前20條結(jié)果向下滾動(dòng)到一定高度后會(huì)觸發(fā)懶加載接口返回下20條。這個(gè)過程可能重復(fù)數(shù)次直到所有結(jié)果加載完畢。用Playwright處理這個(gè)場(chǎng)景的思路是先打開列表頁然后循環(huán)執(zhí)行滾動(dòng)和等待直到檢測(cè)到底部元素不再出現(xiàn)或者翻頁接口調(diào)用結(jié)束。一個(gè)真實(shí)項(xiàng)目的核心邏輯async def fetch_list(self, page, task): await page.goto(task.url, wait_untildomcontentloaded, timeout30000) # 處理可能出現(xiàn)的登錄彈窗和Cookie橫幅 try: await page.click(text同意, timeout3000) except Exception: pass items [] # 預(yù)設(shè)的滾動(dòng)距離和停頓時(shí)間需要根據(jù)目標(biāo)站點(diǎn)實(shí)際表現(xiàn)微調(diào) for scroll_round in range(20): # 獲取當(dāng)前頁面已加載的條目數(shù) current_count await page.locator( //div[contains(class, result-item)] ).count() # 判斷是否已經(jīng)加載到底 reach_end await page.locator( //div[contains(class, pagination-end)] ).count() if reach_end: break # 滾動(dòng)到頁面底部觸發(fā)懶加載 await page.evaluate(window.scrollTo(0, document.body.scrollHeight)) # 等待新條目出現(xiàn)不能直接sleep要等待特定元素 await page.wait_for_function( (prevCount) { return document.querySelectorAll( .result-item ).length prevCount; }, argcurrent_count, timeout10000, ) # 所有條目加載完成后統(tǒng)一提取字段 for i in range(await page.locator(//div[contains(class, result-item)]).count()): item page.locator( //div[contains(class, result-item)] ).nth(i) title await item.locator(.title).inner_text() authors await item.locator(.authors).inner_text() abstract_preview await item.locator(.abstract-preview).inner_text() link await item.locator(a.detail-link).get_attribute(href) items.append({ title: title.strip(), authors: authors.strip(), abstract_preview: abstract_preview.strip(), detail_url: page.urljoin(link), }) return items滾動(dòng)加載的“如何確定加載完”是整個(gè)列表頁抓取能否成功的關(guān)鍵。wait_for_function是Playwright里極好用的API它會(huì)在頁面上下文里執(zhí)行JavaScript并輪詢直到返回真值。這段代碼里我傳入了上一次的元素?cái)?shù)量只有當(dāng)result-item的數(shù)量增加時(shí)才認(rèn)為加載完成避免過早結(jié)束。如果你要處理的是一個(gè)類型不固定、沒有統(tǒng)一末尾標(biāo)記的頁面還有一個(gè)更穩(wěn)妥的方案記錄上一次的數(shù)量循環(huán)執(zhí)行滾動(dòng)如果連續(xù)3次滾動(dòng)后數(shù)量都沒有變化就判定加載完成。我建議把這個(gè)方案作為回退邏輯。4.4 詳情頁的深度信息補(bǔ)全摘要與機(jī)構(gòu)的提取策略詳情頁是摘錄完整信息的唯一來源。列表頁拿到的只是預(yù)覽片段經(jīng)常被截?cái)嗟揭话搿Ｔ斍轫撟侄纬槿〉碾y點(diǎn)在于作者機(jī)構(gòu)和通訊作者郵箱這些字段在頁面上不一定以標(biāo)準(zhǔn)格式出現(xiàn)。我采用了一個(gè)按優(yōu)先級(jí)遞減的提取策略優(yōu)先嘗試頁面上的結(jié)構(gòu)化JSON數(shù)據(jù)很多學(xué)術(shù)站會(huì)在script typeapplication/json里嵌入論文原始數(shù)據(jù)抽取精準(zhǔn)度最高其次用locator按已知的DIV/CSS類名抽取最后用正則或關(guān)鍵詞匹配從正文文本里找郵箱和機(jī)構(gòu)關(guān)鍵字。結(jié)構(gòu)化JSON數(shù)據(jù)這種形態(tài)在學(xué)術(shù)網(wǎng)站里非常常見。它藏在script標(biāo)簽里用Playwright拿起來很方便async def parse_structured_metadata(self, page): scripts await page.locator(script[typeapplication/json]).all() for script in scripts: raw await script.inner_text() if not raw: continue try: data json.loads(raw) if isinstance(data, list): data data[0] if data else {} if title in data and abstract in data: return data except json.JSONDecodeError: continue return {}這里的關(guān)鍵是絕對(duì)不要假設(shè)JSON一定存在。真實(shí)項(xiàng)目中我遇到過一個(gè)檢索平臺(tái)結(jié)構(gòu)化的JSON只覆蓋了60%的頁面剩下的40%只能靠DOM解析兜底。所以提取邏輯必須做多級(jí)回退不能一錘子買賣。如果看到只依賴單一數(shù)據(jù)源抽取就上線的代碼后續(xù)等待你的大概率是無窮無盡的“這條數(shù)據(jù)怎么字段是空的”維護(hù)工單。5. 爬蟲上線后的踩坑實(shí)錄四個(gè)意外與完整排查鏈路系統(tǒng)開發(fā)完成、進(jìn)入真實(shí)學(xué)術(shù)站點(diǎn)試運(yùn)行階段后各種問題才真正開始顯現(xiàn)。這部分我把過程中的典型坑完整記錄下來按“現(xiàn)象 - 排查 - 根因 - 解決”的結(jié)構(gòu)展開比直接給結(jié)論要更有參考價(jià)值。5.1 瀏覽器指紋被識(shí)別所有頁面正常返回空白現(xiàn)象在本地手動(dòng)運(yùn)行Playwright腳本時(shí)頁面渲染、字段抽取都正常但一旦打包上線跑大概200個(gè)關(guān)鍵詞之后所有頁面開始返回空白。不是報(bào)錯(cuò)、不是驗(yàn)證碼就是一個(gè)空白的body。排查鏈路第一步看日志發(fā)現(xiàn)沒有超時(shí)、沒有請(qǐng)求失敗所有請(qǐng)求都是200狀態(tài)。第二步直接連接同一代理IP用普通瀏覽器打開相同URL一切正常。第三步懷疑是代理IP池出了問題更換全新代理IP后問題依然存在。第四步開始懷疑瀏覽器指紋——在本地用headlessFalse跑正常換成headlessTrue跑問題復(fù)現(xiàn)。根因headlessTrue模式下瀏覽器會(huì)暴露不少自動(dòng)化特征比如navigator.webdriver true、缺少chrome.window對(duì)象等。目標(biāo)站點(diǎn)檢測(cè)到了WebDriver標(biāo)記不是封禁IP而是直接返回空白頁面來消耗你的資源。解決在啟動(dòng)參數(shù)中增加反自動(dòng)化標(biāo)記同時(shí)用context.add_init_script注入一段JavaScript隱藏WebDriver特征。具體來說是在啟動(dòng)時(shí)執(zhí)行如下初始化腳本# 通過 init_script 隱藏自動(dòng)化檢測(cè)標(biāo)記 await context.add_init_script( Object.defineProperty(navigator, webdriver, { get: () undefined }); window.chrome window.chrome || { runtime: {} }; )這個(gè)改動(dòng)之后空白頁面問題徹底消失。需要強(qiáng)調(diào)這絕不是為了非法繞過什么機(jī)制只是讓正常的瀏覽器自動(dòng)化工具可以穩(wěn)定完成公開學(xué)術(shù)數(shù)據(jù)的采集工作。5.2 列表頁數(shù)據(jù)重復(fù)去重機(jī)制的三個(gè)漏洞現(xiàn)象采集中有接近30%的論文是重復(fù)的也就是同一篇論文被采集了多次導(dǎo)致下游入庫(kù)時(shí)產(chǎn)生大量重復(fù)記錄。排查鏈路首先檢查關(guān)鍵詞是否重疊發(fā)現(xiàn)兩個(gè)接近的關(guān)鍵詞比如reinforcement learning和deep reinforcement learning拉取的檢索結(jié)果確實(shí)有大量重疊。其次檢查分頁是否重復(fù)發(fā)現(xiàn)部分列表頁在滾動(dòng)加載時(shí)會(huì)把前20條重復(fù)渲染一次。最后檢查詳情頁任務(wù)生成邏輯發(fā)現(xiàn)同一個(gè)詳情頁可能被多個(gè)不同的列表頁任務(wù)解析后重復(fù)入隊(duì)。根因重復(fù)不是單一原因造成的而是三層疊加關(guān)鍵詞重疊語義接近的關(guān)鍵詞產(chǎn)生相同論文命中分頁重疊懶加載接口在快速滾動(dòng)時(shí)重復(fù)返回前20條數(shù)據(jù)任務(wù)重復(fù)同一詳情頁被不同列表頁解析、生成、入隊(duì)。解決在任務(wù)調(diào)度器入口處對(duì)所有詳情頁任務(wù)URL做一步基于規(guī)范化URL的BloomFilter去重class UrlDeduplicator: def __init__(self): self.visited set() def normalize(self, url: str) - str: # 去掉常見的追蹤參數(shù)只保留穩(wěn)定的標(biāo)識(shí)累加參數(shù) from urllib.parse import urlparse, parse_qsl, urlencode parsed urlparse(url) params [item for item in parse_qsl(parsed.query) if item[0] not in (utm_source, utm_medium, session_id)] return parsed._replace(queryurlencode(sorted(params))).geturl() def is_duplicate(self, url: str) - bool: norm self.normalize(url) if norm in self.visited: return True self.visited.add(norm) return False另一個(gè)細(xì)節(jié)是列表頁任務(wù)本身也需要去重因?yàn)闈L動(dòng)加載后當(dāng)前頁的URL可能會(huì)變化有些站點(diǎn)翻頁是改變hash而不是路徑忽略這一點(diǎn)的話同一個(gè)關(guān)鍵詞的20頁會(huì)被重復(fù)抓20次。5.3 登錄態(tài)自動(dòng)失效瀏覽器上下文的Cookie隔離問題現(xiàn)象系統(tǒng)運(yùn)行一段時(shí)間后進(jìn)入詳情頁時(shí)偶爾彈出登錄框?qū)е伦ト〉降恼堑卿浨翱梢姷慕財(cái)喟姹?。排查鏈路在日志里找到彈出的登錄框時(shí)對(duì)應(yīng)的關(guān)鍵詞上下文應(yīng)該已經(jīng)有正常的登錄Cookie。但奇怪的是部分上下文可以用部分不行。進(jìn)一步檢查發(fā)現(xiàn)共享的上下文里不同關(guān)鍵詞之間雖然沒有互相清理Cookie但有一個(gè)關(guān)鍵詞觸發(fā)了OAuth重定向這個(gè)重定向把整個(gè)共享上下文的存儲(chǔ)清洗了一遍。根因多個(gè)關(guān)鍵詞任務(wù)共用了同一個(gè)瀏覽器上下文。某一次詳情頁重定向到OAuth端點(diǎn)時(shí)服務(wù)端返回的Set-Cookie里帶了Domain屬性是根域的Cookie由于同一個(gè)上下文內(nèi)其他關(guān)鍵詞的域名也在同一Cookie域下導(dǎo)致所有會(huì)話被覆蓋。解決把每關(guān)鍵詞一個(gè)上下文改為每關(guān)鍵詞一個(gè)持久化上下文目錄使用Playwright的launch_persistent_context同時(shí)確保每個(gè)上下文的Cookie存儲(chǔ)隔離到獨(dú)立文件目錄# 每個(gè)關(guān)鍵詞都有獨(dú)立的持久化上下文目錄 context await playwright.chromium.launch_persistent_context( user_data_dirf/data/crawler/contexts/{sanitize(keyword)}, headlessTrue, viewport{width: 1280, height: 800}, )這樣做之后即使某個(gè)關(guān)鍵詞的登錄態(tài)被服務(wù)端強(qiáng)制失效也只影響單個(gè)目錄不需要重新登錄所有關(guān)鍵詞。提示帶持久化上下文的啟動(dòng)速度比普通browser.new_context要慢一些冷啟動(dòng)大概多1到2秒。為了穩(wěn)定性這個(gè)代價(jià)是值得的。5.4 代理池切換不及時(shí)連續(xù)重試導(dǎo)致的IP雪崩現(xiàn)象采集達(dá)到峰值狀態(tài)時(shí)代理池里的所有IP在幾分鐘內(nèi)全部被封。排查鏈路查看單條失敗重試鏈路發(fā)現(xiàn)首次失敗后進(jìn)入重試隊(duì)列重試時(shí)沒有換代理IP而是用了原來的IP又一次請(qǐng)求導(dǎo)致同一IP連續(xù)被封。當(dāng)封禁IP比例達(dá)到一定閾值后代理池的可用IP迅速歸零全局任務(wù)全部陷入重試死循環(huán)。根因我把代理池的輪換邏輯放在了任務(wù)重試的外層以為每次重試入隊(duì)時(shí)都會(huì)重新挑選代理。但實(shí)際上依賴的是Playwright上下文創(chuàng)建時(shí)的proxy參數(shù)而上下文一旦創(chuàng)建代理就固定了。重試時(shí)如果上下文沒有銷毀重建代理IP就不會(huì)變化。解決在handle_retry里增加邏輯如果重試次數(shù)等于1則強(qiáng)制銷毀當(dāng)前上下文重新獲取代理IP后進(jìn)入新的上下文。同時(shí)增加一個(gè)max_fail_lock機(jī)制當(dāng)某個(gè)頁面連續(xù)失敗超過3次時(shí)暫停該關(guān)鍵詞的任務(wù)進(jìn)入冷卻期避免因?yàn)槟骋黄尉W(wǎng)絡(luò)問題拖垮整個(gè)代理池。6. 新老方案實(shí)測(cè)吞吐量、資源占用與穩(wěn)定性的量化對(duì)比在系統(tǒng)改造完成并穩(wěn)定運(yùn)行2周后我做了一輪A/B測(cè)試目的是客觀評(píng)估這套新方案相對(duì)舊Scrapy方案到底帶來了多少收益。6.1 對(duì)比條件與指標(biāo)說明為了保證對(duì)比公平我控制了三個(gè)變量采集的目標(biāo)站點(diǎn)相同同一個(gè)學(xué)術(shù)檢索平臺(tái)同一批共100個(gè)關(guān)鍵詞數(shù)據(jù)規(guī)模相同每個(gè)關(guān)鍵詞拉取前200條共約2萬條記錄硬件環(huán)境相同一臺(tái)8核16G內(nèi)存的服務(wù)器同一網(wǎng)絡(luò)出口。實(shí)測(cè)指標(biāo)包括單條記錄平均耗時(shí)、成功率、IP封禁率、內(nèi)存峰值、CPU平均占用。6.2 實(shí)測(cè)數(shù)據(jù)總覽指標(biāo)舊方案Scrapy 同步下載器新方案Playwright asyncio aiohttp變化單條記錄平均耗時(shí)約2.8秒/條約0.6秒/條提升約78%整體采集成功率84.2%96.7%提升12.5個(gè)百分點(diǎn)代理IP封禁率約35%約8%降低77%內(nèi)存峰值約11GB約6.5GB降低41%CPU平均占用約70%約35%降低50%100個(gè)關(guān)鍵詞跑完總時(shí)長(zhǎng)約5小時(shí)約1小時(shí)縮短4小時(shí)這個(gè)數(shù)據(jù)說明兩點(diǎn)異步 瀏覽器渲染的組合不是微調(diào)優(yōu)化而是數(shù)量級(jí)的差距。舊方案的大量時(shí)間耗在串行等待頁面加載和頻繁重試上新方案把閑置等待時(shí)間徹底折疊進(jìn)了事件循環(huán)同時(shí)更精準(zhǔn)的渲染和更低的封禁率也降低了重試成本。6.3 為什么封禁率能降這么多新方案封禁率大幅下降并非單點(diǎn)突破而是多個(gè)因素的疊加瀏覽器指紋更真實(shí)反爬系統(tǒng)不容易把你識(shí)別成爬蟲并發(fā)模型從瞬時(shí)打爆連接變成穩(wěn)定流轉(zhuǎn)同一時(shí)刻的活躍請(qǐng)求被限制在一個(gè)合理水平帶重試的代理輪換策略不會(huì)讓同一個(gè)IP連續(xù)出問題auto_wait機(jī)制減少了因?yàn)轫撁婕虞d沒有完成而產(chǎn)生的超時(shí)重試——超時(shí)重試本身就是引發(fā)風(fēng)控的重要信號(hào)源。這也解釋了為什么很多人用Selenium做學(xué)術(shù)采集依然被封得很慘不是瀏覽器自動(dòng)化不好而是并發(fā)調(diào)度策略沒有跟上。瀏覽器窗口開太多、太快、太無規(guī)律反爬系統(tǒng)通過行為建模很快就能鎖定你。7. 這套架構(gòu)的邊界與后續(xù)會(huì)怎么演進(jìn)7.1 它不適合什么場(chǎng)景說清楚這套系統(tǒng)的邊界對(duì)想直接套用的讀者來說很重要。如果目標(biāo)只是采集靜態(tài)HTML頁面、沒有JavaScript渲染需求那么切到Playwright確實(shí)是一種用重武器打蚊子的行為。aiohttp 靜態(tài)解析可能是更輕、更快、更穩(wěn)定的選擇。Playwright的瀏覽器實(shí)例會(huì)帶來額外的啟動(dòng)時(shí)間和內(nèi)存開銷為純靜態(tài)頁面用它是得不償失的。如果采集量極小比如每天幾百條那么Scrapy或者requests完全夠用。引入異步和瀏覽器渲染會(huì)讓調(diào)試變得復(fù)雜學(xué)習(xí)成本還不低。架構(gòu)的復(fù)雜度和業(yè)務(wù)的需求量必須匹配否則就是過度工程。如果目標(biāo)站點(diǎn)的反爬不是基于瀏覽器指紋和頻率控制而是基于賬號(hào)體系的風(fēng)控策略比如訂閱分?jǐn)?shù)的權(quán)重、付費(fèi)墻那這套方案也無能為力。你需要做的是賬號(hào)管理、行為模擬和用戶畫像層面的合規(guī)工作這和單純的技術(shù)采集是兩個(gè)維度。7.2 下一代架構(gòu)的演進(jìn)方向?yàn)g覽器池化與數(shù)據(jù)管道分離目前這套系統(tǒng)還有一個(gè)明顯的瓶頸PlaywrightFetcher的瀏覽器上下文是按關(guān)鍵詞維度維護(hù)的但Playwright實(shí)例本身依然是單點(diǎn)的。如果目標(biāo)站點(diǎn)數(shù)量翻倍或者將來引入多地域部署需求單機(jī)單瀏覽器會(huì)變成性能瓶頸。我規(guī)劃中的下一步是把Playwright做成獨(dú)立的瀏覽器池化服務(wù)通過無頭瀏覽器集群對(duì)外提供抓取能力采集引擎和服務(wù)之間用消息隊(duì)列解耦。具體的做法是啟動(dòng)多個(gè)分布式Worker節(jié)點(diǎn)每個(gè)Worker承載若干個(gè)Playwright瀏覽器實(shí)例它們各自維護(hù)獨(dú)立的代理和上下文。調(diào)度器通過一個(gè)共享的任務(wù)隊(duì)列把任務(wù)分發(fā)給空閑的Worker。這個(gè)設(shè)計(jì)在現(xiàn)代遠(yuǎn)程瀏覽器隔離、容器化部署的背景下難度不大但能有效突破單機(jī)瓶頸。數(shù)據(jù)管道層面也會(huì)繼續(xù)調(diào)整。目前摘要、作者、機(jī)構(gòu)等字段是在采集階段全部抽好的但其實(shí)可以拆成兩個(gè)階段先采集原始HTML或渲染后的DOM快照再通過解析管道統(tǒng)一抽取。這樣做的好處是頁面如果改了CSS類名不需要重新抓一遍網(wǎng)站只需要把之前的DOM快照重新跑一遍解析邏輯即可歷史數(shù)據(jù)也能重放和追溯。7.3 一個(gè)繞不開的合規(guī)提醒最后想認(rèn)真說一點(diǎn)。做學(xué)術(shù)數(shù)據(jù)采集這個(gè)方向技術(shù)上的空間很大但合規(guī)邊界必須先想清楚。我做這個(gè)項(xiàng)目時(shí)嚴(yán)格限制在公開數(shù)據(jù)范圍內(nèi)對(duì)私有賬號(hào)數(shù)據(jù)不做采集更不去利用漏洞或破解付費(fèi)墻。目標(biāo)平臺(tái)的服務(wù)條款和robots協(xié)議是我們判斷邊界的重要依據(jù)——只采集公開可訪問的論文元數(shù)據(jù)和摘要避免影響目標(biāo)平臺(tái)的正常服務(wù)。合規(guī)不是事后補(bǔ)丁而是在架構(gòu)設(shè)計(jì)時(shí)就應(yīng)該考慮進(jìn)去的約束。比如設(shè)計(jì)合理的請(qǐng)求頻率不要把并發(fā)拉得太高對(duì)目標(biāo)站點(diǎn)的負(fù)載保持克制對(duì)用戶隱私數(shù)據(jù)不做永久存儲(chǔ)。如果你把爬取的論文數(shù)據(jù)用于商業(yè)目的務(wù)必先獲得相應(yīng)的授權(quán)或者確認(rèn)目標(biāo)平臺(tái)的數(shù)據(jù)許可條款。這樣你的技術(shù)能力才不會(huì)用錯(cuò)地方?？偨Y(jié)一點(diǎn)個(gè)人體會(huì)整套從Scrapy到Playwright的演進(jìn)做完之后我最大的感受是技術(shù)選型不是越新越好而是越貼合場(chǎng)景的越好。學(xué)術(shù)論文摘要抓取這個(gè)場(chǎng)景的核心矛盾在于動(dòng)態(tài)渲染反爬高數(shù)據(jù)質(zhì)量三者之間的平衡。Scrapy解決不了動(dòng)態(tài)渲染Selenium解決不了并發(fā)效率只有把瀏覽器自動(dòng)化的可控性和異步模型的吞吐量合在一起才是真正能長(zhǎng)期穩(wěn)定運(yùn)行的方向。如果你正在做類似的爬蟲架構(gòu)升級(jí)我的建議是從最小可行改造開始先把一個(gè)列表頁用Playwright跑通再逐步替換任務(wù)調(diào)度不要試圖一次性把全鏈路推翻。這樣每一步都可以驗(yàn)證效果出了問題也能快速定位。技術(shù)棧再漂亮也比不上能連續(xù)穩(wěn)定運(yùn)行一個(gè)月不鬧脾氣的數(shù)據(jù)管道。