微信视频号弹幕抓取工具wxlivespy技术内核从扫码开播到数据送达中间只差一次请求监听【免费下载链接】wxlivespy微信视频号直播间弹幕信息抓取工具项目地址: https://gitcode.com/gh_mirrors/wx/wxlivespy如果你是做直播带货代运营、弹幕互动游戏开发或者给主播做数据复盘的人大概率遇到过这样的痛苦视频号的直播间数据仿佛在一个黑盒里——官方后台只能看到粗糙的观看人数和点赞总数想要弹幕原文、送礼明细、用户进场的实时流官方没给接口人工录屏又慢又不全。wxlivespy 正是冲着这个缺口来的。这是一款开源的微信视频号弹幕抓取工具基于 Electron 桌面壳 Puppeteer 浏览器自动化 TypeScript 编写能在你点下开始监听后实时抓取直播间里的评论、进入、送礼、连击送礼、点赞、等级提升等互动事件并一键转发到你指定的 HTTP 地址。它不侵入微信、不改协议只是站在浏览器的肩膀上看数据流这也是它最聪明的设计。图1wxlivespy 的监听与转发界面。左侧开始监听拉起浏览器右侧设置转发地址后弹幕与礼物数据就会实时推送到目标服务。跑起来要什么条件为什么这么设计工具只发布并测试过 Windows 64 位其他系统属于未验证状态。启动前有一个关键前置动作npm install装完依赖后Puppeteer 会在C:\Users\你的用户名\.cache\puppeteer\chrome下缓存一份 Chrome把它复制到项目的assets\puppeteer_chrome目录工具启动时就会直接加载这份浏览器。为什么这么绕核心原因是微信视频号管理后台必须在真实浏览器里扫码登录而 headless 模式很容易被风控识别。所以 wxlivespy 选择了headless: false拉起一个看得见的 Chrome 窗口扫码登录后所有直播数据会通过这个浏览器流出——它要做的只是旁听。开发环境npm start生产打包npm run package都是标准 Electron 流程上手门槛不高。数据从哪来、经过谁、到哪去一条流水线讲透整个项目的数据流可以压缩成一句话浏览器发出的每一个响应先过滤、再解码、再补全身份、最后转发。对应代码里三个核心文件拦截——src/main/listener.ts中的WXLiveEventListener解码——src/main/WXDataDecoder.ts中的WXDataDecoder转发——src/main/service.ts中的SpyServicesrc/main/EventForwarder.tsWXLiveEventListener启动后通过page.setRequestInterception(true)打开请求拦截并监听page.on(response)。但这里有个细节值得学习它不是所有响应都接而是做了两道闸门。按 Content-Type 过滤skipContentTypevideo、image、audio开头的直接放行text/css、application/javascript、font/woff这类静态资源也直接跳过只留结构化数据避免解析压力全压在视频流上。按 URL 过滤skipURL目前只处理包含mmfinderassistant-bin/live/msg的请求——这是视频号直播间消息接口的特征路径其他接口即使命中也不处理。通过两道闸门的响应会取出response.json()、请求头里的x-wechat-uin主播标识、POST body 里的finderUsername一起交给decodeDataFromResponse做结构化解码。解码产物是一个DecodedData对象包含三块live_info在线人数、点赞总数、微信币打赏总额等直播间状态、host_info主播信息、events事件数组。其中live_info会被onStatusUpdate推给界面显示同时塞进一个内置的 HTTP 小服务——SpyHttpServer默认监听21201端口外部系统随时GET /getLiveStatus就能拉到直播间实时状态相当于白送一个轻量 API。而events则进入decodeOpenIDInEvents做身份补全再交给EventForwarder转发。四个有技术含量的细节逐个拆开看1. 七种事件类型靠 msgType 精准分流解码器里最核心的分派逻辑在liveMessageFromMsg和liveMessageFromAppMsg两个方法。直播间数据分两条消息通道msgList走普通消息通道appMsgList走业务消息通道两边的类型判断字段不一样。msgList里type 1是评论type 10005是用户进入appMsgList里msgType 20009是单次送礼、20013是连击送礼、20006是点赞、20031是等级提升。送礼和连击的数据藏在 base64 编码的payload字段里解码时先Buffer.from(o.payload, base64)还原出 JSON再从中抽出reward_product_id、reward_product_count、reward_amount_in_wecoin单位是微信币等字段。识别不了的统一归为unknown并把原始数据原样塞进original_data保留——这种解码不了就保留现场的做法给协议升级留了后路。2. 跨场次用户追踪decoded_openid才是真身份这是整个项目技术含量最高的点。原始数据里的sec_openid在不同直播场次之间是会变的拿来追踪用户根本不可靠。但 wxlivespy 发现了一个稳定字段对进入和评论消息msg_id形如finderlive_usermsg_comment_..._o9hHn5apfwHL-RYrxochETS7NyDMgetOpenIDFromMsgId直接把_o9h之后的部分截出来就是同一个主播的不同直播场次都不变的decoded_openid对送礼类消息msg_id形如finderlive_appmsg_finderlive_commcommentnotify_..._b2afac411cfad2d6f5fe69e1c2ec3901getSecOpenIDFromMsgId按_切分取最后一段得到sec_openid的十六进制 ID再映射到已缓存的decoded_openid。再配合src/main/idcache.ts里那张Map——键是liveId-secOpenId值是decodedOpenId——同一场直播内先出现评论、后送礼就能把两次行为对到同一个人身上。这套短期缓存映射 长期稳定标识的组合拳是它最值得抄的设计。3. 转发链路gzip 压缩是隐藏的带宽杀手锏EventForwarder的forwardData会先检查配置里的gzip_forward_data。开启时走postGzippedData用 Node 的zlib.gzip压缩后再通过 axios POST 出去请求头带上Content-Encoding: gzip。弹幕高峰期一晚上几千条消息压缩后能省下可观的带宽而且对接收方透明——绝大多数 HTTP 框架都能自动解压。不开则走PostOriginalData原样发送方便调试。另外配置里还有一个gift_and_comments_only开关可只转发礼物和评论把无关事件挡在转发链路之外进一步降噪。4. 点赞的半开放状态拿得到事件拿不到次数工具能感知到点赞行为msgType 20006能拿到直播间点赞总数但拿不到单个用户精确的点按次数。这属于平台数据粒度的限制wxlivespy 在 README 里直言不讳地写了出来。这种能做什么、不能做什么写进文档的坦诚比藏着掖着的工具更可信。数据不丢、不错、可追溯它做了哪些保障直播数据的可靠性是这类工具的生死线wxlivespy 在三个层面做了防护按 seq 去重SpyService.onEvent维护一个receivedSeqs数组同一seq直播间消息序号从 1 递增只展示一次。需要留意的是转发链路本身可能重复投递CustomTypes.ts里对seq的注释写得很清楚——服务器收到后要自己去重这是给二次开发者的重要提醒。身份冲突预警decodeOpenIDInEvents里如果同一个sec_openid被解析出两个不同的decoded_openid会打一条log.warn警告日志送礼消息的十六进制 ID 映射冲突同理。虽然它没做复杂的纠错但把异常暴露在日志里排查问题就有据可循。日志分级与界面回显所有关键节点都有electron-log记录转发成功会打forward response失败打forward error界面上的转发日志面板展示最近 20 条方便肉眼核对数据到底发没发出去。三个能直接落地的场景场景一弹幕游戏运营。这是项目关键词里就带弹幕游戏的原因。把forward_url指向游戏服务器用户在直播间刷的每一条弹幕都会变成游戏指令连击送礼的combo_product_count还能驱动连击特效。相比录屏识别方案延迟低一个量级。场景二主播数据看板。外部系统轮询http://127.0.0.1:21201/getLiveStatus就能拿到实时在线人数、点赞总数、微信币打赏总额配合转发过来的逐条事件一场直播下来从谁来了、谁说了什么、谁送了多少钱到全程互动曲线全部齐活省掉人工登记。场景三长期用户画像。靠稳定的decoded_openid跨场次聚合某个用户在所有直播中的评论与送礼记录做用户价值分层和主播粉丝黏性分析——这是普通抓一把数据的工具给不了的增量价值。避坑指南三个最容易翻车的地方Chrome 没放对位置启动即失败。最常踩的坑是npm install后忘记把.cache\puppeteer\chrome下的浏览器复制到assets\puppeteer_chrome。报错基本都指向executablePath找不到文件。先确认assets\puppeteer_chrome目录存在且内含chrome.exe。解码报liveInfo is undefined。解码器里专门抛了一个异常liveInfo is undefined, but msgList or appMsgList is not empty。当接口返回的结构和预期不符通常是微信端改了协议或字段不要慌original_data里留了原始数据对着真实报文改WXDataDecoder里的字段路径即可。收到重复数据以为是 bug。前文说过转发链路不保证幂等同一事件可能被发送多次。接收方务必按seq去重这是文档注释明确提示的设计边界不是缺陷。怎么改、怎么扩给想二次开发的人三条路径加新消息类型在src/main/WXDataDecoder.ts的liveMessageFromAppMsg里加一个else if (o.msgType 新类型)分支按payload解出字段即可接口LiveMessage支持灵活追加可选字段。改转发目标默认是 HTTP POST如果你想推给消息队列或数据库只需要替换EventForwarder的实现SpyService.onEvents与转发的接口是解耦的。加本地存储源码里多处 TODO 提到save message to log file说明作者本来就有落盘计划。你可以在decodeDataFromResponse里把每条消息同时写进文件或 SQLite补上本地留档能力。最后说两句一句话回顾wxlivespy 用监听浏览器流量 解析微信私有协议 稳定用户标识这三板斧把一个看似无解的实时抓取难题简化成了几个模块之间的流水线协作。它本身代码量不大但每一处取舍——内容类型过滤、URL 白名单、gzip 转发、seq 去重——都是实战里长出来的经验。值得期待的方向有两个一是对新增消息类型的持续适配微信端每次升级协议都考验解码器的弹性二是本地日志落盘与更完善的重试机制作者已经在代码里埋了 TODO一旦补齐可靠性会再上一个台阶。对这个项目感兴趣的开发者不妨直接git clone https://gitcode.com/gh_mirrors/wx/wxlivespy跑起来从 listener 到 decoder 走一遍数据流你会收获一堂生动的浏览器即传感器实战课。【免费下载链接】wxlivespy微信视频号直播间弹幕信息抓取工具项目地址: https://gitcode.com/gh_mirrors/wx/wxlivespy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考