：抓取公眾號歷史文章與閱讀量評論)
簡介這是一份基于 Node.js 的微信爬蟲項目源碼面向需要批量采集公眾號數(shù)據(jù)的開發(fā)者與數(shù)據(jù)分析人員通過 AnyProxy 中間人代理機制解析微信 HTTPS 請求可獲取文章正文、閱讀量、點贊量、在看數(shù)及評論等核心指標并支持抓取公眾號全部歷史文章鏈接。項目兼容 AnyProxy 4可運行于個人電腦或服務器并提供 Docker 部署方案使用前需準備 Node 8.8.1 以上、MongoDB 3.4.6 以上及 Redis 環(huán)境。壓縮包共 80 個文件約 1.13MB以 40 個 js 與 9 個 jsx 業(yè)務腳本為主體輔以 json 配置、html 模板、png/svg 圖標、woff2/ttf 等字體資源以及 Dockerfile、docker-compose.yml、證書與說明文檔前后端與代理規(guī)則模塊劃分清晰。目前已有 2627 人學習下載適合想研究代理抓包、數(shù)據(jù)落庫與爬蟲工程化的讀者參考復用。1. 公眾號歷史文章抓取從閱讀量到評論一套 JavaScript 爬蟲能拿到什么做公眾號內(nèi)容分析的人多半遇到過這種局面想復盤某個號三年的選題曲線后臺只能一頁頁翻想統(tǒng)計閱讀量中位數(shù)手動復制到表格里眼睛都花了。這個wechat_spider項目就是沖著這個痛點來的——用 JavaScript 寫的一套抓取工具目標是把公眾號的歷史文章鏈接、正文內(nèi)容、閱讀量、點贊量、評論一并拉下來。它適合做內(nèi)容運營分析、競品號監(jiān)測、選題庫搭建的從業(yè)者也適合想拿真實數(shù)據(jù)練手的數(shù)據(jù)方向同學。技術棧是 Node.js 加 JavaScript核心思路是模擬客戶端請求、解析返回結構、分頁遍歷最后落成結構化數(shù)據(jù)。下面按「它怎么跑起來、參數(shù)怎么調(diào)、哪里會翻車」的順序拆一遍。2. 環(huán)境搭建與請求鏈路Node.js 側要準備什么2.1 運行環(huán)境與依賴清單這套工具跑在 Node.js 上建議用 LTS 版本太老的版本對async/await和fetch支持不完整容易在并發(fā)請求那一步報奇怪的錯。依賴方面常見做法是axios負責 HTTP 請求、cheerio負責 HTML 解析、fs-extra負責文件寫入、p-limit控制并發(fā)數(shù)。這幾個包在 npm 上都能直接裝不需要額外編譯工具鏈。先把項目目錄初始化好裝依賴# 初始化項目生成 package.json npm init -y # 安裝核心依賴 npm install axios cheerio fs-extra p-limit # 如果要做定時任務再加一個 npm install node-cron裝完之后檢查node_modules里有沒有axios和cheerio這兩個目錄缺了說明網(wǎng)絡或鏡像源有問題換源重裝即可。這一步看著簡單但后面所有請求和解析都依賴它們裝不干凈后面全是玄學報錯。2.2 請求鏈路從公眾號入口到文章列表抓取的核心鏈路分三段第一段是拿到目標公眾號的文章列表入口第二段是翻頁遍歷歷史文章拿到每篇的鏈接第三段是逐篇請求詳情頁解析閱讀量、點贊和評論。第一段通常需要一個能定位到該公眾號的標識參數(shù)這個參數(shù)在公眾號主頁的請求里能找到具體字段名各版本可能不同常見做法是從主頁 URL 或返回的 JSON 里提取。下面是一個請求封裝的骨架把公共頭、超時、重試都收在一起const axios require(axios); // 創(chuàng)建帶默認配置的請求實例 const client axios.create({ timeout: 10000, // 單次請求超時 10 秒太短容易誤判失敗 headers: { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: application/json, text/plain, */* } }); // 帶重試的請求函數(shù)失敗后隔 1 秒重試最多 3 次 async function requestWithRetry(url, params {}, retries 3) { for (let i 0; i retries; i) { try { const res await client.get(url, { params }); return res.data; } catch (err) { if (i retries - 1) throw err; await new Promise(r setTimeout(r, 1000)); } } } module.exports { requestWithRetry };這段代碼里timeout設 10 秒是個經(jīng)驗值公眾號接口偶爾會慢設 3 秒會大量誤報失敗。重試間隔 1 秒是為了避開瞬時抖動重試次數(shù) 3 次足夠再多說明目標接口本身有問題硬重試沒意義。User-Agent必須帶不帶的話部分接口直接返回空數(shù)據(jù)這是最常見的翻車點之一。2.3 分頁遍歷與去重歷史文章列表是分頁返回的每頁條數(shù)有限需要循環(huán)請求直到?jīng)]有下一頁。這里要處理兩個問題一是翻頁游標或偏移量怎么傳二是重復文章怎么去重。常見做法是用一個Set存已抓到的文章 ID每次解析后先查重再入庫。const seen new Set(); // 已抓取的文章 ID 集合 async function fetchArticleList(accountId, maxPages 50) { const all []; let offset 0; const pageSize 20; for (let page 0; page maxPages; page) { const data await requestWithRetry(/api/article/list, { account_id: accountId, offset: offset, count: pageSize }); const list data?.articles || []; if (list.length 0) break; // 沒有數(shù)據(jù)了提前結束 for (const item of list) { if (seen.has(item.id)) continue; // 去重 seen.add(item.id); all.push(item); } offset pageSize; await new Promise(r setTimeout(r, 500)); // 每頁之間歇一下 } return all; }maxPages是保護性上限防止接口異常時無限循環(huán)。每頁之間停 500 毫秒是降低請求頻率太快容易觸發(fā)限流。offset的遞增方式取決于接口設計有的用游標cursor有的用頁碼page拿到實際返回后按字段調(diào)整。去重這步不能省翻頁過程中接口偶爾會返回重復項不去重最后統(tǒng)計閱讀量會偏高。3. 正文、閱讀量、點贊與評論的解析字段怎么取、結構怎么落3.1 詳情頁解析正文與互動數(shù)據(jù)拿到文章鏈接后逐篇請求詳情頁。正文一般在 HTML 的某個容器里用cheerio按選擇器提取閱讀量和點贊量有的在頁面內(nèi)嵌的 JS 變量里有的在單獨的接口返回中。常見做法是先用cheerio抓正文再用正則從頁面源碼里匹配閱讀量字段。const cheerio require(cheerio); function parseArticleDetail(html) { const $ cheerio.load(html); // 正文取內(nèi)容容器去掉腳本和樣式 const content $(#js_content).text().trim(); // 閱讀量、點贊量常藏在頁面腳本里用正則匹配 const readMatch html.match(/read_num[]?\s*[:]\s*[]?(\d)/); const likeMatch html.match(/like_num[]?\s*[:]\s*[]?(\d)/); return { content: content, readNum: readMatch ? parseInt(readMatch[1], 10) : 0, likeNum: likeMatch ? parseInt(likeMatch[1], 10) : 0 }; }#js_content是正文容器的常見 ID不同模板可能不同抓不到時先打印 HTML 看結構再改選擇器。正則里的read_num和like_num是字段名實際字段名以頁面源碼為準匹配不到就返回 0避免整條記錄失敗。正文用.text()會丟掉圖片和鏈接如果需要保留富文本改用.html()再單獨清洗。3.2 評論抓取分頁與嵌套結構評論通常是單獨接口按文章 ID 分頁拉取每條評論可能帶子評論。抓的時候要處理兩層分頁主評論翻頁和子評論展開。常見做法是先拉主評論再對每條有子評論的項發(fā)二次請求。async function fetchComments(articleId, maxPages 20) { const comments []; let page 1; while (page maxPages) { const data await requestWithRetry(/api/comment/list, { article_id: articleId, page: page, limit: 20 }); const list data?.comments || []; if (list.length 0) break; for (const c of list) { comments.push({ user: c.nickname, text: c.content, like: c.like_num || 0, time: c.create_time }); } page; await new Promise(r setTimeout(r, 300)); } return comments; }maxPages同樣做上限保護。評論接口對頻率更敏感間隔設 300 毫秒以上比較穩(wěn)。子評論如果也要就在主評論循環(huán)里判斷c.reply_count 0再發(fā)一次請求但要注意嵌套層級別無限展開設個深度上限。3.3 數(shù)據(jù)落盤JSON 與 CSV 兩種格式抓完的數(shù)據(jù)建議同時落 JSON 和 CSV。JSON 保留完整結構方便后續(xù)程序處理CSV 方便直接丟進表格軟件看。用fs-extra寫入const fs require(fs-extra); async function saveData(articles, outputDir ./output) { await fs.ensureDir(outputDir); // 目錄不存在就創(chuàng)建 // 完整數(shù)據(jù)存 JSON await fs.writeJson(${outputDir}/articles.json, articles, { spaces: 2 }); // 摘要字段存 CSV const header title,readNum,likeNum,url\n; const rows articles.map(a ${a.title},${a.readNum},${a.likeNum},${a.url} ).join(\n); await fs.writeFile(${outputDir}/summary.csv, header rows, utf8); }ensureDir保證目錄存在避免首次運行報錯。CSV 里標題和 URL 用雙引號包住防止內(nèi)容里的逗號破壞列結構。JSON 用spaces: 2格式化方便人工查看。數(shù)據(jù)量大時 CSV 拼接可能占內(nèi)存可以改成流式寫入但一般幾千篇以內(nèi)直接拼沒問題。4. 避坑與排查抓取過程中最容易翻車的五件事4.1 請求返回空數(shù)據(jù)或 403現(xiàn)象請求發(fā)出后返回空數(shù)組或 403 狀態(tài)碼。原因缺少必要的請求頭或請求頻率過高被臨時限制。解決補全User-Agent、Referer等頭降低并發(fā)數(shù)每頁之間加延時。如果持續(xù) 403說明該入口暫時不可用換時間段再試。4.2 閱讀量字段匹配不到現(xiàn)象正文能抓到但閱讀量和點贊量全是 0。原因字段名和正則不匹配或數(shù)據(jù)在異步加載的接口里而非頁面源碼。解決先打印完整 HTML 搜索read關鍵字定位真實字段名如果頁面源碼里沒有改用抓包工具找到對應接口單獨請求。4.3 翻頁死循環(huán)或漏抓現(xiàn)象程序一直翻頁不結束或中間漏掉幾頁。原因翻頁游標邏輯寫錯或接口在某一頁返回異常導致break提前觸發(fā)。解決打印每頁返回的條數(shù)和游標值確認遞增邏輯對異常返回做判斷區(qū)分「真的沒有下一頁」和「請求失敗」。4.4 評論抓取被限流現(xiàn)象評論抓到前幾頁后開始返回空或報錯。原因評論接口頻率限制比文章列表更嚴。解決把評論請求的間隔調(diào)到 500 毫秒以上并發(fā)降到 1必要時分批分時段抓。4.5 數(shù)據(jù)重復或統(tǒng)計偏差現(xiàn)象同一篇文章出現(xiàn)多次閱讀量統(tǒng)計偏高。原因翻頁過程中接口返回重復項去重沒做或做得不徹底。解決用文章 ID 做Set去重入庫前再查一次統(tǒng)計前先按 ID 去重再算中位數(shù)和均值。5. 進階技巧把抓取結果變成可復用的選題庫抓到數(shù)據(jù)只是第一步真正省時間的是把結果整理成能直接用的選題庫。我一般會做三件事按閱讀量分檔、按時間看趨勢、按關鍵詞聚類。分檔用簡單的分位數(shù)就行不用上復雜模型function analyzeArticles(articles) { // 按閱讀量排序后取分位數(shù) const sorted [...articles].sort((a, b) a.readNum - b.readNum); const q (p) sorted[Math.floor(sorted.length * p)]?.readNum || 0; const low q(0.25); // 25 分位 const mid q(0.5); // 中位數(shù) const high q(0.75); // 75 分位 // 分檔統(tǒng)計 const buckets { low: 0, mid: 0, high: 0 }; for (const a of articles) { if (a.readNum low) buckets.low; else if (a.readNum high) buckets.mid; else buckets.high; } return { low, mid, high, buckets }; }這段代碼把文章按閱讀量分成三檔q(0.25)是 25 分位值低于它的算低閱讀高于 75 分位的算高閱讀。分檔之后就能看出這個號的內(nèi)容基本盤在哪哪些選題屬于爆款區(qū)間。趨勢分析按月份分組算均值關鍵詞聚類用簡單的詞頻統(tǒng)計就夠不用上 NLP 模型。驗證抓取結果是否可靠我習慣抽三篇手動核對閱讀量和評論數(shù)對不上就回頭查解析邏輯。這個習慣是從一次翻車來的——當時正則匹配到了頁面里另一個同名字段導致所有閱讀量都偏大抽檢才發(fā)現(xiàn)。從那以后我每次抓完都強制走一遍抽檢三篇對不上就全量重跑。希望幫到你。本文還有配套的精品資源點擊獲取 JavaScript爬蟲實戰(zhàn)：抓取公眾號歷史文章與閱讀量評論
簡介這是一份基于 Node.js 的微信爬蟲項目源碼面向需要批量采集公眾號數(shù)據(jù)的開發(fā)者與數(shù)據(jù)分析人員通過 AnyProxy 中間人代理機制解析微信 HTTPS 請求可獲取文章正文、閱讀量、點贊量、在看數(shù)及評論等核心指標并支持抓取公眾號全部歷史文章鏈接。項目兼容 AnyProxy 4可運行于個人電腦或服務器并提供 Docker 部署方案使用前需準備 Node 8.8.1 以上、MongoDB 3.4.6 以上及 Redis 環(huán)境。壓縮包共 80 個文件約 1.13MB以 40 個 js 與 9 個 jsx 業(yè)務腳本為主體輔以 json 配置、html 模板、png/svg 圖標、woff2/ttf 等字體資源以及 Dockerfile、docker-compose.yml、證書與說明文檔前后端與代理規(guī)則模塊劃分清晰。目前已有 2627 人學習下載適合想研究代理抓包、數(shù)據(jù)落庫與爬蟲工程化的讀者參考復用。1. 公眾號歷史文章抓取從閱讀量到評論一套 JavaScript 爬蟲能拿到什么做公眾號內(nèi)容分析的人多半遇到過這種局面想復盤某個號三年的選題曲線后臺只能一頁頁翻想統(tǒng)計閱讀量中位數(shù)手動復制到表格里眼睛都花了。這個wechat_spider項目就是沖著這個痛點來的——用 JavaScript 寫的一套抓取工具目標是把公眾號的歷史文章鏈接、正文內(nèi)容、閱讀量、點贊量、評論一并拉下來。它適合做內(nèi)容運營分析、競品號監(jiān)測、選題庫搭建的從業(yè)者也適合想拿真實數(shù)據(jù)練手的數(shù)據(jù)方向同學。技術棧是 Node.js 加 JavaScript核心思路是模擬客戶端請求、解析返回結構、分頁遍歷最后落成結構化數(shù)據(jù)。下面按「它怎么跑起來、參數(shù)怎么調(diào)、哪里會翻車」的順序拆一遍。2. 環(huán)境搭建與請求鏈路Node.js 側要準備什么2.1 運行環(huán)境與依賴清單這套工具跑在 Node.js 上建議用 LTS 版本太老的版本對async/await和fetch支持不完整容易在并發(fā)請求那一步報奇怪的錯。依賴方面常見做法是axios負責 HTTP 請求、cheerio負責 HTML 解析、fs-extra負責文件寫入、p-limit控制并發(fā)數(shù)。這幾個包在 npm 上都能直接裝不需要額外編譯工具鏈。先把項目目錄初始化好裝依賴# 初始化項目生成 package.json npm init -y # 安裝核心依賴 npm install axios cheerio fs-extra p-limit # 如果要做定時任務再加一個 npm install node-cron裝完之后檢查node_modules里有沒有axios和cheerio這兩個目錄缺了說明網(wǎng)絡或鏡像源有問題換源重裝即可。這一步看著簡單但后面所有請求和解析都依賴它們裝不干凈后面全是玄學報錯。2.2 請求鏈路從公眾號入口到文章列表抓取的核心鏈路分三段第一段是拿到目標公眾號的文章列表入口第二段是翻頁遍歷歷史文章拿到每篇的鏈接第三段是逐篇請求詳情頁解析閱讀量、點贊和評論。第一段通常需要一個能定位到該公眾號的標識參數(shù)這個參數(shù)在公眾號主頁的請求里能找到具體字段名各版本可能不同常見做法是從主頁 URL 或返回的 JSON 里提取。下面是一個請求封裝的骨架把公共頭、超時、重試都收在一起const axios require(axios); // 創(chuàng)建帶默認配置的請求實例 const client axios.create({ timeout: 10000, // 單次請求超時 10 秒太短容易誤判失敗 headers: { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: application/json, text/plain, */* } }); // 帶重試的請求函數(shù)失敗后隔 1 秒重試最多 3 次 async function requestWithRetry(url, params {}, retries 3) { for (let i 0; i retries; i) { try { const res await client.get(url, { params }); return res.data; } catch (err) { if (i retries - 1) throw err; await new Promise(r setTimeout(r, 1000)); } } } module.exports { requestWithRetry };這段代碼里timeout設 10 秒是個經(jīng)驗值公眾號接口偶爾會慢設 3 秒會大量誤報失敗。重試間隔 1 秒是為了避開瞬時抖動重試次數(shù) 3 次足夠再多說明目標接口本身有問題硬重試沒意義。User-Agent必須帶不帶的話部分接口直接返回空數(shù)據(jù)這是最常見的翻車點之一。2.3 分頁遍歷與去重歷史文章列表是分頁返回的每頁條數(shù)有限需要循環(huán)請求直到?jīng)]有下一頁。這里要處理兩個問題一是翻頁游標或偏移量怎么傳二是重復文章怎么去重。常見做法是用一個Set存已抓到的文章 ID每次解析后先查重再入庫。const seen new Set(); // 已抓取的文章 ID 集合 async function fetchArticleList(accountId, maxPages 50) { const all []; let offset 0; const pageSize 20; for (let page 0; page maxPages; page) { const data await requestWithRetry(/api/article/list, { account_id: accountId, offset: offset, count: pageSize }); const list data?.articles || []; if (list.length 0) break; // 沒有數(shù)據(jù)了提前結束 for (const item of list) { if (seen.has(item.id)) continue; // 去重 seen.add(item.id); all.push(item); } offset pageSize; await new Promise(r setTimeout(r, 500)); // 每頁之間歇一下 } return all; }maxPages是保護性上限防止接口異常時無限循環(huán)。每頁之間停 500 毫秒是降低請求頻率太快容易觸發(fā)限流。offset的遞增方式取決于接口設計有的用游標cursor有的用頁碼page拿到實際返回后按字段調(diào)整。去重這步不能省翻頁過程中接口偶爾會返回重復項不去重最后統(tǒng)計閱讀量會偏高。3. 正文、閱讀量、點贊與評論的解析字段怎么取、結構怎么落3.1 詳情頁解析正文與互動數(shù)據(jù)拿到文章鏈接后逐篇請求詳情頁。正文一般在 HTML 的某個容器里用cheerio按選擇器提取閱讀量和點贊量有的在頁面內(nèi)嵌的 JS 變量里有的在單獨的接口返回中。常見做法是先用cheerio抓正文再用正則從頁面源碼里匹配閱讀量字段。const cheerio require(cheerio); function parseArticleDetail(html) { const $ cheerio.load(html); // 正文取內(nèi)容容器去掉腳本和樣式 const content $(#js_content).text().trim(); // 閱讀量、點贊量常藏在頁面腳本里用正則匹配 const readMatch html.match(/read_num[]?\s*[:]\s*[]?(\d)/); const likeMatch html.match(/like_num[]?\s*[:]\s*[]?(\d)/); return { content: content, readNum: readMatch ? parseInt(readMatch[1], 10) : 0, likeNum: likeMatch ? parseInt(likeMatch[1], 10) : 0 }; }#js_content是正文容器的常見 ID不同模板可能不同抓不到時先打印 HTML 看結構再改選擇器。正則里的read_num和like_num是字段名實際字段名以頁面源碼為準匹配不到就返回 0避免整條記錄失敗。正文用.text()會丟掉圖片和鏈接如果需要保留富文本改用.html()再單獨清洗。3.2 評論抓取分頁與嵌套結構評論通常是單獨接口按文章 ID 分頁拉取每條評論可能帶子評論。抓的時候要處理兩層分頁主評論翻頁和子評論展開。常見做法是先拉主評論再對每條有子評論的項發(fā)二次請求。async function fetchComments(articleId, maxPages 20) { const comments []; let page 1; while (page maxPages) { const data await requestWithRetry(/api/comment/list, { article_id: articleId, page: page, limit: 20 }); const list data?.comments || []; if (list.length 0) break; for (const c of list) { comments.push({ user: c.nickname, text: c.content, like: c.like_num || 0, time: c.create_time }); } page; await new Promise(r setTimeout(r, 300)); } return comments; }maxPages同樣做上限保護。評論接口對頻率更敏感間隔設 300 毫秒以上比較穩(wěn)。子評論如果也要就在主評論循環(huán)里判斷c.reply_count 0再發(fā)一次請求但要注意嵌套層級別無限展開設個深度上限。3.3 數(shù)據(jù)落盤JSON 與 CSV 兩種格式抓完的數(shù)據(jù)建議同時落 JSON 和 CSV。JSON 保留完整結構方便后續(xù)程序處理CSV 方便直接丟進表格軟件看。用fs-extra寫入const fs require(fs-extra); async function saveData(articles, outputDir ./output) { await fs.ensureDir(outputDir); // 目錄不存在就創(chuàng)建 // 完整數(shù)據(jù)存 JSON await fs.writeJson(${outputDir}/articles.json, articles, { spaces: 2 }); // 摘要字段存 CSV const header title,readNum,likeNum,url\n; const rows articles.map(a ${a.title},${a.readNum},${a.likeNum},${a.url} ).join(\n); await fs.writeFile(${outputDir}/summary.csv, header rows, utf8); }ensureDir保證目錄存在避免首次運行報錯。CSV 里標題和 URL 用雙引號包住防止內(nèi)容里的逗號破壞列結構。JSON 用spaces: 2格式化方便人工查看。數(shù)據(jù)量大時 CSV 拼接可能占內(nèi)存可以改成流式寫入但一般幾千篇以內(nèi)直接拼沒問題。4. 避坑與排查抓取過程中最容易翻車的五件事4.1 請求返回空數(shù)據(jù)或 403現(xiàn)象請求發(fā)出后返回空數(shù)組或 403 狀態(tài)碼。原因缺少必要的請求頭或請求頻率過高被臨時限制。解決補全User-Agent、Referer等頭降低并發(fā)數(shù)每頁之間加延時。如果持續(xù) 403說明該入口暫時不可用換時間段再試。4.2 閱讀量字段匹配不到現(xiàn)象正文能抓到但閱讀量和點贊量全是 0。原因字段名和正則不匹配或數(shù)據(jù)在異步加載的接口里而非頁面源碼。解決先打印完整 HTML 搜索read關鍵字定位真實字段名如果頁面源碼里沒有改用抓包工具找到對應接口單獨請求。4.3 翻頁死循環(huán)或漏抓現(xiàn)象程序一直翻頁不結束或中間漏掉幾頁。原因翻頁游標邏輯寫錯或接口在某一頁返回異常導致break提前觸發(fā)。解決打印每頁返回的條數(shù)和游標值確認遞增邏輯對異常返回做判斷區(qū)分「真的沒有下一頁」和「請求失敗」。4.4 評論抓取被限流現(xiàn)象評論抓到前幾頁后開始返回空或報錯。原因評論接口頻率限制比文章列表更嚴。解決把評論請求的間隔調(diào)到 500 毫秒以上并發(fā)降到 1必要時分批分時段抓。4.5 數(shù)據(jù)重復或統(tǒng)計偏差現(xiàn)象同一篇文章出現(xiàn)多次閱讀量統(tǒng)計偏高。原因翻頁過程中接口返回重復項去重沒做或做得不徹底。解決用文章 ID 做Set去重入庫前再查一次統(tǒng)計前先按 ID 去重再算中位數(shù)和均值。5. 進階技巧把抓取結果變成可復用的選題庫抓到數(shù)據(jù)只是第一步真正省時間的是把結果整理成能直接用的選題庫。我一般會做三件事按閱讀量分檔、按時間看趨勢、按關鍵詞聚類。分檔用簡單的分位數(shù)就行不用上復雜模型function analyzeArticles(articles) { // 按閱讀量排序后取分位數(shù) const sorted [...articles].sort((a, b) a.readNum - b.readNum); const q (p) sorted[Math.floor(sorted.length * p)]?.readNum || 0; const low q(0.25); // 25 分位 const mid q(0.5); // 中位數(shù) const high q(0.75); // 75 分位 // 分檔統(tǒng)計 const buckets { low: 0, mid: 0, high: 0 }; for (const a of articles) { if (a.readNum low) buckets.low; else if (a.readNum high) buckets.mid; else buckets.high; } return { low, mid, high, buckets }; }這段代碼把文章按閱讀量分成三檔q(0.25)是 25 分位值低于它的算低閱讀高于 75 分位的算高閱讀。分檔之后就能看出這個號的內(nèi)容基本盤在哪哪些選題屬于爆款區(qū)間。趨勢分析按月份分組算均值關鍵詞聚類用簡單的詞頻統(tǒng)計就夠不用上 NLP 模型。驗證抓取結果是否可靠我習慣抽三篇手動核對閱讀量和評論數(shù)對不上就回頭查解析邏輯。這個習慣是從一次翻車來的——當時正則匹配到了頁面里另一個同名字段導致所有閱讀量都偏大抽檢才發(fā)現(xiàn)。從那以后我每次抓完都強制走一遍抽檢三篇對不上就全量重跑。希望幫到你。本文還有配套的精品資源點擊獲取