彈幕抓取工具wxlivespy技術(shù)內(nèi)核：從“掃碼開播“到數(shù)據(jù)送達(dá)，中間只差一次請(qǐng)求監(jiān)聽)
微信視頻號(hào)彈幕抓取工具wxlivespy技術(shù)內(nèi)核從掃碼開播到數(shù)據(jù)送達(dá)中間只差一次請(qǐng)求監(jiān)聽【免費(fèi)下載鏈接】wxlivespy微信視頻號(hào)直播間彈幕信息抓取工具項(xiàng)目地址: https://gitcode.com/gh_mirrors/wx/wxlivespy如果你是做直播帶貨代運(yùn)營、彈幕互動(dòng)游戲開發(fā)或者給主播做數(shù)據(jù)復(fù)盤的人大概率遇到過這樣的痛苦視頻號(hào)的直播間數(shù)據(jù)仿佛在一個(gè)黑盒里——官方后臺(tái)只能看到粗糙的觀看人數(shù)和點(diǎn)贊總數(shù)想要彈幕原文、送禮明細(xì)、用戶進(jìn)場的實(shí)時(shí)流官方?jīng)]給接口人工錄屏又慢又不全。wxlivespy 正是沖著這個(gè)缺口來的。這是一款開源的微信視頻號(hào)彈幕抓取工具基于 Electron 桌面殼 Puppeteer 瀏覽器自動(dòng)化 TypeScript 編寫能在你點(diǎn)下開始監(jiān)聽后實(shí)時(shí)抓取直播間里的評(píng)論、進(jìn)入、送禮、連擊送禮、點(diǎn)贊、等級(jí)提升等互動(dòng)事件并一鍵轉(zhuǎn)發(fā)到你指定的 HTTP 地址。它不侵入微信、不改協(xié)議只是站在瀏覽器的肩膀上看數(shù)據(jù)流這也是它最聰明的設(shè)計(jì)。圖1wxlivespy 的監(jiān)聽與轉(zhuǎn)發(fā)界面。左側(cè)開始監(jiān)聽拉起瀏覽器右側(cè)設(shè)置轉(zhuǎn)發(fā)地址后彈幕與禮物數(shù)據(jù)就會(huì)實(shí)時(shí)推送到目標(biāo)服務(wù)。跑起來要什么條件為什么這么設(shè)計(jì)工具只發(fā)布并測(cè)試過 Windows 64 位其他系統(tǒng)屬于未驗(yàn)證狀態(tài)。啟動(dòng)前有一個(gè)關(guān)鍵前置動(dòng)作npm install裝完依賴后Puppeteer 會(huì)在C:\Users\你的用戶名\.cache\puppeteer\chrome下緩存一份 Chrome把它復(fù)制到項(xiàng)目的assets\puppeteer_chrome目錄工具啟動(dòng)時(shí)就會(huì)直接加載這份瀏覽器。為什么這么繞核心原因是微信視頻號(hào)管理后臺(tái)必須在真實(shí)瀏覽器里掃碼登錄而 headless 模式很容易被風(fēng)控識(shí)別。所以 wxlivespy 選擇了headless: false拉起一個(gè)看得見的 Chrome 窗口掃碼登錄后所有直播數(shù)據(jù)會(huì)通過這個(gè)瀏覽器流出——它要做的只是旁聽。開發(fā)環(huán)境npm start生產(chǎn)打包npm run package都是標(biāo)準(zhǔn) Electron 流程上手門檻不高。數(shù)據(jù)從哪來、經(jīng)過誰、到哪去一條流水線講透整個(gè)項(xiàng)目的數(shù)據(jù)流可以壓縮成一句話瀏覽器發(fā)出的每一個(gè)響應(yīng)先過濾、再解碼、再補(bǔ)全身份、最后轉(zhuǎn)發(fā)。對(duì)應(yīng)代碼里三個(gè)核心文件攔截——src/main/listener.ts中的WXLiveEventListener解碼——src/main/WXDataDecoder.ts中的WXDataDecoder轉(zhuǎn)發(fā)——src/main/service.ts中的SpyServicesrc/main/EventForwarder.tsWXLiveEventListener啟動(dòng)后通過page.setRequestInterception(true)打開請(qǐng)求攔截并監(jiān)聽page.on(response)。但這里有個(gè)細(xì)節(jié)值得學(xué)習(xí)它不是所有響應(yīng)都接而是做了兩道閘門。按 Content-Type 過濾skipContentTypevideo、image、audio開頭的直接放行text/css、application/javascript、font/woff這類靜態(tài)資源也直接跳過只留結(jié)構(gòu)化數(shù)據(jù)避免解析壓力全壓在視頻流上。按 URL 過濾skipURL目前只處理包含mmfinderassistant-bin/live/msg的請(qǐng)求——這是視頻號(hào)直播間消息接口的特征路徑其他接口即使命中也不處理。通過兩道閘門的響應(yīng)會(huì)取出response.json()、請(qǐng)求頭里的x-wechat-uin主播標(biāo)識(shí)、POST body 里的finderUsername一起交給decodeDataFromResponse做結(jié)構(gòu)化解碼。解碼產(chǎn)物是一個(gè)DecodedData對(duì)象包含三塊live_info在線人數(shù)、點(diǎn)贊總數(shù)、微信幣打賞總額等直播間狀態(tài)、host_info主播信息、events事件數(shù)組。其中l(wèi)ive_info會(huì)被onStatusUpdate推給界面顯示同時(shí)塞進(jìn)一個(gè)內(nèi)置的 HTTP 小服務(wù)——SpyHttpServer默認(rèn)監(jiān)聽21201端口外部系統(tǒng)隨時(shí)GET /getLiveStatus就能拉到直播間實(shí)時(shí)狀態(tài)相當(dāng)于白送一個(gè)輕量 API。而events則進(jìn)入decodeOpenIDInEvents做身份補(bǔ)全再交給EventForwarder轉(zhuǎn)發(fā)。四個(gè)有技術(shù)含量的細(xì)節(jié)逐個(gè)拆開看1. 七種事件類型靠 msgType 精準(zhǔn)分流解碼器里最核心的分派邏輯在liveMessageFromMsg和liveMessageFromAppMsg兩個(gè)方法。直播間數(shù)據(jù)分兩條消息通道m(xù)sgList走普通消息通道appMsgList走業(yè)務(wù)消息通道兩邊的類型判斷字段不一樣。msgList里type 1是評(píng)論type 10005是用戶進(jìn)入appMsgList里msgType 20009是單次送禮、20013是連擊送禮、20006是點(diǎn)贊、20031是等級(jí)提升。送禮和連擊的數(shù)據(jù)藏在 base64 編碼的payload字段里解碼時(shí)先Buffer.from(o.payload, base64)還原出 JSON再從中抽出reward_product_id、reward_product_count、reward_amount_in_wecoin單位是微信幣等字段。識(shí)別不了的統(tǒng)一歸為unknown并把原始數(shù)據(jù)原樣塞進(jìn)original_data保留——這種解碼不了就保留現(xiàn)場的做法給協(xié)議升級(jí)留了后路。2. 跨場次用戶追蹤decoded_openid才是真身份這是整個(gè)項(xiàng)目技術(shù)含量最高的點(diǎn)。原始數(shù)據(jù)里的sec_openid在不同直播場次之間是會(huì)變的拿來追蹤用戶根本不可靠。但 wxlivespy 發(fā)現(xiàn)了一個(gè)穩(wěn)定字段對(duì)進(jìn)入和評(píng)論消息msg_id形如finderlive_usermsg_comment_..._o9hHn5apfwHL-RYrxochETS7NyDMgetOpenIDFromMsgId直接把_o9h之后的部分截出來就是同一個(gè)主播的不同直播場次都不變的decoded_openid對(duì)送禮類消息msg_id形如finderlive_appmsg_finderlive_commcommentnotify_..._b2afac411cfad2d6f5fe69e1c2ec3901getSecOpenIDFromMsgId按_切分取最后一段得到sec_openid的十六進(jìn)制 ID再映射到已緩存的decoded_openid。再配合src/main/idcache.ts里那張Map——鍵是liveId-secOpenId值是decodedOpenId——同一場直播內(nèi)先出現(xiàn)評(píng)論、后送禮就能把兩次行為對(duì)到同一個(gè)人身上。這套短期緩存映射 長期穩(wěn)定標(biāo)識(shí)的組合拳是它最值得抄的設(shè)計(jì)。3. 轉(zhuǎn)發(fā)鏈路gzip 壓縮是隱藏的帶寬殺手锏EventForwarder的forwardData會(huì)先檢查配置里的gzip_forward_data。開啟時(shí)走postGzippedData用 Node 的zlib.gzip壓縮后再通過 axios POST 出去請(qǐng)求頭帶上Content-Encoding: gzip。彈幕高峰期一晚上幾千條消息壓縮后能省下可觀的帶寬而且對(duì)接收方透明——絕大多數(shù) HTTP 框架都能自動(dòng)解壓。不開則走PostOriginalData原樣發(fā)送方便調(diào)試。另外配置里還有一個(gè)gift_and_comments_only開關(guān)可只轉(zhuǎn)發(fā)禮物和評(píng)論把無關(guān)事件擋在轉(zhuǎn)發(fā)鏈路之外進(jìn)一步降噪。4. 點(diǎn)贊的半開放狀態(tài)拿得到事件拿不到次數(shù)工具能感知到點(diǎn)贊行為msgType 20006能拿到直播間點(diǎn)贊總數(shù)但拿不到單個(gè)用戶精確的點(diǎn)按次數(shù)。這屬于平臺(tái)數(shù)據(jù)粒度的限制wxlivespy 在 README 里直言不諱地寫了出來。這種能做什么、不能做什么寫進(jìn)文檔的坦誠比藏著掖著的工具更可信。數(shù)據(jù)不丟、不錯(cuò)、可追溯它做了哪些保障直播數(shù)據(jù)的可靠性是這類工具的生死線wxlivespy 在三個(gè)層面做了防護(hù)按 seq 去重SpyService.onEvent維護(hù)一個(gè)receivedSeqs數(shù)組同一seq直播間消息序號(hào)從 1 遞增只展示一次。需要留意的是轉(zhuǎn)發(fā)鏈路本身可能重復(fù)投遞CustomTypes.ts里對(duì)seq的注釋寫得很清楚——服務(wù)器收到后要自己去重這是給二次開發(fā)者的重要提醒。身份沖突預(yù)警decodeOpenIDInEvents里如果同一個(gè)sec_openid被解析出兩個(gè)不同的decoded_openid會(huì)打一條log.warn警告日志送禮消息的十六進(jìn)制 ID 映射沖突同理。雖然它沒做復(fù)雜的糾錯(cuò)但把異常暴露在日志里排查問題就有據(jù)可循。日志分級(jí)與界面回顯所有關(guān)鍵節(jié)點(diǎn)都有electron-log記錄轉(zhuǎn)發(fā)成功會(huì)打forward response失敗打forward error界面上的轉(zhuǎn)發(fā)日志面板展示最近 20 條方便肉眼核對(duì)數(shù)據(jù)到底發(fā)沒發(fā)出去。三個(gè)能直接落地的場景場景一彈幕游戲運(yùn)營。這是項(xiàng)目關(guān)鍵詞里就帶彈幕游戲的原因。把forward_url指向游戲服務(wù)器用戶在直播間刷的每一條彈幕都會(huì)變成游戲指令連擊送禮的combo_product_count還能驅(qū)動(dòng)連擊特效。相比錄屏識(shí)別方案延遲低一個(gè)量級(jí)。場景二主播數(shù)據(jù)看板。外部系統(tǒng)輪詢http://127.0.0.1:21201/getLiveStatus就能拿到實(shí)時(shí)在線人數(shù)、點(diǎn)贊總數(shù)、微信幣打賞總額配合轉(zhuǎn)發(fā)過來的逐條事件一場直播下來從誰來了、誰說了什么、誰送了多少錢到全程互動(dòng)曲線全部齊活省掉人工登記。場景三長期用戶畫像。靠穩(wěn)定的decoded_openid跨場次聚合某個(gè)用戶在所有直播中的評(píng)論與送禮記錄做用戶價(jià)值分層和主播粉絲黏性分析——這是普通抓一把數(shù)據(jù)的工具給不了的增量價(jià)值。避坑指南三個(gè)最容易翻車的地方Chrome 沒放對(duì)位置啟動(dòng)即失敗。最常踩的坑是npm install后忘記把.cache\puppeteer\chrome下的瀏覽器復(fù)制到assets\puppeteer_chrome。報(bào)錯(cuò)基本都指向executablePath找不到文件。先確認(rèn)assets\puppeteer_chrome目錄存在且內(nèi)含chrome.exe。解碼報(bào)liveInfo is undefined。解碼器里專門拋了一個(gè)異常liveInfo is undefined, but msgList or appMsgList is not empty。當(dāng)接口返回的結(jié)構(gòu)和預(yù)期不符通常是微信端改了協(xié)議或字段不要慌original_data里留了原始數(shù)據(jù)對(duì)著真實(shí)報(bào)文改WXDataDecoder里的字段路徑即可。收到重復(fù)數(shù)據(jù)以為是 bug。前文說過轉(zhuǎn)發(fā)鏈路不保證冪等同一事件可能被發(fā)送多次。接收方務(wù)必按seq去重這是文檔注釋明確提示的設(shè)計(jì)邊界不是缺陷。怎么改、怎么擴(kuò)給想二次開發(fā)的人三條路徑加新消息類型在src/main/WXDataDecoder.ts的liveMessageFromAppMsg里加一個(gè)else if (o.msgType 新類型)分支按payload解出字段即可接口LiveMessage支持靈活追加可選字段。改轉(zhuǎn)發(fā)目標(biāo)默認(rèn)是 HTTP POST如果你想推給消息隊(duì)列或數(shù)據(jù)庫只需要替換EventForwarder的實(shí)現(xiàn)SpyService.onEvents與轉(zhuǎn)發(fā)的接口是解耦的。加本地存儲(chǔ)源碼里多處 TODO 提到save message to log file說明作者本來就有落盤計(jì)劃。你可以在decodeDataFromResponse里把每條消息同時(shí)寫進(jìn)文件或 SQLite補(bǔ)上本地留檔能力。最后說兩句一句話回顧wxlivespy 用監(jiān)聽瀏覽器流量 解析微信私有協(xié)議 穩(wěn)定用戶標(biāo)識(shí)這三板斧把一個(gè)看似無解的實(shí)時(shí)抓取難題簡化成了幾個(gè)模塊之間的流水線協(xié)作。它本身代碼量不大但每一處取舍——內(nèi)容類型過濾、URL 白名單、gzip 轉(zhuǎn)發(fā)、seq 去重——都是實(shí)戰(zhàn)里長出來的經(jīng)驗(yàn)。值得期待的方向有兩個(gè)一是對(duì)新增消息類型的持續(xù)適配微信端每次升級(jí)協(xié)議都考驗(yàn)解碼器的彈性二是本地日志落盤與更完善的重試機(jī)制作者已經(jīng)在代碼里埋了 TODO一旦補(bǔ)齊可靠性會(huì)再上一個(gè)臺(tái)階。對(duì)這個(gè)項(xiàng)目感興趣的開發(fā)者不妨直接git clone https://gitcode.com/gh_mirrors/wx/wxlivespy跑起來從 listener 到 decoder 走一遍數(shù)據(jù)流你會(huì)收獲一堂生動(dòng)的瀏覽器即傳感器實(shí)戰(zhàn)課?！久赓M(fèi)下載鏈接】wxlivespy微信視頻號(hào)直播間彈幕信息抓取工具項(xiàng)目地址: https://gitcode.com/gh_mirrors/wx/wxlivespy創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 微信視頻號(hào)彈幕抓取工具wxlivespy技術(shù)內(nèi)核：從“掃碼開播“到數(shù)據(jù)送達(dá)，中間只差一次請(qǐng)求監(jiān)聽
微信視頻號(hào)彈幕抓取工具wxlivespy技術(shù)內(nèi)核從掃碼開播到數(shù)據(jù)送達(dá)中間只差一次請(qǐng)求監(jiān)聽【免費(fèi)下載鏈接】wxlivespy微信視頻號(hào)直播間彈幕信息抓取工具項(xiàng)目地址: https://gitcode.com/gh_mirrors/wx/wxlivespy如果你是做直播帶貨代運(yùn)營、彈幕互動(dòng)游戲開發(fā)或者給主播做數(shù)據(jù)復(fù)盤的人大概率遇到過這樣的痛苦視頻號(hào)的直播間數(shù)據(jù)仿佛在一個(gè)黑盒里——官方后臺(tái)只能看到粗糙的觀看人數(shù)和點(diǎn)贊總數(shù)想要彈幕原文、送禮明細(xì)、用戶進(jìn)場的實(shí)時(shí)流官方?jīng)]給接口人工錄屏又慢又不全。wxlivespy 正是沖著這個(gè)缺口來的。這是一款開源的微信視頻號(hào)彈幕抓取工具基于 Electron 桌面殼 Puppeteer 瀏覽器自動(dòng)化 TypeScript 編寫能在你點(diǎn)下開始監(jiān)聽后實(shí)時(shí)抓取直播間里的評(píng)論、進(jìn)入、送禮、連擊送禮、點(diǎn)贊、等級(jí)提升等互動(dòng)事件并一鍵轉(zhuǎn)發(fā)到你指定的 HTTP 地址。它不侵入微信、不改協(xié)議只是站在瀏覽器的肩膀上看數(shù)據(jù)流這也是它最聰明的設(shè)計(jì)。圖1wxlivespy 的監(jiān)聽與轉(zhuǎn)發(fā)界面。左側(cè)開始監(jiān)聽拉起瀏覽器右側(cè)設(shè)置轉(zhuǎn)發(fā)地址后彈幕與禮物數(shù)據(jù)就會(huì)實(shí)時(shí)推送到目標(biāo)服務(wù)。跑起來要什么條件為什么這么設(shè)計(jì)工具只發(fā)布并測(cè)試過 Windows 64 位其他系統(tǒng)屬于未驗(yàn)證狀態(tài)。啟動(dòng)前有一個(gè)關(guān)鍵前置動(dòng)作npm install裝完依賴后Puppeteer 會(huì)在C:\Users\你的用戶名\.cache\puppeteer\chrome下緩存一份 Chrome把它復(fù)制到項(xiàng)目的assets\puppeteer_chrome目錄工具啟動(dòng)時(shí)就會(huì)直接加載這份瀏覽器。為什么這么繞核心原因是微信視頻號(hào)管理后臺(tái)必須在真實(shí)瀏覽器里掃碼登錄而 headless 模式很容易被風(fēng)控識(shí)別。所以 wxlivespy 選擇了headless: false拉起一個(gè)看得見的 Chrome 窗口掃碼登錄后所有直播數(shù)據(jù)會(huì)通過這個(gè)瀏覽器流出——它要做的只是旁聽。開發(fā)環(huán)境npm start生產(chǎn)打包npm run package都是標(biāo)準(zhǔn) Electron 流程上手門檻不高。數(shù)據(jù)從哪來、經(jīng)過誰、到哪去一條流水線講透整個(gè)項(xiàng)目的數(shù)據(jù)流可以壓縮成一句話瀏覽器發(fā)出的每一個(gè)響應(yīng)先過濾、再解碼、再補(bǔ)全身份、最后轉(zhuǎn)發(fā)。對(duì)應(yīng)代碼里三個(gè)核心文件攔截——src/main/listener.ts中的WXLiveEventListener解碼——src/main/WXDataDecoder.ts中的WXDataDecoder轉(zhuǎn)發(fā)——src/main/service.ts中的SpyServicesrc/main/EventForwarder.tsWXLiveEventListener啟動(dòng)后通過page.setRequestInterception(true)打開請(qǐng)求攔截并監(jiān)聽page.on(response)。但這里有個(gè)細(xì)節(jié)值得學(xué)習(xí)它不是所有響應(yīng)都接而是做了兩道閘門。按 Content-Type 過濾skipContentTypevideo、image、audio開頭的直接放行text/css、application/javascript、font/woff這類靜態(tài)資源也直接跳過只留結(jié)構(gòu)化數(shù)據(jù)避免解析壓力全壓在視頻流上。按 URL 過濾skipURL目前只處理包含mmfinderassistant-bin/live/msg的請(qǐng)求——這是視頻號(hào)直播間消息接口的特征路徑其他接口即使命中也不處理。通過兩道閘門的響應(yīng)會(huì)取出response.json()、請(qǐng)求頭里的x-wechat-uin主播標(biāo)識(shí)、POST body 里的finderUsername一起交給decodeDataFromResponse做結(jié)構(gòu)化解碼。解碼產(chǎn)物是一個(gè)DecodedData對(duì)象包含三塊live_info在線人數(shù)、點(diǎn)贊總數(shù)、微信幣打賞總額等直播間狀態(tài)、host_info主播信息、events事件數(shù)組。其中l(wèi)ive_info會(huì)被onStatusUpdate推給界面顯示同時(shí)塞進(jìn)一個(gè)內(nèi)置的 HTTP 小服務(wù)——SpyHttpServer默認(rèn)監(jiān)聽21201端口外部系統(tǒng)隨時(shí)GET /getLiveStatus就能拉到直播間實(shí)時(shí)狀態(tài)相當(dāng)于白送一個(gè)輕量 API。而events則進(jìn)入decodeOpenIDInEvents做身份補(bǔ)全再交給EventForwarder轉(zhuǎn)發(fā)。四個(gè)有技術(shù)含量的細(xì)節(jié)逐個(gè)拆開看1. 七種事件類型靠 msgType 精準(zhǔn)分流解碼器里最核心的分派邏輯在liveMessageFromMsg和liveMessageFromAppMsg兩個(gè)方法。直播間數(shù)據(jù)分兩條消息通道m(xù)sgList走普通消息通道appMsgList走業(yè)務(wù)消息通道兩邊的類型判斷字段不一樣。msgList里type 1是評(píng)論type 10005是用戶進(jìn)入appMsgList里msgType 20009是單次送禮、20013是連擊送禮、20006是點(diǎn)贊、20031是等級(jí)提升。送禮和連擊的數(shù)據(jù)藏在 base64 編碼的payload字段里解碼時(shí)先Buffer.from(o.payload, base64)還原出 JSON再從中抽出reward_product_id、reward_product_count、reward_amount_in_wecoin單位是微信幣等字段。識(shí)別不了的統(tǒng)一歸為unknown并把原始數(shù)據(jù)原樣塞進(jìn)original_data保留——這種解碼不了就保留現(xiàn)場的做法給協(xié)議升級(jí)留了后路。2. 跨場次用戶追蹤decoded_openid才是真身份這是整個(gè)項(xiàng)目技術(shù)含量最高的點(diǎn)。原始數(shù)據(jù)里的sec_openid在不同直播場次之間是會(huì)變的拿來追蹤用戶根本不可靠。但 wxlivespy 發(fā)現(xiàn)了一個(gè)穩(wěn)定字段對(duì)進(jìn)入和評(píng)論消息msg_id形如finderlive_usermsg_comment_..._o9hHn5apfwHL-RYrxochETS7NyDMgetOpenIDFromMsgId直接把_o9h之后的部分截出來就是同一個(gè)主播的不同直播場次都不變的decoded_openid對(duì)送禮類消息msg_id形如finderlive_appmsg_finderlive_commcommentnotify_..._b2afac411cfad2d6f5fe69e1c2ec3901getSecOpenIDFromMsgId按_切分取最后一段得到sec_openid的十六進(jìn)制 ID再映射到已緩存的decoded_openid。再配合src/main/idcache.ts里那張Map——鍵是liveId-secOpenId值是decodedOpenId——同一場直播內(nèi)先出現(xiàn)評(píng)論、后送禮就能把兩次行為對(duì)到同一個(gè)人身上。這套短期緩存映射 長期穩(wěn)定標(biāo)識(shí)的組合拳是它最值得抄的設(shè)計(jì)。3. 轉(zhuǎn)發(fā)鏈路gzip 壓縮是隱藏的帶寬殺手锏EventForwarder的forwardData會(huì)先檢查配置里的gzip_forward_data。開啟時(shí)走postGzippedData用 Node 的zlib.gzip壓縮后再通過 axios POST 出去請(qǐng)求頭帶上Content-Encoding: gzip。彈幕高峰期一晚上幾千條消息壓縮后能省下可觀的帶寬而且對(duì)接收方透明——絕大多數(shù) HTTP 框架都能自動(dòng)解壓。不開則走PostOriginalData原樣發(fā)送方便調(diào)試。另外配置里還有一個(gè)gift_and_comments_only開關(guān)可只轉(zhuǎn)發(fā)禮物和評(píng)論把無關(guān)事件擋在轉(zhuǎn)發(fā)鏈路之外進(jìn)一步降噪。4. 點(diǎn)贊的半開放狀態(tài)拿得到事件拿不到次數(shù)工具能感知到點(diǎn)贊行為msgType 20006能拿到直播間點(diǎn)贊總數(shù)但拿不到單個(gè)用戶精確的點(diǎn)按次數(shù)。這屬于平臺(tái)數(shù)據(jù)粒度的限制wxlivespy 在 README 里直言不諱地寫了出來。這種能做什么、不能做什么寫進(jìn)文檔的坦誠比藏著掖著的工具更可信。數(shù)據(jù)不丟、不錯(cuò)、可追溯它做了哪些保障直播數(shù)據(jù)的可靠性是這類工具的生死線wxlivespy 在三個(gè)層面做了防護(hù)按 seq 去重SpyService.onEvent維護(hù)一個(gè)receivedSeqs數(shù)組同一seq直播間消息序號(hào)從 1 遞增只展示一次。需要留意的是轉(zhuǎn)發(fā)鏈路本身可能重復(fù)投遞CustomTypes.ts里對(duì)seq的注釋寫得很清楚——服務(wù)器收到后要自己去重這是給二次開發(fā)者的重要提醒。身份沖突預(yù)警decodeOpenIDInEvents里如果同一個(gè)sec_openid被解析出兩個(gè)不同的decoded_openid會(huì)打一條log.warn警告日志送禮消息的十六進(jìn)制 ID 映射沖突同理。雖然它沒做復(fù)雜的糾錯(cuò)但把異常暴露在日志里排查問題就有據(jù)可循。日志分級(jí)與界面回顯所有關(guān)鍵節(jié)點(diǎn)都有electron-log記錄轉(zhuǎn)發(fā)成功會(huì)打forward response失敗打forward error界面上的轉(zhuǎn)發(fā)日志面板展示最近 20 條方便肉眼核對(duì)數(shù)據(jù)到底發(fā)沒發(fā)出去。三個(gè)能直接落地的場景場景一彈幕游戲運(yùn)營。這是項(xiàng)目關(guān)鍵詞里就帶彈幕游戲的原因。把forward_url指向游戲服務(wù)器用戶在直播間刷的每一條彈幕都會(huì)變成游戲指令連擊送禮的combo_product_count還能驅(qū)動(dòng)連擊特效。相比錄屏識(shí)別方案延遲低一個(gè)量級(jí)。場景二主播數(shù)據(jù)看板。外部系統(tǒng)輪詢http://127.0.0.1:21201/getLiveStatus就能拿到實(shí)時(shí)在線人數(shù)、點(diǎn)贊總數(shù)、微信幣打賞總額配合轉(zhuǎn)發(fā)過來的逐條事件一場直播下來從誰來了、誰說了什么、誰送了多少錢到全程互動(dòng)曲線全部齊活省掉人工登記。場景三長期用戶畫像。靠穩(wěn)定的decoded_openid跨場次聚合某個(gè)用戶在所有直播中的評(píng)論與送禮記錄做用戶價(jià)值分層和主播粉絲黏性分析——這是普通抓一把數(shù)據(jù)的工具給不了的增量價(jià)值。避坑指南三個(gè)最容易翻車的地方Chrome 沒放對(duì)位置啟動(dòng)即失敗。最常踩的坑是npm install后忘記把.cache\puppeteer\chrome下的瀏覽器復(fù)制到assets\puppeteer_chrome。報(bào)錯(cuò)基本都指向executablePath找不到文件。先確認(rèn)assets\puppeteer_chrome目錄存在且內(nèi)含chrome.exe。解碼報(bào)liveInfo is undefined。解碼器里專門拋了一個(gè)異常liveInfo is undefined, but msgList or appMsgList is not empty。當(dāng)接口返回的結(jié)構(gòu)和預(yù)期不符通常是微信端改了協(xié)議或字段不要慌original_data里留了原始數(shù)據(jù)對(duì)著真實(shí)報(bào)文改WXDataDecoder里的字段路徑即可。收到重復(fù)數(shù)據(jù)以為是 bug。前文說過轉(zhuǎn)發(fā)鏈路不保證冪等同一事件可能被發(fā)送多次。接收方務(wù)必按seq去重這是文檔注釋明確提示的設(shè)計(jì)邊界不是缺陷。怎么改、怎么擴(kuò)給想二次開發(fā)的人三條路徑加新消息類型在src/main/WXDataDecoder.ts的liveMessageFromAppMsg里加一個(gè)else if (o.msgType 新類型)分支按payload解出字段即可接口LiveMessage支持靈活追加可選字段。改轉(zhuǎn)發(fā)目標(biāo)默認(rèn)是 HTTP POST如果你想推給消息隊(duì)列或數(shù)據(jù)庫只需要替換EventForwarder的實(shí)現(xiàn)SpyService.onEvents與轉(zhuǎn)發(fā)的接口是解耦的。加本地存儲(chǔ)源碼里多處 TODO 提到save message to log file說明作者本來就有落盤計(jì)劃。你可以在decodeDataFromResponse里把每條消息同時(shí)寫進(jìn)文件或 SQLite補(bǔ)上本地留檔能力。最后說兩句一句話回顧wxlivespy 用監(jiān)聽瀏覽器流量 解析微信私有協(xié)議 穩(wěn)定用戶標(biāo)識(shí)這三板斧把一個(gè)看似無解的實(shí)時(shí)抓取難題簡化成了幾個(gè)模塊之間的流水線協(xié)作。它本身代碼量不大但每一處取舍——內(nèi)容類型過濾、URL 白名單、gzip 轉(zhuǎn)發(fā)、seq 去重——都是實(shí)戰(zhàn)里長出來的經(jīng)驗(yàn)。值得期待的方向有兩個(gè)一是對(duì)新增消息類型的持續(xù)適配微信端每次升級(jí)協(xié)議都考驗(yàn)解碼器的彈性二是本地日志落盤與更完善的重試機(jī)制作者已經(jīng)在代碼里埋了 TODO一旦補(bǔ)齊可靠性會(huì)再上一個(gè)臺(tái)階。對(duì)這個(gè)項(xiàng)目感興趣的開發(fā)者不妨直接git clone https://gitcode.com/gh_mirrors/wx/wxlivespy跑起來從 listener 到 decoder 走一遍數(shù)據(jù)流你會(huì)收獲一堂生動(dòng)的瀏覽器即傳感器實(shí)戰(zhàn)課?！久赓M(fèi)下載鏈接】wxlivespy微信視頻號(hào)直播間彈幕信息抓取工具項(xiàng)目地址: https://gitcode.com/gh_mirrors/wx/wxlivespy創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考