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