拓冰网站定制 
抖音直播数据抓取实战指南WebSocket逆向与实时弹幕分析的4行代码入门【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcherDouyinLiveWebFetcher 是一个基于 Python 的抖音直播间网页版直播数据抓取工具核心链路是WebSocket 长连接接收实时消息、JS 签名逆向通过连接校验、Protobuf 协议解析把二进制流还原成弹幕、礼物、进场、统计等结构化数据。下文按 5 分钟、30 分钟、1 小时、1 天、1 周五个投入档位带你从看见数据走到上线运维。5 分钟 · 看见数据先跑通终端里的实时弹幕读完这节你会知道这个项目到底输出什么、解决什么问题。运行main.py后终端会持续滚动类似这样的内容【进场msg】[79026102598][男]尘埃 进入了直播间 【礼物msg】X L 送出了 为你点亮x1 【点赞msg】小程๑ 点了9个赞 【统计msg】当前观看人数: 22164, 累计观看人数: 43.6万 【聊天msg】[67197561586]说谎: 去拿 去拿去哪 【粉丝团msg】恭喜 安好 成为粉丝团第289687名成员抖音网页版直播间没有公开的开放接口直播间的消息流只推送给浏览器。DouyinLiveWebFetcher 的思路是让 Python 扮演浏览器用同一个连接通道、同一套签名算法去订阅消息从而把聊天、礼物、进场、点赞、统计这类事件原样拿到手。它解决的核心问题就一个——不靠人工盯屏把直播间里的实时事件变成可编程的数据流。30 分钟 · 搞懂原理长连接、签名与二进制协议读完这节你能向别人讲清楚项目做的三件事建一条 WebSocket 长连接、算出连接所需的签名、解析 Protobuf 二进制帧。为什么用 WebSocket 长连接而不是 HTTP 轮询WebSocket 是一种建立一次握手后、双方都能随时发数据的持久连接协议而 HTTP 轮询是你每隔几秒主动问一次有没有新消息。维度HTTP 轮询WebSocket 长连接数据发起方客户端定时请求服务器有消息就推延迟受轮询间隔限制秒级消息到达即推送毫秒级带宽每次请求都带完整请求/响应头一条连接只传消息体连接状态无状态断了无感长连接需要心跳保活适合场景低频数据弹幕这类高频事件流直播间的弹幕是高频事件流用轮询意味着消息到了服务器却在你两次请求的间隙里等了几秒且每次空轮询都浪费带宽所以长连接是这里唯一合理的选型。WebSocket 连接生命周期从取 cookie 到心跳保活这一小节回答连接是怎么一步步建立并维持下去的。整条生命周期在liveMan.py里分五步取 ttwid先访问直播页首页从响应 cookie 里拿到ttwid抖音用来标识访客的凭证。取 room_id请求直播间页面用正则从 HTML 里抽出roomId——注意live_id地址里的数字不等于room_id两者都要。拼装 wss 连接串把 room_id、设备平台、浏览器标识等一串参数拼进 WebSocket 地址并追加签名下一节讲。建连用 websocket-client 的WebSocketApp注册on_open / on_message / on_error / on_close四个回调后run_forever()连接不断则阻塞收包。保活握手成功后开一个独立线程每 5 秒发一个payload_typehb的心跳帧以 PING 帧形式发出服务器若标记need_ack则回发一个 ack 帧确认存活。断开时on_close回调会去查一次开播状态判断是下播还是网络问题。直播间连接签名是怎么算出来的这一小节回答为什么 wss 地址最后必须挂一个signature参数以及它是怎么得到的。抖音的校验分三层项目逐一对应处理校验项作用项目实现ttwid cookie标识访客身份直接请求直播页获取wss 连接签名防止伪造连接串执行sign.js计算__ac_signature / a_bogus房间状态等接口的参数校验纯 Python 实现 JS 脚本计算wss 签名的计算路径很直白先把 13 个参数live_id、aid、room_id、identity 等按固定顺序拼成kv,格式的字符串取 MD5再把这个 MD5 值喂给一段 JS——sign.js是字节跳动的byted_acrawler混淆脚本人工看不太懂所以项目用 mini_racer 在进程内嵌一个 V8 引擎直接执行它调用get_sign拿到签名拼到 URL 末尾。为什么必须执行而不是重算脚本被混淆了逆向出等价 Python 代码的成本远高于直接跑它而 mini_racer 自带 V8不需要你再装 Node.js。另外两个校验项里__ac_signature项目在ac_signature.py里用纯 Python 重写了算法输入域名、nonce、UA、时间戳输出签名串a_bogus则交给a_bogus.js计算代码注释里写明它的成功率不是 100%失败重试即可。Protobuf 协议解析二进制帧是怎么变成结构化数据的Protobuf 是一种比 JSON 更省流量、速度更快的二进制序列化格式——同样的内容用字节表示字段靠编号区分。这一小节回答收到的每个二进制包内部长什么样。帧是两层嵌套外层 PushFrame只描述这个包是什么log_id、payload_type、payload 等内层 Response才是真正的消息集合messages_list、need_ack、internal_ext。收到包后的动作是按 PushFrame 解析外层 → 对 payload 做 gzip 解压 → 按 Response 解析得到一组 Message每条 Message 带一个method消息类型名和一段 payload该类型的私有字节。protobuf/douyin.proto里用 proto3 语法定义了 Response、Message、ChatMessage、GiftMessage、PushFrame 等全部结构项目用 betterproto一个把 .proto 编译成 Python dataclass 的生成器生成protobuf/douyin.py于是解析就变成ChatMessage().parse(payload)一行调用取message.user.nick_name、message.content这些字段即可。1 小时 · 跑通链路安装、启动与数据流走读读完这节你能在自己机器上装好项目、跑起来并说清一个数据包从到达到打印的完整路径。环境准备与安装命令环境要求很轻Python 3.7 即可签名计算靠 mini_racer 内嵌 V8不需要 Node.js。git clone https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher cd DouyinLiveWebFetcher pip install -r requirements.txtrequirements.txt里只有 5 个依赖requestsHTTP 取 cookie/页面、websocket-client长连接、betterproto 2.0.0b6协议解析、PyExecJS 与 mini_racer两个 JS 执行引擎分别服务新旧两条签名路径。只有当你需要改动协议字段时才要装 protoc25.1重新生成protobuf/douyin.py。4 行最简启动代码拿到 live_id直播间网页地址末尾的那串数字后启动只需要这几行from liveMan import DouyinLiveWebFetcher fetcher DouyinLiveWebFetcher(510200350291) # 换成你的直播间 live_id fetcher.start()start()内部会依次完成取 ttwid、取 room_id、算签名、建连、启心跳线程然后阻塞收包打印。关键参数与 config.yaml 配置说明当前版本没有独立的 config.yaml关键参数都硬编码在liveMan.py中。如果你要扩展成多房间生产版建议把它们外置成config.yaml先对照这张表知道该外置哪些配置项当前取值代码位置说明心跳间隔5 秒_sendHeartbeat的time.sleep(5)调太小浪费流量调太大易被断下播判定status 3_parseControlMsg收到即调用stop()房间状态接口live_id a_bogusget_room_statusa_bogus 失败需重试签名脚本sign.js可切 sign_v0.jsgenerateSignature新版走 mini_racer旧版走 execjs数据流走读收包 → 解压 → 解析 → 分发这一小节回答一条消息在_wsOnMessage里经过的四步。核心逻辑浓缩如下package PushFrame().parse(message) # 1. 收包外层帧 response Response().parse(gzip.decompress(package.payload)) # 2. 解压内层 if response.need_ack: # 3. 回 ack 保活 ack PushFrame(log_idpackage.log_id, payload_typeack, payloadresponse.internal_ext.encode()).SerializeToString() ws.send(ack, websocket.ABNF.OPCODE_BINARY) for msg in response.messages_list: # 4. 按类型分发 handler {WebcastChatMessage: self._parseChatMsg, WebcastGiftMessage: self._parseGiftMsg, WebcastMemberMessage: self._parseMemberMsg}.get(msg.method) handler and handler(msg.payload)分发的目标由method字段决定项目当前处理 13 种method含义处理器WebcastChatMessage聊天弹幕_parseChatMsgWebcastGiftMessage礼物_parseGiftMsgWebcastLikeMessage点赞_parseLikeMsgWebcastMemberMessage进入直播间_parseMemberMsgWebcastSocialMessage关注主播_parseSocialMsgWebcastRoomUserSeqMessage当前/累计观看_parseRoomUserSeqMsgWebcastFansclubMessage粉丝团变动_parseFansclubMsgWebcastControlMessage下播状态_parseControlMsgWebcastRoomRankMessage 等排行榜、流配置等对应_parse*Msg注意分发处包在try/except里——某类消息解析失败只跳过不会拖垮整条连接这是长连接程序的基本防御。1 天 · 让数据干活仪表板、告警与业务场景读完这节你知道如何把终端打印升级为指标、告警以及哪些业务场景值得做。实时指标仪表板把 13 类处理器从print改成累加器即可——聊天量、礼物价值combo_count 计件数、进场速率、并发观看人数统计消息里的 total按窗口聚合推给 Grafana 或一块简单的 Web 看板。因为数据源本身就是实时的仪表板天然不需要定时刷新。敏感词与异常行为告警在聊天处理器里挂一层规则——敏感词表命中即告警再用滑动窗口统计消息速率、礼物频率、观众增速超过阈值比如每秒 100 条弹幕、单位时间礼物激增触发刷屏/水军/冲榜类告警。规则表和阈值都该做成可热更新的配置而不是写死在代码里。业务场景一览场景实现方式价值直播电商监控监听礼物、商品榜消息关联口播时间点评估带货节奏与转化节点内容安全敏感词过滤 异常行为检测提前干预降低违规风险竞品分析多实例同时监控多个直播间对比互动数据支撑运营决策用户行为分析按 user_id 聚合进场/发言/送礼轨迹构建活跃用户画像数据产品原始消息落库后二次加工对外提供看板或 API1 周 · 上线与扩展Docker、监控与并发读完这节你有一份可照抄的容器化方案和监控清单以及三个扩展方向。Docker 容器化镜像就是一个 Python 薄层装依赖、跑main.py即可配合restart: unless-stopped让断线后进程自动拉起FROM python:3.11-slim WORKDIR /app COPY . /app RUN pip install -r requirements.txt CMD [python, main.py]监控指标上线后重点盯四件事指标、频率与阈值给一张表直接照用监控指标采集频率告警阈值建议工具连接成功率每分钟 95%Prometheus Grafana消息处理延迟每 5 秒 1000msGrafana内存占用每分钟 80%cAdvisorCPU 占用每分钟 70%node_exporter并发与优化要点心跳已经放在独立线程不会阻塞收包解析和落库可以再丢进线程池 队列做到收包快、处理快、写盘批量化。大房间数万观众时先观察队列深度再决定是加 worker 还是只保留需要的消息类型增量解析省掉不关心的字段。扩展方向每个两句话数据管道上把分发出口抽象成 sinkJSON 文件 / Parquet / Kafka / Redis下游按需订阅多平台适配上给每个平台写一个 adapter统一成callback(消息类型, 数据字典)一种签名上层代码零改动API 封装上用 Flask 暴露 start / stop / messages 三个接口就能把这个命令行工具变成多租户服务。避坑速查Q启动就连不上A先确认 live_id 正确且该房间正在直播ttwid 和 room_id 的获取偶发失败重跑一次通常就好。Q签名计算报 GBK 编码错A把 subprocess 的 Popen 编码参数改成 utf-8或改用 sign_v0.js execjs 的备用路径。Qa_bogus 偶尔失败A代码注释已说明成功率不是 100%捕获异常后重试即可。Q某类新消息解析报错A在protobuf/douyin.proto补上对应 message用 protoc betterproto 重新生成 douyin.py再在分发表里加一行。Q为什么直播结束程序自己退了AWebcastControlMessage的 status3 是下播信号处理器里主动调了stop()属正常行为。Q能同时抓多个直播间吗A每个房间 new 一个DouyinLiveWebFetcher实例用线程池统一管理注意控制并发连接数。Q长时间跑内存持续上涨A边收边处理、及时落盘不要在内存里攒完整消息流同时盯队列深度有积压就加 worker。小结DouyinLiveWebFetcher 的价值在于把WebSocket 长连接 JS 签名逆向 Protobuf 解析三件事压进一条稳定管线4 行代码即可看见实时弹幕收包、解压、解析、分发的架构则可以直接搬到任何网页实时流场景。把它当学习样例读一遍再改造成你的目标平台是最省事的路线。【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 抖音直播数据抓取实战指南：WebSocket逆向与实时弹幕分析的4行代码入门
抖音直播数据抓取实战指南WebSocket逆向与实时弹幕分析的4行代码入门【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcherDouyinLiveWebFetcher 是一个基于 Python 的抖音直播间网页版直播数据抓取工具核心链路是WebSocket 长连接接收实时消息、JS 签名逆向通过连接校验、Protobuf 协议解析把二进制流还原成弹幕、礼物、进场、统计等结构化数据。下文按 5 分钟、30 分钟、1 小时、1 天、1 周五个投入档位带你从看见数据走到上线运维。5 分钟 · 看见数据先跑通终端里的实时弹幕读完这节你会知道这个项目到底输出什么、解决什么问题。运行main.py后终端会持续滚动类似这样的内容【进场msg】[79026102598][男]尘埃 进入了直播间 【礼物msg】X L 送出了 为你点亮x1 【点赞msg】小程๑ 点了9个赞 【统计msg】当前观看人数: 22164, 累计观看人数: 43.6万 【聊天msg】[67197561586]说谎: 去拿 去拿去哪 【粉丝团msg】恭喜 安好 成为粉丝团第289687名成员抖音网页版直播间没有公开的开放接口直播间的消息流只推送给浏览器。DouyinLiveWebFetcher 的思路是让 Python 扮演浏览器用同一个连接通道、同一套签名算法去订阅消息从而把聊天、礼物、进场、点赞、统计这类事件原样拿到手。它解决的核心问题就一个——不靠人工盯屏把直播间里的实时事件变成可编程的数据流。30 分钟 · 搞懂原理长连接、签名与二进制协议读完这节你能向别人讲清楚项目做的三件事建一条 WebSocket 长连接、算出连接所需的签名、解析 Protobuf 二进制帧。为什么用 WebSocket 长连接而不是 HTTP 轮询WebSocket 是一种建立一次握手后、双方都能随时发数据的持久连接协议而 HTTP 轮询是你每隔几秒主动问一次有没有新消息。维度HTTP 轮询WebSocket 长连接数据发起方客户端定时请求服务器有消息就推延迟受轮询间隔限制秒级消息到达即推送毫秒级带宽每次请求都带完整请求/响应头一条连接只传消息体连接状态无状态断了无感长连接需要心跳保活适合场景低频数据弹幕这类高频事件流直播间的弹幕是高频事件流用轮询意味着消息到了服务器却在你两次请求的间隙里等了几秒且每次空轮询都浪费带宽所以长连接是这里唯一合理的选型。WebSocket 连接生命周期从取 cookie 到心跳保活这一小节回答连接是怎么一步步建立并维持下去的。整条生命周期在liveMan.py里分五步取 ttwid先访问直播页首页从响应 cookie 里拿到ttwid抖音用来标识访客的凭证。取 room_id请求直播间页面用正则从 HTML 里抽出roomId——注意live_id地址里的数字不等于room_id两者都要。拼装 wss 连接串把 room_id、设备平台、浏览器标识等一串参数拼进 WebSocket 地址并追加签名下一节讲。建连用 websocket-client 的WebSocketApp注册on_open / on_message / on_error / on_close四个回调后run_forever()连接不断则阻塞收包。保活握手成功后开一个独立线程每 5 秒发一个payload_typehb的心跳帧以 PING 帧形式发出服务器若标记need_ack则回发一个 ack 帧确认存活。断开时on_close回调会去查一次开播状态判断是下播还是网络问题。直播间连接签名是怎么算出来的这一小节回答为什么 wss 地址最后必须挂一个signature参数以及它是怎么得到的。抖音的校验分三层项目逐一对应处理校验项作用项目实现ttwid cookie标识访客身份直接请求直播页获取wss 连接签名防止伪造连接串执行sign.js计算__ac_signature / a_bogus房间状态等接口的参数校验纯 Python 实现 JS 脚本计算wss 签名的计算路径很直白先把 13 个参数live_id、aid、room_id、identity 等按固定顺序拼成kv,格式的字符串取 MD5再把这个 MD5 值喂给一段 JS——sign.js是字节跳动的byted_acrawler混淆脚本人工看不太懂所以项目用 mini_racer 在进程内嵌一个 V8 引擎直接执行它调用get_sign拿到签名拼到 URL 末尾。为什么必须执行而不是重算脚本被混淆了逆向出等价 Python 代码的成本远高于直接跑它而 mini_racer 自带 V8不需要你再装 Node.js。另外两个校验项里__ac_signature项目在ac_signature.py里用纯 Python 重写了算法输入域名、nonce、UA、时间戳输出签名串a_bogus则交给a_bogus.js计算代码注释里写明它的成功率不是 100%失败重试即可。Protobuf 协议解析二进制帧是怎么变成结构化数据的Protobuf 是一种比 JSON 更省流量、速度更快的二进制序列化格式——同样的内容用字节表示字段靠编号区分。这一小节回答收到的每个二进制包内部长什么样。帧是两层嵌套外层 PushFrame只描述这个包是什么log_id、payload_type、payload 等内层 Response才是真正的消息集合messages_list、need_ack、internal_ext。收到包后的动作是按 PushFrame 解析外层 → 对 payload 做 gzip 解压 → 按 Response 解析得到一组 Message每条 Message 带一个method消息类型名和一段 payload该类型的私有字节。protobuf/douyin.proto里用 proto3 语法定义了 Response、Message、ChatMessage、GiftMessage、PushFrame 等全部结构项目用 betterproto一个把 .proto 编译成 Python dataclass 的生成器生成protobuf/douyin.py于是解析就变成ChatMessage().parse(payload)一行调用取message.user.nick_name、message.content这些字段即可。1 小时 · 跑通链路安装、启动与数据流走读读完这节你能在自己机器上装好项目、跑起来并说清一个数据包从到达到打印的完整路径。环境准备与安装命令环境要求很轻Python 3.7 即可签名计算靠 mini_racer 内嵌 V8不需要 Node.js。git clone https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher cd DouyinLiveWebFetcher pip install -r requirements.txtrequirements.txt里只有 5 个依赖requestsHTTP 取 cookie/页面、websocket-client长连接、betterproto 2.0.0b6协议解析、PyExecJS 与 mini_racer两个 JS 执行引擎分别服务新旧两条签名路径。只有当你需要改动协议字段时才要装 protoc25.1重新生成protobuf/douyin.py。4 行最简启动代码拿到 live_id直播间网页地址末尾的那串数字后启动只需要这几行from liveMan import DouyinLiveWebFetcher fetcher DouyinLiveWebFetcher(510200350291) # 换成你的直播间 live_id fetcher.start()start()内部会依次完成取 ttwid、取 room_id、算签名、建连、启心跳线程然后阻塞收包打印。关键参数与 config.yaml 配置说明当前版本没有独立的 config.yaml关键参数都硬编码在liveMan.py中。如果你要扩展成多房间生产版建议把它们外置成config.yaml先对照这张表知道该外置哪些配置项当前取值代码位置说明心跳间隔5 秒_sendHeartbeat的time.sleep(5)调太小浪费流量调太大易被断下播判定status 3_parseControlMsg收到即调用stop()房间状态接口live_id a_bogusget_room_statusa_bogus 失败需重试签名脚本sign.js可切 sign_v0.jsgenerateSignature新版走 mini_racer旧版走 execjs数据流走读收包 → 解压 → 解析 → 分发这一小节回答一条消息在_wsOnMessage里经过的四步。核心逻辑浓缩如下package PushFrame().parse(message) # 1. 收包外层帧 response Response().parse(gzip.decompress(package.payload)) # 2. 解压内层 if response.need_ack: # 3. 回 ack 保活 ack PushFrame(log_idpackage.log_id, payload_typeack, payloadresponse.internal_ext.encode()).SerializeToString() ws.send(ack, websocket.ABNF.OPCODE_BINARY) for msg in response.messages_list: # 4. 按类型分发 handler {WebcastChatMessage: self._parseChatMsg, WebcastGiftMessage: self._parseGiftMsg, WebcastMemberMessage: self._parseMemberMsg}.get(msg.method) handler and handler(msg.payload)分发的目标由method字段决定项目当前处理 13 种method含义处理器WebcastChatMessage聊天弹幕_parseChatMsgWebcastGiftMessage礼物_parseGiftMsgWebcastLikeMessage点赞_parseLikeMsgWebcastMemberMessage进入直播间_parseMemberMsgWebcastSocialMessage关注主播_parseSocialMsgWebcastRoomUserSeqMessage当前/累计观看_parseRoomUserSeqMsgWebcastFansclubMessage粉丝团变动_parseFansclubMsgWebcastControlMessage下播状态_parseControlMsgWebcastRoomRankMessage 等排行榜、流配置等对应_parse*Msg注意分发处包在try/except里——某类消息解析失败只跳过不会拖垮整条连接这是长连接程序的基本防御。1 天 · 让数据干活仪表板、告警与业务场景读完这节你知道如何把终端打印升级为指标、告警以及哪些业务场景值得做。实时指标仪表板把 13 类处理器从print改成累加器即可——聊天量、礼物价值combo_count 计件数、进场速率、并发观看人数统计消息里的 total按窗口聚合推给 Grafana 或一块简单的 Web 看板。因为数据源本身就是实时的仪表板天然不需要定时刷新。敏感词与异常行为告警在聊天处理器里挂一层规则——敏感词表命中即告警再用滑动窗口统计消息速率、礼物频率、观众增速超过阈值比如每秒 100 条弹幕、单位时间礼物激增触发刷屏/水军/冲榜类告警。规则表和阈值都该做成可热更新的配置而不是写死在代码里。业务场景一览场景实现方式价值直播电商监控监听礼物、商品榜消息关联口播时间点评估带货节奏与转化节点内容安全敏感词过滤 异常行为检测提前干预降低违规风险竞品分析多实例同时监控多个直播间对比互动数据支撑运营决策用户行为分析按 user_id 聚合进场/发言/送礼轨迹构建活跃用户画像数据产品原始消息落库后二次加工对外提供看板或 API1 周 · 上线与扩展Docker、监控与并发读完这节你有一份可照抄的容器化方案和监控清单以及三个扩展方向。Docker 容器化镜像就是一个 Python 薄层装依赖、跑main.py即可配合restart: unless-stopped让断线后进程自动拉起FROM python:3.11-slim WORKDIR /app COPY . /app RUN pip install -r requirements.txt CMD [python, main.py]监控指标上线后重点盯四件事指标、频率与阈值给一张表直接照用监控指标采集频率告警阈值建议工具连接成功率每分钟 95%Prometheus Grafana消息处理延迟每 5 秒 1000msGrafana内存占用每分钟 80%cAdvisorCPU 占用每分钟 70%node_exporter并发与优化要点心跳已经放在独立线程不会阻塞收包解析和落库可以再丢进线程池 队列做到收包快、处理快、写盘批量化。大房间数万观众时先观察队列深度再决定是加 worker 还是只保留需要的消息类型增量解析省掉不关心的字段。扩展方向每个两句话数据管道上把分发出口抽象成 sinkJSON 文件 / Parquet / Kafka / Redis下游按需订阅多平台适配上给每个平台写一个 adapter统一成callback(消息类型, 数据字典)一种签名上层代码零改动API 封装上用 Flask 暴露 start / stop / messages 三个接口就能把这个命令行工具变成多租户服务。避坑速查Q启动就连不上A先确认 live_id 正确且该房间正在直播ttwid 和 room_id 的获取偶发失败重跑一次通常就好。Q签名计算报 GBK 编码错A把 subprocess 的 Popen 编码参数改成 utf-8或改用 sign_v0.js execjs 的备用路径。Qa_bogus 偶尔失败A代码注释已说明成功率不是 100%捕获异常后重试即可。Q某类新消息解析报错A在protobuf/douyin.proto补上对应 message用 protoc betterproto 重新生成 douyin.py再在分发表里加一行。Q为什么直播结束程序自己退了AWebcastControlMessage的 status3 是下播信号处理器里主动调了stop()属正常行为。Q能同时抓多个直播间吗A每个房间 new 一个DouyinLiveWebFetcher实例用线程池统一管理注意控制并发连接数。Q长时间跑内存持续上涨A边收边处理、及时落盘不要在内存里攒完整消息流同时盯队列深度有积压就加 worker。小结DouyinLiveWebFetcher 的价值在于把WebSocket 长连接 JS 签名逆向 Protobuf 解析三件事压进一条稳定管线4 行代码即可看见实时弹幕收包、解压、解析、分发的架构则可以直接搬到任何网页实时流场景。把它当学习样例读一遍再改造成你的目标平台是最省事的路线。【免费下载链接】DouyinLiveWebFetcher抖音直播间网页版的弹幕数据抓取2025最新版本项目地址: https://gitcode.com/gh_mirrors/do/DouyinLiveWebFetcher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考