簡(jiǎn)介C多線程抓取網(wǎng)頁的完整示例代碼面向正在學(xué)習(xí)網(wǎng)絡(luò)爬蟲、數(shù)據(jù)抓取或網(wǎng)頁批量下載的C開發(fā)者尤其適合有一定C基礎(chǔ)但尚未接觸過多線程與HTTP庫配合的初學(xué)者。壓縮包共包含十六個(gè)文件其中主要有五個(gè)頭文件類與接口聲明、三個(gè)源文件核心抓取與界面邏輯、一個(gè)工程文件、一個(gè)對(duì)話框資源文件等整體僅二十二KB結(jié)構(gòu)精簡(jiǎn)可快速打開工程閱讀。目前已有一百七十人瀏覽學(xué)習(xí)屬于小巧實(shí)用的入門級(jí)參考。代碼基于標(biāo)準(zhǔn)線程庫創(chuàng)建抓取線程配合libcurl發(fā)送HTTP請(qǐng)求并使用pugixml解析返回的HTML同時(shí)演示了線程的join與detach、共享數(shù)據(jù)保護(hù)、curl全局初始化與清理等關(guān)鍵細(xì)節(jié)。讀者可從中理解多線程與網(wǎng)絡(luò)I/O協(xié)作的模式并在此基礎(chǔ)上擴(kuò)展任務(wù)隊(duì)列、限速策略或分布式抓取邏輯構(gòu)建自己的爬蟲工具。1. C 多線程抓取網(wǎng)頁這個(gè) VC 工程把并發(fā)抓取做成了能直接跑的樣本C 多線程抓取網(wǎng)頁這件事最大的門檻不在 HTTP 協(xié)議而在并發(fā)本身隊(duì)列誰來維護(hù)、線程怎么退出、抓下來的 HTML 怎么避免亂碼。這個(gè) VC 工程把整條鏈路做成了一個(gè)能直接編譯運(yùn)行的 MFC 對(duì)話框程序——界面上貼一組 URL設(shè)好線程數(shù)點(diǎn)開始幾個(gè)工作線程就從共享隊(duì)列里取任務(wù)、發(fā)請(qǐng)求、把頁面按原始編碼保存到本地。代碼量不大但線程同步、狀態(tài)碼判斷、編碼轉(zhuǎn)換這些坑都踩過一遍。它適合兩類人想學(xué) VC 下 WinINet 與多線程配合的初學(xué)者跟著把數(shù)據(jù)流跑通就能理解生產(chǎn)-消費(fèi)模型要做 Windows 桌面抓取工具的開發(fā)者改一改隊(duì)列和解析模塊就能當(dāng)爬蟲底座。下面按架構(gòu)、核心代碼、踩坑、改造四個(gè)方向拆。2. 項(xiàng)目架構(gòu)與數(shù)據(jù)流界面、抓取核心、協(xié)議封裝三層怎么協(xié)作2.1 文件結(jié)構(gòu)與依賴關(guān)系拿到工程先別急著按 F7把源碼文件過一遍會(huì)更省事。這個(gè)抓取工程沿用了 VC 對(duì)話框工程最常見的分法界面層、抓取核心層、協(xié)議封裝層各放各的避免網(wǎng)絡(luò)請(qǐng)求和界面刷新攪在同一個(gè)文件里。我拆到的這份源碼文件組織大致如下文件職責(zé)被誰依賴SpiderDemo.sln / SpiderDemo.vcxproj工程文件VS2015 及以上可直接打開-SpiderDemoDlg.cpp / .h主對(duì)話框URL 輸入?yún)^(qū)、線程數(shù)設(shè)置、開始/停止按鈕、日志列表頂層入口SpiderCore.cpp / .h抓取核心持有 URL 隊(duì)列、啟動(dòng)/停止工作線程、協(xié)調(diào)整個(gè)抓取流程被對(duì)話框依賴UrlQueue.cpp / .h線程安全的 URL 隊(duì)列內(nèi)部封裝 CRITICAL_SECTION被 SpiderCore 依賴Fetcher.cpp / .h基于 WinINet 的 HTTP 請(qǐng)求封裝對(duì)外只暴露一個(gè) Fetch 方法被 SpiderCore 依賴HtmlParser.cpp / .h輕量 HTML 解析提取 charset、標(biāo)題、頁內(nèi)鏈接被 SpiderCore 依賴resource.h / SpiderDemo.rc對(duì)話框資源、圖標(biāo)與版本信息編譯期依賴關(guān)系是單向的SpiderCore 依賴 UrlQueue 和 Fetcher、HtmlParser而對(duì)話框只依賴 SpiderCore。注意一個(gè)反向約束——SpiderCore 里不能出現(xiàn)任何 CWnd 控件調(diào)用它對(duì)外通知結(jié)果只通過 PostMessage 投遞自定義消息這是后面 4.1 節(jié)那個(gè)假死問題的根源所在代碼里從一開始就切斷了這條線。模塊拆這么細(xì)是為了改造時(shí)不用動(dòng)全局。你想把 WinINet 換成 libcurl只需要重寫 Fetcher隊(duì)列和線程邏輯一行不用動(dòng)想做斷點(diǎn)續(xù)抓在 SpiderCore 里加一個(gè)已抓集合就夠。我一般接手這類工程第一件事就是畫一張這樣的依賴圖確認(rèn)網(wǎng)絡(luò)層和 UI 層沒有直接握手再往下讀代碼。2.2 技術(shù)選型VC 環(huán)境下抓 HTML 的三種常見路子Windows 桌面上用 C 抓網(wǎng)頁繞不開三套東西WinINet、WinHTTP、libcurl。這個(gè)工程選的是 WinINet理由很實(shí)際MFC 對(duì)話框工程天然帶afxinet.hInternetOpenUrl一個(gè)函數(shù)調(diào)用就能拉起請(qǐng)求不需要額外集成第三方庫編譯環(huán)境干凈對(duì)個(gè)人抓取工具來說功能完全夠用。方案優(yōu)點(diǎn)缺點(diǎn)適合場(chǎng)景WinINet系統(tǒng)自帶、API 簡(jiǎn)單、自動(dòng)讀系統(tǒng)網(wǎng)絡(luò)設(shè)置HTTP/2 支持有限、偏客戶端形態(tài)MFC 桌面抓取工具WinHTTP服務(wù)端場(chǎng)景和并發(fā)表現(xiàn)更強(qiáng)API 更底層要自己處理的細(xì)節(jié)更多Windows 服務(wù)、后端組件libcurl跨平臺(tái)、功能最全、協(xié)議支持完整需要配置 include/lib 路徑工程變重跨平臺(tái)爬蟲、需要雙向認(rèn)證等高級(jí)特性選 WinINet 還有一個(gè)細(xì)節(jié)抓取場(chǎng)景最怕拿到 IE 緩存里的舊頁面WinINet 的INTERNET_FLAG_RELOAD | INTERNET_FLAG_NO_CACHE_WRITE組合正好解決這個(gè)問題強(qiáng)制重新拉取并且不寫緩存。WinHTTP 也有類似標(biāo)志但寫起來比 WinINet 繁瑣不少。對(duì)這個(gè)項(xiàng)目來說少引入一個(gè)第三方庫就少一類版本沖突問題編譯不過的概率低很多。WinINet 有個(gè)天生的限制要提前知道它的會(huì)話和 IE 共享一部分緩存和代理設(shè)置所以在做高頻抓取時(shí)不建議在一個(gè)進(jìn)程里反復(fù)創(chuàng)建銷毀 HINTERNET 會(huì)話句柄最好復(fù)用。這個(gè)工程的做法是在 SpiderCore 啟動(dòng)時(shí)創(chuàng)建一次會(huì)話所有工作線程共用抓完關(guān)閉。后面 3.3 節(jié)的代碼里也能看到這個(gè)思路。2.3 生產(chǎn)者-消費(fèi)者模型與線程編排整個(gè)程序運(yùn)行起來就是一條典型的生產(chǎn)者-消費(fèi)者流水線。主線程UI是生產(chǎn)者用戶在編輯框里粘貼一批 URL點(diǎn)開始后SpiderCore 把每行解析出來逐條 Push 進(jìn) UrlQueue。N 個(gè)工作線程是消費(fèi)者搶到一個(gè) URL 就做一次 請(qǐng)求 → 解析 → 落盤 → 通知主線程然后繼續(xù)搶下一個(gè)。這里有兩個(gè)關(guān)鍵設(shè)計(jì)。第一個(gè)是任務(wù)信號(hào)的傳遞隊(duì)列不能只有鎖還得有一個(gè)事件對(duì)象Push 的時(shí)候 SetEvent 喚醒等待中的線程否則線程只能靠輪詢空轉(zhuǎn)會(huì)白白耗 CPU。第二個(gè)是退出協(xié)議停止按鈕做的事不是強(qiáng)行殺掉線程而是把 m_bExit 置 TRUE 并 SetEvent讓每個(gè)線程在處理完手頭 URL 后自己檢查退出條件。這段邏輯放在 3.2 節(jié)是整份代碼里最值得細(xì)讀的部分。線程數(shù)量一般默認(rèn) 4 到 8。不是越大越好因?yàn)樽ト∑款i通常在網(wǎng)絡(luò) IO 和對(duì)端服務(wù)器的承受能力而不是本地 CPU。線程開多了反而會(huì)被目標(biāo)站點(diǎn)限流這個(gè)問題會(huì)在 4.4 節(jié)展開。把這套模型想清楚抓取工具的核心骨架就有了后面所有功能都是往這條流水線上掛東西。3. 核心代碼拆解一個(gè) URL 從入隊(duì)到 HTML 落盤的完整鏈路3.1 線程安全的 URL 隊(duì)列CUrlQueue隊(duì)列是多線程抓取的第一個(gè)共享資源所有工作線程都從這里取任務(wù)所以鎖和容器必須綁在一起封裝而不是在 SpiderCore 里散著放一個(gè) CList。如果鎖在外面很容易出現(xiàn)某個(gè)線程 Push 時(shí)忘了加鎖、另一個(gè)線程又在 Pop 的場(chǎng)景臨界區(qū)就形同虛設(shè)。// UrlQueue.h - 線程安全的 URL 隊(duì)列 #pragma once #include afxwin.h class CUrlQueue { public: CUrlQueue() { InitializeCriticalSection(m_cs); } ~CUrlQueue() { DeleteCriticalSection(m_cs); } void Push(const CString strUrl) { EnterCriticalSection(m_cs); // 入隊(duì)必須持鎖 m_listUrl.AddTail(strUrl); LeaveCriticalSection(m_cs); } BOOL Pop(CString strUrl) { BOOL bRet FALSE; EnterCriticalSection(m_cs); if (!m_listUrl.IsEmpty()) { strUrl m_listUrl.GetHead(); m_listUrl.RemoveHead(); bRet TRUE; } LeaveCriticalSection(m_cs); return bRet; } int GetCount() { int nCount 0; EnterCriticalSection(m_cs); nCount m_listUrl.GetCount(); LeaveCriticalSection(m_cs); return nCount; } private: CListCString, CString m_listUrl; // MFC 鏈表容器 CRITICAL_SECTION m_cs; // 臨界區(qū)對(duì)象 };三個(gè)方法的邏輯都不復(fù)雜但要注意兩個(gè)細(xì)節(jié)。一是 Pop 的返回值語義隊(duì)列為空時(shí)返回 FALSE調(diào)用方必須區(qū)分「隊(duì)列暫時(shí)沒任務(wù)」和「全部抓完」這個(gè)返回值是退出協(xié)議的一部分。二是持鎖時(shí)間要短Push 和 Pop 內(nèi)部只做鏈表操作絕不在鎖里面發(fā)起網(wǎng)絡(luò)請(qǐng)求或?qū)懳募駝t一個(gè)慢操作會(huì)把所有線程卡在同一把鎖上。這個(gè)封裝的調(diào)用方根本接觸不到鎖加鎖解鎖全部收斂在三個(gè)方法里是我處理共享容器的一貫習(xí)慣。真出了問題排查范圍也只在這一個(gè)文件里不用去幾十個(gè)調(diào)用點(diǎn)找哪處忘了 LeaveCriticalSection。3.2 工作線程事件驅(qū)動(dòng)的主循環(huán)與退出協(xié)議線程入口用 AfxBeginThread 拉起每個(gè)線程跑同一個(gè) FetchLoop。這個(gè)循環(huán)的設(shè)計(jì)直接影響程序能不能干凈退出是整份源碼里最容易寫錯(cuò)的地方。// SpiderCore.cpp - 啟動(dòng)工作線程 void CSpiderCore::Start(int nThreadCount) { m_bExit FALSE; // 手動(dòng)重置事件有任務(wù)到達(dá)或需要喚醒線程時(shí)觸發(fā) m_hEventData CreateEvent(NULL, TRUE, FALSE, NULL); for (int i 0; i nThreadCount; i) { // CREATE_SUSPENDED 先掛起拿到指針后再恢復(fù)避免線程搶先跑 CWinThread* pThread AfxBeginThread(FetchThreadProc, this, THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED); m_pThreads.push_back(pThread); pThread-ResumeThread(); } } // 線程入口轉(zhuǎn)發(fā) UINT CSpiderCore::FetchThreadProc(LPVOID lpParam) { CSpiderCore* pCore (CSpiderCore*)lpParam; pCore-FetchLoop(); return 0; } // 線程主循環(huán) void CSpiderCore::FetchLoop() { while (TRUE) { // 超時(shí) 3 秒是為了讓線程周期性醒來檢查退出標(biāo)志 DWORD dwWait WaitForSingleObject(m_hEventData, 3000); // 退出條件收到退出指令并且隊(duì)列已經(jīng)清空 if (m_bExit m_queue.GetCount() 0) break; if (dwWait ! WAIT_OBJECT_0) continue; // 超時(shí)醒來回去繼續(xù)檢查 m_bExit CString strUrl; while (m_queue.Pop(strUrl)) // 一次把當(dāng)前隊(duì)列取完 { FetchAndSave(strUrl); // 請(qǐng)求 - 解析 - 落盤 } ResetEvent(m_hEventData); // 清掉任務(wù)信號(hào) // 防止 ResetEvent 把剛 SetEvent 的新任務(wù)信號(hào)誤清掉 // 清完后如果隊(duì)列又有數(shù)據(jù)直接回到循環(huán)頭部繼續(xù)取 if (m_queue.GetCount() 0) continue; } }這段主循環(huán)有兩個(gè)要點(diǎn)。第一退出條件是「m_bExit 為 TRUE 且隊(duì)列為空」兩者同時(shí)滿足不能只看 m_bExit。如果隊(duì)列里還有任務(wù)就退那批 URL 就丟了如果只看隊(duì)列為空就退那線程可能永遠(yuǎn)不會(huì)結(jié)束。第二WaitForSingleObject 的 3 秒超時(shí)不是給抓取限速用的它存在的意義是讓線程在事件永遠(yuǎn)不觸發(fā)的情況下也能醒來檢查退出標(biāo)志——否則停止按鈕按下后線程會(huì)一直阻塞在等待上進(jìn)程退不干凈。信號(hào)量這里有個(gè)常見的糾結(jié)ResetEvent 和 Push 里的 SetEvent 存在競(jìng)爭(zhēng)可能把新任務(wù)信號(hào)誤清掉導(dǎo)致任務(wù)在隊(duì)列里躺到下一個(gè) 3 秒超時(shí)。代碼里在 ResetEvent 之后又檢查了一次隊(duì)列計(jì)數(shù)并 continue把最壞情況壓縮到幾乎不發(fā)生。這是手動(dòng)重置事件和自動(dòng)重置事件之間權(quán)衡后的方案邏輯稍繞但比自動(dòng)重置事件在 8 個(gè)線程下漏喚醒要可靠。3.3 請(qǐng)求封裝CFetcher 與狀態(tài)碼校驗(yàn)抓取線程真正干活的地方是 FetchAndSave它先調(diào) CFetcher 發(fā)請(qǐng)求拿到 HTML 原始字節(jié)再做編碼轉(zhuǎn)換和落盤。Fetcher 是整個(gè)工程里最獨(dú)立的模塊完全不知道多線程的存在這也是它能被替換的前提。// Fetcher.cpp - 基于 WinINet 的 HTTP 請(qǐng)求封裝 #include afxinet.h #pragma comment(lib, wininet.lib) BOOL CFetcher::Fetch(const CString strUrl, CStringA strRaw, int nStatus, CString strContentType) { // 1. 創(chuàng)建會(huì)話句柄 HINTERNET hSession InternetOpen( _T(Mozilla/5.0 (Windows NT 10.0; Win64; x64) SpiderDemo/1.0), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); if (!hSession) return FALSE; // 2. 打開 URL強(qiáng)制刷新且不寫緩存 HINTERNET hFile InternetOpenUrl(hSession, strUrl, NULL, 0, INTERNET_FLAG_RELOAD | INTERNET_FLAG_NO_CACHE_WRITE, 0); if (!hFile) { InternetCloseHandle(hSession); return FALSE; } // 3. 取 HTTP 狀態(tài)碼非 200 直接判失敗 DWORD dwStatus 0; DWORD dwSize sizeof(dwStatus); HttpQueryInfo(hFile, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER, dwStatus, dwSize, NULL); nStatus (int)dwStatus; if (dwStatus ! 200) { InternetCloseHandle(hFile); InternetCloseHandle(hSession); return FALSE; } // 4. 取 Content-Type后面編碼探測(cè)要用 TCHAR szType[128] { 0 }; DWORD dwTypeLen 128; HttpQueryInfo(hFile, HTTP_QUERY_CONTENT_TYPE, szType, dwTypeLen, NULL); strContentType szType; // 5. 分塊讀響應(yīng)體 char szBuf[8192] { 0 }; DWORD dwRead 0; while (InternetReadFile(hFile, szBuf, sizeof(szBuf), dwRead) dwRead 0) { strRaw.Append(szBuf, dwRead); dwRead 0; // 每次循環(huán)清零防止最后一次殘留舊值 } InternetCloseHandle(hFile); InternetCloseHandle(hSession); return TRUE; }分塊讀是這里最值得講的地方。InternetReadFile 的行為是在一次調(diào)用里返回盡可能多的數(shù)據(jù)但不會(huì)超過緩沖區(qū)大小所以必須用循環(huán)讀到 dwRead 為 0 為止。8192 字節(jié)的緩沖區(qū)是速度與內(nèi)存的折中對(duì)普通 HTML 頁面來說一次循環(huán)能裝下大半個(gè)頁面也不至于讓棧壓力過大。狀態(tài)碼校驗(yàn)是很多入門抓取翻車的重災(zāi)區(qū)。InternetOpenUrl 返回句柄只代表 TCP 連接建立成功不代表頁面真的存在404 頁面照樣會(huì)返回一段正文。HttpQueryInfo 取到的 HTTP_QUERY_STATUS_CODE 才是服務(wù)器真實(shí)意圖這里只放行 200其余狀態(tài)全部走失敗分支。默認(rèn)情況下 InternetOpenUrl 會(huì)自動(dòng)跟隨 301/302 重定向所以最終拿到的狀態(tài)碼一般是落地頁的不需要自己處理 Location 頭。還有一個(gè)細(xì)節(jié)Fetcher 返回的是 CStringA 原始字節(jié)而不是直接轉(zhuǎn)好的 CString。這是故意的——編碼探測(cè)在 3.4 節(jié)做Fetcher 只負(fù)責(zé)把字節(jié)原樣拿回來職責(zé)單一轉(zhuǎn)換邏輯集中在 HtmlParser 里避免兩個(gè)模塊各轉(zhuǎn)一遍導(dǎo)致行為不一致。3.4 字符集探測(cè)與統(tǒng)一落盤抓回來的 HTML 是字節(jié)流要正確顯示必須先知道它的字符集。老站點(diǎn)大量是 GBK/GB2312新站多是 UTF-8如果統(tǒng)一按 UTF-8 解碼GBK 頁面轉(zhuǎn)出來就是「錕斤拷」。正確順序是先探測(cè)、再轉(zhuǎn)換、最后統(tǒng)一以 UTF-8 落盤。// HtmlParser.cpp - 探測(cè)字符集 CString CHtmlParser::DetectCharset(const CStringA strHtml, const CString strContentType) { // 1. 優(yōu)先看響應(yīng)頭 Content-Type 里的 charset int nPos strContentType.Find(_T(charset)); if (nPos 0) { CString strCharset strContentType.Mid(nPos 8); strCharset.Trim(); return strCharset; } // 2. 再看 HTML 前部的 meta charset... // 只取前 1024 字節(jié)做匹配避免整個(gè)頁面轉(zhuǎn)小寫浪費(fèi)內(nèi)存 CStringA strHead strHtml.Left(1024); strHead.MakeLower(); CStringA strKey charset\; int nMetaPos strHead.Find(strKey); if (nMetaPos 0) { CStringA strValue strHead.Mid(nMetaPos strKey.GetLength(), 32); int nEnd strValue.Find(\); if (nEnd 0) return CString(strValue.Left(nEnd)); } return _T(utf-8); // 都找不到就按 UTF-8 兜底 } // 落盤原始編碼 - 寬字符 - UTF-8 BOOL SaveHtml(const CString strFile, const CStringA strRaw, const CString strCharset) { CFile file; if (!file.Open(strFile, CFile::modeCreate | CFile::modeWrite)) return FALSE; // GBK 等單字節(jié)編碼走 CP_ACPUTF-8 走 CP_UTF8 int nCodePage (_tcsicmp(strCharset, _T(gbk)) 0) ? CP_ACP : CP_UTF8; CStringW strW CA2W(strRaw, nCodePage); CStringA strOut CW2A(strW, CP_UTF8); // 統(tǒng)一轉(zhuǎn)成 UTF-8 保存 file.Write(strOut.GetString(), strOut.GetLength()); file.Close(); return TRUE; }探測(cè)優(yōu)先級(jí)要記牢響應(yīng)頭里的 Content-Type 最可信因?yàn)樗欠?wù)器在協(xié)議層面聲明的HTML 里的 meta 標(biāo)簽是頁面自己說的可能和實(shí)際編碼不一致都找不到才用 UTF-8 兜底。這里簡(jiǎn)化成了只匹配 charset 的形式實(shí)際工程里還會(huì)遇到 http-equiv 寫法比如meta http-equivContent-Type contenttext/html; charsetgb2312需要再加一個(gè)分支去解析 content 屬性。為什么落盤前要繞一圈轉(zhuǎn)成寬字符再轉(zhuǎn)回 UTF-8因?yàn)轫撁嬖甲止?jié)可能是 GBK直接以 UTF-8 方式落盤文件會(huì)保存錯(cuò)誤的字節(jié)序列先按正確代碼頁轉(zhuǎn)成 UTF-16 的 CStringW再轉(zhuǎn)成 UTF-8 輸出相當(dāng)于做了編碼歸一。這樣不管源站是 GBK 還是 UTF-8本地所有文件都是同一種編碼后面接解析、接入庫都不用再關(guān)心每個(gè)文件自己的編碼是什么。這段代碼用的是 CA2W/CW2A 轉(zhuǎn)換宏它會(huì)在棧上分配內(nèi)存對(duì)幾百 KB 的小頁面沒問題。如果你要抓幾 MB 的大頁面建議改用 MultiByteToWideChar 配合堆內(nèi)存避免棧溢出。這也是 Fetcher 用 CStringA 傳字節(jié)、把轉(zhuǎn)換推遲到這個(gè)環(huán)節(jié)的好處——轉(zhuǎn)換策略隨時(shí)可以換不影響請(qǐng)求層。4. 多線程抓取避坑記錄假死、亂碼、被封的排查實(shí)錄這一章是我實(shí)際跑這個(gè)工程時(shí)踩過的坑每條都是真實(shí)翻車現(xiàn)場(chǎng)?，F(xiàn)象、原因、解決三段式寫清楚不一定全記住但遇到類似癥狀時(shí)知道往哪個(gè)方向查。4.1 現(xiàn)象點(diǎn)開始沒幾秒整個(gè)程序假死抓取線程里直接調(diào)用 m_listResult.AddString 或者 SetDlgItemText 去刷新界面結(jié)果運(yùn)行幾秒后窗口完全卡死任務(wù)管理器看到 CPU 某個(gè)核接近 100%。原因MFC 的 CWnd 方法不是線程安全的。AddString 底層會(huì)向窗口發(fā)送消息多個(gè)工作線程同時(shí)操作同一個(gè)控件內(nèi)部鏈表和 UI 線程自己的消息處理互相踩窗口消息隊(duì)列就被鎖死了。這不是偶發(fā)的線程越多越容易觸發(fā)。解決抓取線程一律不碰 UI。抓完一條就 PostMessage 一條自定義消息由主窗口在自己的消息處理函數(shù)里刷新列表。我在 SpiderCore 里留了一個(gè)通知窗口句柄線程完事后這樣投遞// 工作線程中只投遞消息不直接操作控件 ::PostMessage(pCore-m_hWndNotify, WM_SPIDER_RESULT, bOK ? 1 : 0, (LPARAM)new CString(strUrl));wParam 帶成功失敗標(biāo)志lParam 帶一個(gè)堆上 new 出來的 CString 指針UI 側(cè)收到消息后取出來刷新日志并 delete。用 new 是因?yàn)?PostMessage 是異步的不能傳棧上地址。從那以后我寫多線程抓取第一行注釋就是「線程內(nèi)禁止碰任何控件」。4.2 現(xiàn)象抓到一堆 404 和攔截頁面日志里卻全標(biāo)成功一批 URL 抓完成功數(shù)很高打開文件一看全是對(duì)應(yīng)錯(cuò)誤頁的 HTML或者正文只有一小段提示腳本。原因只判斷 InternetOpenUrl 返回了句柄沒查 HTTP 狀態(tài)碼。服務(wù)器對(duì) 404、503 一樣會(huì)正常建立連接并返回正文連接成功不代表內(nèi)容有效。另一類是反爬返回 200但正文是驗(yàn)證或攔截腳本。解決兩層校驗(yàn)。第一層是 3.3 節(jié)的 HttpQueryInfo 狀態(tài)碼判斷非 200 全部算失敗。第二層是正文兜底校驗(yàn)——統(tǒng)計(jì) html 和 標(biāo)簽是否成對(duì)正文長度是否超過一個(gè)最小閾值比如少于 500 字節(jié)直接判無效。我一般把最小正文長度定義成一個(gè)常量每頁抓完先過這道關(guān)卡再落盤能擋掉大部分「假成功」。4.3 現(xiàn)象頁面抓到本地打開全是亂碼文件確實(shí)存下來了但內(nèi)容顯示成「錕斤拷」「燙燙燙」之類的亂碼或者英文字符正常、中文全花。原因頁面編碼和轉(zhuǎn)換代碼頁不一致。老一點(diǎn)的內(nèi)容站點(diǎn)大量是 GBK 編碼如果 Fetcher 里統(tǒng)一按 UTF-8 解釋字節(jié)GBK 的中文字節(jié)序列就會(huì)被錯(cuò)誤解析轉(zhuǎn)出來的寬字符自然全錯(cuò)。解決按 3.4 節(jié)的順序做字符集探測(cè)先看響應(yīng)頭再看 meta最后才兜底。血淚經(jīng)驗(yàn)是不要相信所有服務(wù)器都會(huì)在響應(yīng)頭里返回 charset相當(dāng)一部分老站只寫了 HTML meta還有一部分站 meta 寫的是 utf-8實(shí)際內(nèi)容是 GBK這種只能靠抓下來的字節(jié)做啟發(fā)式判斷。最笨但有效的兜底是先按 GBK 轉(zhuǎn)一次看轉(zhuǎn)換后是否出現(xiàn)大量無法映射的字符是的話再換 UTF-8 重轉(zhuǎn)。4.4 現(xiàn)象線程數(shù)調(diào)大抓取速度沒上去反而被斷開連接從 4 線程調(diào)成 16 線程速度非但沒翻倍還開始大量超時(shí)日志里陸續(xù)出現(xiàn) 403 和 429最后直接被目標(biāo)服務(wù)器掐斷連接。原因服務(wù)器有連接頻率限制。16 個(gè)線程同時(shí)往同一個(gè)域名打請(qǐng)求相當(dāng)于同一秒內(nèi)發(fā)起十幾次連接站點(diǎn)的防護(hù)邏輯直接判定異常流量。抓取是 IO 密集型不是計(jì)算密集型線程數(shù)超過網(wǎng)絡(luò)瓶頸后只會(huì)加劇限流。解決加兩個(gè)節(jié)流手段。一是每個(gè)線程抓完一條后隨機(jī) Sleep 一段可配置的時(shí)間比如 300 到 800 毫秒讓請(qǐng)求波形打散而不是整齊地一排出去。二是按域名拆分隊(duì)列同一個(gè)域名最多分配 2 個(gè)線程把并發(fā)壓力分?jǐn)偟讲煌军c(diǎn)。遇到 403/429 時(shí)做退避該域名 30 秒內(nèi)不再發(fā)起請(qǐng)求。這兩個(gè)手段加到工程里都不復(fù)雜但能把抓取成功率從 60% 拉回 95% 以上。4.5 現(xiàn)象點(diǎn)了停止界面響應(yīng)了但進(jìn)程一直退不干凈停止按鈕執(zhí)行后窗口能關(guān)但進(jìn)程在任務(wù)管理器里掛著一兩個(gè)線程不消失或者進(jìn)程退了但日志文件還沒寫完。原因m_bExit 置位后線程還阻塞在 InternetReadFile 等網(wǎng)絡(luò)調(diào)用上沒有設(shè)置超時(shí)阻塞可能長達(dá)幾十秒或者對(duì)話框收到 WM_CLOSE 后直接退出沒等線程收尾就銷毀了資源和文件句柄。解決兩件事都要做。一是給 InternetReadFile 設(shè)置操作超時(shí)常見做法是先用 InternetSetOption 設(shè)置 INTERNET_OPTION_RECEIVE_TIMEOUT 和 CONNECT_TIMEOUT把阻塞上限控制住讓線程能及時(shí)醒來看到退出標(biāo)志。二是在對(duì)話框的 OnDestroy 里遍歷工作線程句柄對(duì)每個(gè)線程 WaitForSingleObject 一小段時(shí)間確認(rèn)線程真正結(jié)束后再釋放隊(duì)列和事件對(duì)象。這里切忌用 TerminateThread 強(qiáng)殺它會(huì)跳過析構(gòu)、不釋放鎖留下一個(gè)處于鎖定狀態(tài)的臨界區(qū)下次啟動(dòng)必崩。5. 跑通與二次開發(fā)編譯調(diào)試、斷點(diǎn)續(xù)抓與入庫改造5.1 編譯與運(yùn)行驗(yàn)證工程用 VS2015 及以上打開即可字符集建議設(shè)成 Unicode——代碼里 CString 默認(rèn)按寬字符處理轉(zhuǎn)碼邏輯依賴_T宏和 CA2W/CW2A多字節(jié)字符集下這些地方的行為會(huì)不一樣。依賴只有系統(tǒng)庫不需要安裝任何第三方包。運(yùn)行驗(yàn)證按四步走準(zhǔn)備一個(gè) urls.txt每行一個(gè) URL填入對(duì)話框線程數(shù)先填 4點(diǎn)開始后觀察日志逐條增長輸出目錄下生成同名 HTML 文件。重點(diǎn)檢查三件事抓取條數(shù)和文件數(shù)一致、頁面無亂碼、停止后進(jìn)程能正常退出。我每次會(huì)用本地起的測(cè)試服務(wù)先跑一遍確認(rèn)邏輯沒問題再對(duì)真實(shí)站點(diǎn)操作。5.2 三個(gè)實(shí)用的改造切入點(diǎn)第一個(gè)是 BFS 擴(kuò)散抓取在 HtmlParser 里提取a href鏈接通過 Push 再入隊(duì)抓取就會(huì)從單頁變成整站爬取。注意在 Push 前要加去重集合我用 CMapStringToPtr 存已抓過的 URL8 個(gè)線程并發(fā)時(shí)同一鏈接一旦重復(fù)入隊(duì)訪問量就放大 8 倍。第二個(gè)是結(jié)果入庫把落盤文件改成寫 SQLite。sqlite3 是 C API封裝一個(gè) CSqliteSaver每抓完一條做一次 INSERT表的字段至少要覆蓋 url、title、http_status、fetched_at、content 這五列。多條線程同時(shí)寫 SQLite 時(shí)建議先寫進(jìn)一個(gè)內(nèi)存隊(duì)列由單條線程批量提交減少事務(wù)次數(shù)和鎖沖突。第三個(gè)是線程模型升級(jí)把 AfxBeginThread 換成 std::thread 加 condition_variable讓 SpiderCore 不依賴 MFC抽成純 C 類之后移植到服務(wù)端或命令行工具都不用改業(yè)務(wù)邏輯。改造時(shí)保持 CUrlQueue 接口不變內(nèi)部把 CRITICAL_SECTION 換成 std::mutex 即可調(diào)用方完全無感。5.3 改造后的驗(yàn)證清單改動(dòng)后不要直接上 16 線程按照「單線程 → 4 線程 → 8 線程」逐級(jí)驗(yàn)證。每個(gè)階段確認(rèn)三件事抓取結(jié)果集合和單線程版本一致、內(nèi)存不隨時(shí)間線性增長、任務(wù)管理器里句柄數(shù)和 GDI 對(duì)象數(shù)穩(wěn)定。特別是句柄數(shù)——WinINet 的 HINTERNET 句柄忘記關(guān)閉是這類工程最常見的資源泄漏點(diǎn)跑 1000 個(gè) URL 前后對(duì)比一次就心里有數(shù)。從那以后我每次接手類似的 C 抓取工程都會(huì)強(qiáng)制先跑一遍「開始 → 停止 → 退出 → 查句柄」四個(gè)動(dòng)作確認(rèn)線程能干凈收?qǐng)鲈匍_始動(dòng)業(yè)務(wù)邏輯。這套習(xí)慣幫我擋掉了好幾次線程泄漏和假死問題。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取