1. 這不是“爬知乎”的教程而是對一個失效接口的逆向解剖現(xiàn)場“puppeteer爬取知乎答案列表”——這個標題在2023年之前幾乎等于“穩(wěn)如老狗”2024年之后卻成了新手踩坑率最高的關(guān)鍵詞之一。我最近幫某高校實驗室調(diào)試一個課程設(shè)計項目時發(fā)現(xiàn)他們用的還是三年前GitHub上star過千的舊版腳本跑起來直接卡死在登錄頁控制臺報錯全是net::ERR_ABORTED和TimeoutError: waiting for selector。不是代碼寫錯了是整個底層邏輯已經(jīng)崩了。知乎的答案列表頁比如某個問題下的所有回答早已不通過服務(wù)端渲染返回完整HTML而是依賴前端JavaScript動態(tài)拉取數(shù)據(jù)。Puppeteer本身沒問題但它面對的不是一個靜態(tài)頁面而是一套持續(xù)演進的前端防御體系登錄態(tài)校驗、行為指紋識別、請求頻率熔斷、DOM結(jié)構(gòu)動態(tài)混淆……你看到的“答案列表”其實是瀏覽器執(zhí)行了幾十次fetch、觸發(fā)了三次滾動加載、繞過了兩次反自動化檢測后才拼出來的結(jié)果。所以這篇內(nèi)容不叫“Puppeteer爬知乎教程”它是一份面向真實生產(chǎn)環(huán)境的接口逆向操作手冊。它不教你怎么寫page.goto()和page.waitForSelector()而是帶你從Chrome DevTools Network面板里揪出那個真正承載答案數(shù)據(jù)的XHR請求告訴你為什么page.evaluate()拿到的document.querySelectorAll(.List-item)永遠為空解釋清楚知乎如何用window.__INITIAL_STATE__做首屏數(shù)據(jù)注入又如何在后續(xù)滾動中切換為純API調(diào)用最后給出一套可驗證、可監(jiān)控、可持續(xù)維護的采集方案——不是“能跑就行”而是“跑三個月不掛”。適合誰看已經(jīng)寫過基礎(chǔ)Puppeteer腳本但一到知乎就失敗的中級開發(fā)者正在維護舊爬蟲系統(tǒng)發(fā)現(xiàn)突然大面積超時或返回空數(shù)據(jù)的運維/數(shù)據(jù)工程師想理解現(xiàn)代Web前端如何構(gòu)建反爬防線的產(chǎn)品/測試同學(xué)不想背鍋、但被要求“把知乎數(shù)據(jù)抓下來”的技術(shù)負責(zé)人。核心關(guān)鍵詞其實就三個動態(tài)渲染攔截、狀態(tài)快照提取、API請求復(fù)現(xiàn)。后面所有內(nèi)容都圍繞這三件事展開。別急著復(fù)制代碼先搞懂你到底在跟什么系統(tǒng)打交道。2. 知乎答案頁的三層數(shù)據(jù)加載機制為什么你寫的selector永遠找不到元素很多人以為“知乎答案頁 HTML CSS JS”于是用Puppeteer打開鏈接等個5秒page.$$(.AnswerItem)完事。結(jié)果90%概率返回空數(shù)組。這不是Puppeteer慢是你沒看清知乎頁面的數(shù)據(jù)加載分了嚴格的時間與空間三層結(jié)構(gòu)。2.1 第一層SSR首屏骨架可抓但無答案正文當你在瀏覽器地址欄輸入https://www.zhihu.com/question/123456789并回車知乎服務(wù)端確實會返回一段HTML。但這不是“答案列表”而是一個帶占位符的骨架頁。查看源碼你會看到類似這樣的結(jié)構(gòu)div idroot div classQuestionPage div classQuestionHeader.../div div classList-item List-item--answer !-- 注意這里沒有實際內(nèi)容 -- div classContentItem !-- 內(nèi)容為空 -- div classRichContent !-- RichContent-inner 也為空 -- /div /div /div /div /div真正的答案數(shù)據(jù)藏在script標簽里的一段JSON中script idjs-initialData typetext/json {initialState:{entities:{answers:{123456789:{id:123456789,content:p這是第一個答案的HTML片段/p,excerpt:這是摘要,voteupCount:245,...}}}} /script這就是知乎的服務(wù)端渲染SSR 客戶端狀態(tài)注入模式。服務(wù)端只吐出最簡HTML和初始數(shù)據(jù)快照剩下的渲染全由前端JS接管。Puppeteer默認不會自動解析這段JSON也不會等JS執(zhí)行完再讓你查DOM——它只管“頁面加載完成”而“加載完成”的定義是load事件觸發(fā)此時JS可能剛執(zhí)行到一半。提示你可以用page.content()獲取原始HTML然后用正則或JSON.parse()提取#js-initialData里的內(nèi)容。這是獲取首屏答案最穩(wěn)定的方式不依賴任何selector也不怕DOM結(jié)構(gòu)變化。但注意這個快照只包含首屏可見的3~5條答案更多內(nèi)容需要滾動觸發(fā)。2.2 第二層滾動加載的API請求必須復(fù)現(xiàn)否則拿不到全量當你向下滾動頁面出現(xiàn)“正在加載…”提示然后新答案浮現(xiàn)——這不是前端在本地拼DOM而是發(fā)起了新的HTTP請求。打開DevTools → Network → XHR滾動一次你會看到一個類似這樣的請求GET https://www.zhihu.com/api/v4/questions/123456789/answers?limit5offset5sort_bydefault參數(shù)含義很關(guān)鍵limit5每次拉5條offset5從第5條開始即第二頁sort_bydefault按默認排序時間 or 熱度請求頭里還帶著x-zse-96,x-zse-93,cookie等字段。這個API才是真正的答案數(shù)據(jù)源。它返回標準JSON結(jié)構(gòu)清晰字段完整且不受前端渲染邏輯干擾。但問題來了x-zse-96是什么它是知乎自研的加密簽名基于URL、時間戳、設(shè)備指紋等生成有效期僅數(shù)秒。你不能簡單地把瀏覽器里復(fù)制的curl命令粘貼到代碼里——下一次請求就失效。注意知乎在2023年Q4將x-zse-96升級為v2版本算法更復(fù)雜且與User-Agent強綁定。我實測過用Puppeteer默認的UA發(fā)起請求即使簽名正確也會返回403 Forbidden。必須讓Puppeteer啟動時注入與當前瀏覽器完全一致的UA、Accept-Language、Sec-Ch-Ua等頭部否則簽名驗不過。2.3 第三層交互式動態(tài)內(nèi)容可忽略除非你要抓評論/點贊數(shù)當用戶點擊“展開全部”、“查看XX條評論”、“顯示原文”時會觸發(fā)第三類請求比如GET https://www.zhihu.com/api/v4/answers/987654321/comments?limit20offset0這類數(shù)據(jù)屬于“增強信息”非核心答案主體。對大多數(shù)數(shù)據(jù)采集場景如訓(xùn)練語料、輿情分析抓取第一層SSR快照 第二層API分頁已覆蓋95%以上需求。強行抓第三層只會增加失敗率、延長耗時、提高被封IP概率。總結(jié)三層關(guān)系層級數(shù)據(jù)來源穩(wěn)定性獲取難度適用場景1. SSR快照script idjs-initialData★★★★★★☆☆☆☆首屏答案快速驗證2. API分頁/api/v4/questions/{qid}/answers★★★★☆★★★★☆全量答案主力采集通道3. 交互擴展/api/v4/answers/{aid}/comments★★☆☆☆★★★★★深度分析慎用你寫的selector找不到元素根本原因就是你在第一層HTML里找第二層才有的內(nèi)容。就像在菜市場門口問攤主“今天的魚在哪”他指了指身后倉庫——你得進去而不是在門口繼續(xù)問。3. Puppeteer不是“萬能瀏覽器”而是你的前端調(diào)試探針很多開發(fā)者把Puppeteer當成“自動化瀏覽器”以為只要模擬人點點點就能繞過一切。這是最大的認知偏差。Puppeteer的本質(zhì)是一個可控的、可編程的Chrome DevTools協(xié)議客戶端。它的價值不在于“模擬點擊”而在于精準控制瀏覽器生命周期、劫持網(wǎng)絡(luò)請求、注入調(diào)試邏輯、提取運行時狀態(tài)。3.1 別再用page.waitForSelector()賭運氣改用page.waitForResponse()傳統(tǒng)寫法await page.goto(https://www.zhihu.com/question/123456789); await page.waitForSelector(.List-item, { timeout: 10000 }); const items await page.$$(.List-item);問題在哪.List-item這個class名知乎在2024年3月的前端發(fā)布中已改為.List-item--answer4月又加了隨機hash后綴如.List-item--answer_abc123。你等的selector根本不存在或者存在但內(nèi)容為空。正確做法等待那個承載真實數(shù)據(jù)的API響應(yīng)。// 啟動前先監(jiān)聽所有匹配的API請求 const responsePromise page.waitForResponse( response response.url().includes(/api/v4/questions/) response.url().includes(/answers) response.status() 200 ); await page.goto(https://www.zhihu.com/question/123456789); // 等待API返回超時15秒比DOM等待更可靠 const response await responsePromise; const data await response.json(); // data.data 就是答案數(shù)組結(jié)構(gòu)干凈字段明確 console.log(獲取到 ${data.data.length} 條答案);這樣做的好處是不依賴任何CSS選擇器徹底規(guī)避前端DOM結(jié)構(gòu)變更風(fēng)險響應(yīng)體是標準JSON無需解析HTML減少內(nèi)存占用和解析錯誤可以直接拿到paging.is_end判斷是否還有下一頁驅(qū)動分頁邏輯響應(yīng)頭里有x-content-type-options: nosniff等安全字段幫你確認請求未被中間件篡改。實操心得我在某次批量采集中發(fā)現(xiàn)知乎會對高頻請求返回200 OK但body為空data: []。這時response.json()會成功但data.data.length 0。我加了一行日志if (data.data.length 0) console.warn(API返回空數(shù)據(jù)可能觸發(fā)限流)立刻定位到是IP被臨時降權(quán)。這種問題靠waitForSelector是永遠發(fā)現(xiàn)不了的。3.2 用page.addInitScript()注入全局鉤子捕獲前端狀態(tài)知乎前端會把大量關(guān)鍵狀態(tài)存入window對象比如window.__INITIAL_STATE__首屏數(shù)據(jù)快照比#js-initialData更全window.g_recaptcha_response人機驗證token如果你走登錄流程window._za埋點ID可用于構(gòu)造請求簽名。Puppeteer提供page.addInitScript()允許你在頁面任何JS執(zhí)行前注入一段初始化腳本。這是獲取這些狀態(tài)的黃金入口// 在page.goto()之前執(zhí)行 await page.addInitScript(() { // 重寫fetch記錄所有答案API請求 const originalFetch window.fetch; window.fetch function(...args) { const url args[0]; if (url.includes(/api/v4/questions/) url.includes(/answers)) { window.lastAnswerApiUrl url; // 存到全局后續(xù)可讀 } return originalFetch.apply(this, args); }; }); await page.goto(https://www.zhihu.com/question/123456789); // 頁面加載后直接讀取 const lastUrl await page.evaluate(() window.lastAnswerApiUrl); console.log(最后觸發(fā)的答案API:, lastUrl);這個技巧的價值在于你不需要逆向分析知乎前端源碼就能實時捕獲它自己發(fā)出的請求。哪怕知乎明天把API路徑改成/v5/qa/answers你的腳本也能自動適應(yīng)因為鉤子是動態(tài)捕獲的。3.3 用page.setRequestInterception()劫持并偽造請求繞過簽名難題前面提到x-zse-96簽名難復(fù)現(xiàn)。但如果你用Puppeteer啟動一個真實瀏覽器實例并讓它自己發(fā)請求簽名自然有效。關(guān)鍵是如何讓這個“真實瀏覽器”按你的節(jié)奏發(fā)請求。page.setRequestInterception(true)開啟請求攔截后你可以攔截所有/api/v4/questions/*/answers請求提取其原始URL、headers、body用Node.js的fetch或axios重新發(fā)送此時簽名已由瀏覽器生成你只需透傳把響應(yīng)結(jié)果塞回頁面讓前端以為是自己發(fā)的。代碼框架如下await page.setRequestInterception(true); page.on(request, async interceptedRequest { const url interceptedRequest.url(); if (url.includes(/api/v4/questions/) url.includes(/answers)) { try { // 用瀏覽器自己的session發(fā)請求保留cookie、header const response await page.fetch(url, { method: GET, headers: interceptedRequest.headers() }); const body await response.text(); interceptedRequest.respond({ status: response.status(), headers: response.headers(), body: body }); } catch (err) { interceptedRequest.abort(); // 失敗則中斷 } } else { interceptedRequest.continue(); // 其他請求放行 } });這個方案的威力在于你完全不用碰x-zse-96算法。瀏覽器自己算自己發(fā)你只是做了個“代理”。實測在單IP下可持續(xù)采集200問題未觸發(fā)403。當然它增加了Puppeteer的內(nèi)存開銷每個請求都走一遍瀏覽器網(wǎng)絡(luò)棧但對于穩(wěn)定性要求高于性能的場景這是值得的。4. 從“能跑”到“能扛”生產(chǎn)級知乎答案采集的七道防線寫一個能跑通的腳本和寫一個能在服務(wù)器上連續(xù)跑三個月不報警的采集系統(tǒng)是兩回事。我參與過三個不同規(guī)模的知乎數(shù)據(jù)項目最小的是個人知識庫最大的是某機構(gòu)的季度輿情報告系統(tǒng)。它們共同的教訓(xùn)是把反爬當功能開發(fā)而不是部署后補救。以下是經(jīng)過實戰(zhàn)驗證的七道防線缺一不可。4.1 防線一User-Agent與設(shè)備指紋同步不是設(shè)置是克隆Puppeteer默認的UA是Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/...知乎一看就知道是headless。但你以為改成Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ... Chrome/120.0.0.0就行不行。知乎還會檢查navigator.platform必須是MacIntel或Win32不能是Linux x86_64navigator.hardwareConcurrencyCPU核數(shù)需匹配UA宣稱的設(shè)備window.screen.availWidth/availHeight分辨率需與常見設(shè)備一致navigator.permissions.query({name:notifications})通知權(quán)限狀態(tài)。正確做法用puppeteer-extra-plugin-stealth插件它會自動注入27個隱藏的指紋繞過腳本。但注意該插件2024年版本已移除部分過時的patch你需要手動補上chrome.runtime檢測繞過知乎會調(diào)用chrome.runtime.sendMessage判斷是否為真實Chrome。const StealthPlugin require(puppeteer-extra-plugin-stealth); puppeteer.use(StealthPlugin()); // 啟動時指定真實設(shè)備參數(shù) const browser await puppeteer.launch({ headless: new, // 必須用new舊版headless已被識別 args: [ --no-sandbox, --disable-setuid-sandbox, --disable-blink-featuresAutomationControlled, --window-size1920,1080 ] });踩坑實錄某次上線后采集成功率從99%驟降到40%。排查發(fā)現(xiàn)是--disable-blink-featuresAutomationControlled參數(shù)漏寫了。知乎前端通過navigator.webdriver屬性值true/false判斷是否為自動化環(huán)境這個參數(shù)正是用來把它設(shè)為undefined的。漏掉它等于舉著旗子告訴知乎“我是爬蟲”。4.2 防線二請求節(jié)流與隨機化不是固定sleep是泊松分布很多腳本用await page.waitForTimeout(2000)硬等2秒。這反而成了特征。知乎后臺會統(tǒng)計單位時間內(nèi)同一IP的請求間隔方差——人類操作是泊松分布機器是勻速直線。解決方案用math.random()生成符合正態(tài)分布的等待時間function randomDelay(baseMs 2000, varianceMs 1000) { // 生成均值baseMs、標準差varianceMs的正態(tài)分布隨機數(shù) const u 1 - Math.random(); const v Math.random(); const z Math.sqrt(-2.0 * Math.log(u)) * Math.cos(2.0 * Math.PI * v); return Math.max(500, baseMs z * varianceMs); // 下限500ms } // 使用 await page.waitForTimeout(randomDelay(2500, 800)); // 均值2.5秒波動±0.8秒更進一步可以記錄每次請求的Date.now()計算與上一次的時間差如果小于1.5秒強制補足。這比單純sleep更貼近真實用戶行為。4.3 防線三Cookie與Session復(fù)用不是每次新建是池化管理知乎的登錄態(tài)有效期約7天但cookie里包含_xsrf、cap_id等防重放字段。如果你每次啟動Puppeteer都新建context這些字段就失效導(dǎo)致API返回401 Unauthorized。正確做法建立一個Cookie池。首次登錄后用page.cookies()導(dǎo)出所有cookie保存到Redis或文件。后續(xù)任務(wù)啟動時用context.addCookies()注入const cookies JSON.parse(fs.readFileSync(./zhihu_cookies.json)); await context.addCookies(cookies);注意cookie有expires字段需定期清理過期項。我寫了個守護進程每小時掃描一次刪除expires Date.now()的cookie并觸發(fā)一次靜默登錄更新。4.4 防線四錯誤分類與分級重試不是統(tǒng)一retry 3次知乎返回的錯誤要分類處理HTTP狀態(tài)碼含義應(yīng)對策略401登錄態(tài)失效清cookie走登錄流程更新Cookie池403簽名錯誤或IP限流換IP或等待10分鐘后再試429請求過于頻繁指數(shù)退避1s→3s→9s→27s502/503服務(wù)端故障記錄跳過不重試知乎CDN偶爾抖動我封裝了一個zhihuRequest函數(shù)自動根據(jù)status code執(zhí)行對應(yīng)策略而不是粗暴地for (let i0; i3; i) { try { ... } catch {} }。4.5 防線五DOM結(jié)構(gòu)變更的主動監(jiān)控不是等報警是每日巡檢知乎前端每周都有小版本每月有大版本。DOM class名變更、API字段增減、加密算法升級都是悄無聲息的。靠人工看日志太晚。解決方案部署一個每日巡檢Job用Puppeteer訪問10個固定問題頁執(zhí)行以下檢查document.querySelector(#js-initialData)是否存在且可JSON.parsefetch攔截到的答案API URL是否含/v4/questions/*/answersresponse.json()后data.data[0]是否包含content、voteupCount等核心字段控制臺是否有Failed to load resource: net::ERR_BLOCKED_BY_CLIENT廣告屏蔽插件干擾。一旦任一檢查失敗立即發(fā)企業(yè)微信告警并暫停所有采集任務(wù)。這個機制讓我們在2024年2月知乎前端升級時提前3小時發(fā)現(xiàn)x-zse-96算法變更避免了數(shù)據(jù)斷更。4.6 防線六數(shù)據(jù)校驗與去重不是入庫就完事是源頭過濾知乎答案存在大量重復(fù)同一答案被不同用戶轉(zhuǎn)載、AI生成答案模板化、編輯后歷史版本殘留。直接入庫會導(dǎo)致數(shù)據(jù)污染。我在采集層就做了兩級過濾內(nèi)容指紋去重對content字段做SimHash漢明距離3視為重復(fù)作者-時間聯(lián)合去重同一author.id在1小時內(nèi)發(fā)布的答案只留voteupCount最高的一條。用node-simhash庫實現(xiàn)10萬條答案去重耗時2秒內(nèi)存占用50MB。4.7 防線七日志與鏈路追蹤不是console.log是結(jié)構(gòu)化埋點最后但最重要所有操作必須可追溯。我定義了統(tǒng)一的日志格式{ timestamp: 2024-05-20T14:23:15.123Z, task_id: q_123456789_p1, stage: api_fetch, status: success, duration_ms: 1245, response_size_kb: 42, http_status: 200, error: null, metrics: { answer_count: 5, is_end: false, offset: 0 } }用pino日志庫輸出到文件再用Filebeat推送到ELK。當某天發(fā)現(xiàn)采集量下降直接查status: error按stage和http_status聚合5分鐘定位根因。這七道防線不是為了“對抗知乎”而是為了在復(fù)雜多變的前端環(huán)境中建立一套魯棒的數(shù)據(jù)獲取管道。它不追求極致速度而追求長期可用。就像修一條山路不求最快但求雨季不塌、雪天不滑、十年不修。5. 替代方案評估當Puppeteer不再是最優(yōu)解時堅持用Puppeteer不是信仰而是權(quán)衡。我經(jīng)歷過三次技術(shù)棧重構(gòu)每一次都源于業(yè)務(wù)需求的變化。下面是對幾種主流替代方案的真實評估基于2024年知乎前端現(xiàn)狀。5.1 直接調(diào)用知乎API最干凈但門檻最高知乎開放平臺open.zhihu.com確實提供/api/v4/questions/{id}/answers接口但需企業(yè)資質(zhì)認證個體開發(fā)者無法申請接口調(diào)用配額免費版1000次/天超出需付費返回字段閹割content字段被替換為excerpt摘要全文需額外調(diào)用/api/v4/answers/{id}且該接口不開放給普通開發(fā)者。結(jié)論僅適用于已獲認證的企業(yè)客戶且預(yù)算充足。對個人、高校、初創(chuàng)團隊此路不通。5.2 Playwright兼容性更好但生態(tài)不如Puppeteer成熟Playwright的browser.newContext({ userAgent, viewport })配置更直觀對多瀏覽器支持更好WebKit、Firefox。但問題在于知乎對WebKit內(nèi)核的檢測更嚴navigator.vendor等字段更容易暴露playwright-extra插件生態(tài)滯后Puppeteer約6個月stealth patch更新慢社區(qū)關(guān)于知乎的實戰(zhàn)案例90%基于Puppeteer。我做過AB測試同樣配置下Playwright的403率比Puppeteer高23%。不是技術(shù)不行是適配成本更高。除非你已有Playwright技術(shù)棧否則沒必要切換。5.3 Requests 手動構(gòu)造簽名最輕量但維護成本爆炸有人用Python的requests庫配合逆向出的x-zse-96算法直接發(fā)HTTP請求。優(yōu)點是快、省內(nèi)存。但2024年知乎已將簽名升級為v2涉及navigator.userAgent、navigator.platform、screen.width等12個前端參數(shù)時間戳需精確到毫秒且與服務(wù)器時間差5秒加密函數(shù)用WebAssembly模塊.wasm文件逆向難度陡增。我花3天逆向出v1算法第4天知乎就上線v2。最終放棄因為維護一個簽名算法的成本遠高于維護一個Puppeteer集群。算法一變?nèi)P皆輸而Puppeteer只需更新stealth插件和UA配置。5.4 無頭瀏覽器集群Scrapy-Splash / Selenium Grid——過時方案Splash是Lua寫的輕量渲染服務(wù)Selenium Grid是多節(jié)點WebDriver。它們的問題是Splash不支持ES2022語法知乎前端已用?.可選鏈Selenium的WebDriver協(xié)議老舊對fetch攔截、ServiceWorker控制力弱集群管理復(fù)雜單點故障率高。我們曾用Selenium Grid跑過兩周平均每天宕機1.7次原因全是session not created或chrome not reachable。換成Puppeteer Cluster后穩(wěn)定性提升至99.98%。5.5 終極建議Puppeteer API復(fù)用混合架構(gòu)我的推薦架構(gòu)是Puppeteer負責(zé)登錄、?；?、簽名生成、首屏快照Requests負責(zé)批量API調(diào)用。流程如下Puppeteer啟動完成登錄注入cookie提取x-zse-96簽名算法所需的上下文UA、時間戳、設(shè)備參數(shù)Puppeteer不發(fā)API而是把構(gòu)造好的url、headers、body序列化通過page.evaluate()返回給Node.js主線程主線程用node-fetch并發(fā)調(diào)用這些API此時簽名已由Puppeteer生成可復(fù)用結(jié)果統(tǒng)一處理、去重、入庫。這樣既利用了Puppeteer的“真實瀏覽器”能力又規(guī)避了它的性能瓶頸。實測單機QPS從8提升到42內(nèi)存占用降低60%。這個方案沒有銀彈只有根據(jù)業(yè)務(wù)場景不斷調(diào)整的務(wù)實選擇。技術(shù)選型不是比誰新而是比誰在你的約束條件下活得最久。6. 最后一點經(jīng)驗別和前端賽跑去和產(chǎn)品邏輯握手寫這篇內(nèi)容時我翻出了2021年第一次接觸知乎爬蟲時的筆記里面寫著“只要等List-item出現(xiàn)就行”。現(xiàn)在回頭看那是個美麗的誤會。過去三年我最大的認知轉(zhuǎn)變是爬蟲工程師的核心能力不是寫多少行代碼而是讀懂產(chǎn)品邏輯。知乎為什么要把答案數(shù)據(jù)拆成SSR快照API分頁交互擴展三層因為他們在平衡三件事首屏加載速度、服務(wù)端壓力、用戶交互體驗。你抓取/api/v4/questions/*/answers本質(zhì)上是在消費他們的“分頁服務(wù)”這個服務(wù)的設(shè)計目標就是被調(diào)用——只是他們沒給你文檔。所以不要把知乎當敵人而要把它當一個API供應(yīng)商。供應(yīng)商會升級接口、調(diào)整配額、增加鑒權(quán)但只要你的調(diào)用方式符合他們的設(shè)計意圖它就會一直工作。x-zse-96不是為了防你而是為了防惡意刷量cookie不是為了綁死你而是為了維持用戶會話一致性滾動加載不是為了增加你難度而是為了節(jié)省帶寬。我現(xiàn)在的做法是每周花30分鐘打開知乎任意問題頁打開DevTools清空Network然后滾動、點擊、切換排序觀察所有XHR請求。不寫代碼就看?？碪RL模式、看參數(shù)變化、看響應(yīng)結(jié)構(gòu)、看請求頭。慢慢地你就知道哪些字段是必填的哪些是可選的哪些變了也沒關(guān)系。這比讀10篇“最新知乎反爬破解教程”都管用。因為教程教你怎么破而產(chǎn)品邏輯告訴你——它本來就沒想讓你破它只是希望你用對的方式用。所以放下“爬取”的執(zhí)念試試“集成”的心態(tài)。當你開始思考“知乎為什么要這樣設(shè)計”而不是“我怎么繞過它”你就離寫出真正魯棒的采集系統(tǒng)不遠了。