1. 先想清楚评论抓取到底能干什么做评论抓取这件事最开始往往是出于很朴素的需求。我自己第一次动手是因为要给一个视频做选题分析想知道观众对某个话题的真实反应而不是只看弹幕里刷的几句话。评论区比弹幕更有信息密度有完整表达、有观点倾向、有点赞互动把这些数据拉下来才能量化“大家到底在讨论什么”。往后在实践中逐步发现这类数据的需求面真的很宽。做内容运营的人会想知道哪条评论被顶到前排、用户的槽点集中在哪做市场调研的人会关注一个产品相关视频下的用户反馈把评论里的高频词提取出来就能大致判断口碑方向做学术研究的人会需要评论数据做情感分析或话题演化分析哪怕是普通用户也想把自己喜欢的视频评论区留存一份做一些词频统计或围观数据变化。本质上评论区就是一个公开的文本样本库而抓取只是把它从网页上变成结构化数据的第一步。技术难度并不高但有几个关键点决定你能不能稳定、高效地把数据拿到手——接口怎么找、参数怎么理解、反爬怎么应对、数据怎么存。这篇文章就围绕这些点展开给出一个可以直接上手的方案。需要说明的是这篇文章讲的所有方法都是针对公开评论数据的采集用途限定在个人学习、内容分析和学术研究范围内。抓取行为需要遵守平台规则控制请求频率不要对平台服务造成压力同时注意不要采集和传播个人隐私信息。合规红线划在前面剩下的技术细节我们可以放开来聊。2. 技术路线选型为什么首选接口方式2.1 三种常见抓取思路的横向对比针对评论区数据业界常见的做法有三种。第一种是模拟浏览器操作用自动化工具打开网页版评论区模拟滚动和点击来触发加载再对页面元素做解析提取。第二种是直接分析网页背后的数据接口通过构造HTTP请求获取JSON数据。第三种是寻找第三方配套工具或现成库直接调用封装好的函数。这三种方式我全都试过最推荐的是第二种——直接对接接口。理由很直接评论区是动态加载的纯页面解析需要处理异步渲染、懒加载、元素结构变化稍有不稳定就会导致解析失败而接口返回的是结构化JSON字段清楚、分页明确、数据量可控。模拟浏览器操作虽然能绕开一些签名校验但它吃内存、速度慢、而且一旦页面改版整套选择器就要重写维护成本非常高。从请求量来看接口方式也更轻量。获取一页评论就是一次普通请求返回几十KB数据而自动化工具每操作一次就要加载一整套网页资源效率和接口方式差了不止一个数量级。对于需要长期、大规模采集的场景接口方式几乎是唯一合理的选择。2.2 自主实现与现成库的取舍网上有不少现成的爬虫库封装了B站视频信息、评论获取、弹幕获取等功能用起来确实方便。但我仍然建议你自己动手实现一遍核心逻辑原因有几个。第一现成库为了兼容各种场景往往做得比较重很多你根本用不到第二评论接口的参数其实不多自己实现并不费事第三最关键的是——接口逻辑并不复杂但当你依赖第三方库时一旦平台调整参数或接口路径你会被迫等待库作者更新而自己实现了核心逻辑出了问题半小时内就能定位修复。所以我的建议是核心请求逻辑自己写个别辅助功能比如BV号转cid、时间戳转换可以借助轻量库。后面给出的代码就是完全自主实现的版本没有任何第三方爬虫框架的依赖。2.3 为什么公开接口就能拿到数据很多初学者会有一个疑问不登录能拿到评论吗答案是可以的。B站的评论区对未登录用户本身就是可见的网页端的评论数据接口也是公开可访问的接口只是对于高频请求有一定的频率控制。正是因为公开抓取公开的评论数据在技术层面是可行的合规层面的关键就在于请求频率和数据用途。这里要强调一个概念公开不等于无限制。平台对每个IP的请求频率都有隐性限制如果单线程高频请求短则几十次长则几百次就可能触发风控轻则返回异常数据重则暂时封禁IP。所以后面会重点讲到频率控制策略这是整个项目能不能长期稳定运行的关键之一。3. 核心机制拆解评论加载与字段结构3.1 评论区的加载逻辑在动手写代码之前必须理解平台的评论加载机制。打开任意一个视频页面评论区的加载是异步的——页面框架先渲染然后脚本向接口发起请求拿到JSON数据后动态填充到页面上。这也解释了为什么直接下载HTML源码看不到评论内容因为请求发生在页面加载之后。评论本身分为两级。一级评论是楼层的根节点直接挂在视频下二级评论则是某个一级评论下面的回复。接口的分页逻辑以一级评论为主第一页返回一批一级评论点击“查看更多回复”或在评论底部翻页才会加载更多的二级评论。这个层级关系在数据结构和采集策略上都要注意。3.2 评论接口参数逐项拆解评论接口的核心参数主要有以下几个理解它们是整个教程的关键。参数名含义说明type评论类型视频评论固定为1oid视频对象ID视频数据里的cid不是BV号sort排序方式0按热度排序1按时间排序cursor分页游标第一页为0后续翻页需要带上服务器返回的游标mode评论模式固定为3表示获取根评论oid是最容易搞错的地方。视频的BV号是用户看到的ID但评论数据挂在cid上。要获取cid需要先请求视频信息接口根据BV号解析出对应的cid然后再拿cid去请求评论数据。流程上必须分两步走。sort参数代表排序策略。按热度排序时评论顺序由点赞数、回复数等综合权重决定按时间排序则是按发布时间倒序排列。两种排序对应的分页游标逻辑不太一样时间排序的下一页游标通常就是当前页最后一条评论的时间戳而热度排序的游标则是一个单独的字符串标识由服务器返回。3.3 数据结构与关键字段拿到JSON响应后核心数据在data.replies字段中它是一个数组每个元素代表一条一级评论。每条评论的字段非常丰富常用字段梳理如下rpid评论ID唯一标识可用于去重mid评论者用户IDroot所归属的根评论ID如果为0说明自身就是根评论parent父评论ID如果为0说明是根评论message评论正文文本like点赞数ctime发布时间戳Unix秒级rcounts该评论下的回复数量replies如果该评论的回复已经被加载会包含二级评论数组。在text额外的子字段中还会包含评论的格式化内容、表情信息、提示等。对数据分析来说最核心的字段就是message、like、ctime、rpid这四个。中间三个字段决定了你对评论做排序、筛选、去重等操作时有没有足够的依据。3.4 响应外层结构与状态判断整个JSON响应外层结构基本固定在code、message、data这样的骨架内。code为0表示请求成功data为null表示该视频没有评论data不为空时除了replies还有一个关键的cursor字段。cursor字段承担了分页游标的作用。它里面包含类似next下一页游标值、is_end是否已加载完全部评论这样的子字段。正确做法是每请求一页都从这一页的响应中提取cursor用它构造下一页的请求。不要自己拼接页码因为游标是一个不透明的标识平台可能在任何时候调整它的编码方式保持“服务器给什么我就用什么”是最稳妥的策略。4. 完整实现从环境准备到数据落地4.1 环境准备开发语言选择Python主要因为它处理JSON和数据结构足够顺手第三方库生态也完善。需要安装的依赖只有三个pip install requests pandas openpyxlrequests负责HTTP请求pandas负责数据整理openpyxl用于把结果导出为Excel。如果你后续想存储为JSON或CSVpandas不是必须的但用它做数据清洗和预览确实方便。4.2 第一步BV号转cid先简单解释一下BV号和cid的关系。BV号是用户可见的视频编号但评论、弹幕、播放地址这些数据都挂在cid上。获取cid的接口路径相对稳定核心代码如下import requests HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.bilibili.com/ } def bv_to_cid(bv_id: str) - int: url https://api.bilibili.com/x/web-interface/view params {bvid: bv_id} resp requests.get(url, paramsparams, headersHEADERS, timeout10) data resp.json() if data.get(code) ! 0: raise ValueError(f视频信息获取失败: {data.get(message)}) return data[data][cid]这一步的本质是调用视频信息API拿到cid之后再进入评论接口流程。注意Referer头要带上这是常规的反爬校验之一缺失Referer可能会被拒绝。4.3 第二步构造评论请求评论接口的请求参数我们已经拆解过代码实现上需要封装一个函数让它接受cid、排序方式、游标三个参数返回解析好的评论列表和下一游标。COMMENT_URL https://api.bilibili.com/x/v2/reply/main def fetch_comments(cid: int, sort: int 0, cursor: int 0): params { type: 1, oid: cid, sort: sort, cursor: cursor, mode: 3, } resp requests.get(COMMENT_URL, paramsparams, headersHEADERS, timeout10) data resp.json() if data.get(code) ! 0: raise RuntimeError(f评论请求失败: {data.get(message)}) replies data.get(data, {}).get(replies) or [] next_cursor data.get(data, {}).get(cursor, {}).get(next, 0) is_end data.get(data, {}).get(cursor, {}).get(is_end, False) return replies, next_cursor, is_end这里有个容易踩坑的细节当评论区没有评论时返回的data可能不是字典而是null所以需要用or []来兜底否则会直接抛出TypeError。4.4 第三步字段提取与清洗拿到原始replies数组后不要急着存入文件先做字段投影——把多层嵌套的JSON拍平成一张扁平的表格只保留后续分析真正用到的字段。def flatten_comment(reply: dict) - dict: return { rpid: reply.get(rpid), user_id: reply.get(mid), username: reply.get(member, {}).get(uname, ), content: reply.get(content, {}).get(message, ).strip(), like: reply.get(like, 0), reply_count: reply.get(rcount, 0), time: reply.get(ctime, 0), }提取content时要注意评论正文在content.message字段里而content内部还有一堆富文本相关字段不要取错了。如果只做文本分析message字段就够了但如果后续要做表情还原才需要去处理content内的emote、at_name等字段。4.5 第四步分页循环与全量抓取分页循环是整个抓取流程的核心骨架也是最容易出现死循环的地方。标准写法是用while循环不断请求下一页每次拿返回值更新游标直到is_end为True或达到最大页数限制。import time def crawl_all_comments(cid: int, sort: int 0, max_pages: int 500): all_comments [] cursor 0 page 0 while not is_end and page max_pages: replies, cursor, is_end fetch_comments(cid, sort, cursor) page 1 for reply in replies: all_comments.append(flatten_comment(reply)) print(f已抓取第{page}页累计{len(all_comments)}条评论is_end{is_end}) time.sleep(random.uniform(1.5, 3.0)) return all_comments注意每页请求之间必须加延迟。随机延迟比固定延迟效果好因为固定间隔更容易被风控系统识别。1.5到3秒是我实测下来不同网络环境下都还算安全的区间。如果采集量特别大还可以考虑增加请求失败后的重试机制和指数退避。4.6 第五步数据存储与导出数据到位后直接用pandas转为DataFrame然后导出为Excel或CSV分分钟完成。import pandas as pd def save_to_excel(comments: list, filename: str): df pd.DataFrame(comments) df[datetime] pd.to_datetime(df[time], units, utcTrue).tz_convert(Asia/Shanghai) df df.drop(columns[time], errorsignore) df.to_excel(filename, indexFalse) comments crawl_all_comments(cid) save_to_excel(comments, comments.xlsx) print(f共导出{len(comments)}条评论)这里把Unix时间戳转换成了可读的北京时间方便直接浏览。用to_csv也一样指定encodingutf-8-sig可以解决Excel打开CSV乱码的问题。4.7 二级评论的抓取方案上面实现的是根评论的抓取。如果需要连带二级评论需要另外请求回复接口。流程是先拿到根评论的rpid再调用回复接口带上rpid请求对应评论下的回复列表。核心区别在于参数回复接口使用的是rpid字段而不是oid。实现方式是在循环遍历根评论时对每条根评论的rpid发起一次回复请求再合并数据。要注意回复接口同样有分页游标也要限制每页之间的请求频率。二级评论抓不抓取决于分析目标。如果只是做词频统计和情感分析只抓根评论就足够如果要做互动关系网络分析二级评论连回复对象一起抓下来才有价值。5. 深入优化排序策略、增量抓取与反爬规避5.1 时间排序与热度排序的选择sort0按热度排序适合快速获取最有代表性的评论sort1按时间排序适合做时间段观察比如想看某个事件爆发后前几个小时的评论变化。实测下来两类排序返回的数据量和完整度也会有差异。热度排序下如果你不翻页翻到底拿到的通常是高互动评论样本会有明显的头部倾斜时间排序则能覆盖到发布最早的评论但需要更多页才能覆盖完整的讨论过程。建议根据分析目的决定不要把两类排序的评论混合去重因为同一视频下不同排序返回的是同一批内容的不同顺序混合反而容易造成重复统计直接在排序参数上做区分即可。5.2 增量抓取与去重策略如果隔段时间重新采集同一个视频的评论你并不需要重新抓全部。设计方案是每次抓完把最大的rpid或最后一条评论的时间戳保存下来下次抓取时把游标直接推进到上次的位置之前或者抓完后按rpid做去重只保留新增部分。去重逻辑最好同时使用rpid和user_idtime的组合作为参考。rpid是唯一ID正常情况下不同请求不会产生重复ID但假如平台调整了评论ID的生成规则用user_id加time做交叉验证会更稳妥。动作很简单但增量抓取能省大量时间和流量。特别是做长期舆情观察时每天增量抓一次数据表从零构建成历史库效率和完整度都远超每次全量抓取。5.3 风控触发后的排查与处理项目跑着跑着突然拿不到数据了这是最常见的意外情况。先不要慌按照下面的顺序定位问题。第一步看返回的code。如果code不为0说明接口拒绝了请求需要仔细读message字段多数情况下会直接提示触发风控。第二步检查是否被要求验证码。第三步检查IP状态。如果是办公室或校园网出口整个网段的请求都集中在一个IP上更容易触发风控——这是多用户共享出口IP导致的常见现象通常过一段时间限制会自动解除。应对的核心思路是降低请求密度。延迟从2秒提高到5秒以上把并行抓取改成单线程串行同时暂时停掉重复任务。幻想有永久绕过风控的方案是不现实的平台风控策略一定会迭代而控制请求频率本身就是最安全、最可持续的做法。5.4 代理池和并发要不要上看到这里有些读者可能会问我数据量大能不能用并发加代理池来加速我的回答是先想清楚你的数据量级。个人项目和分析场景每天采集几千到几万条评论单线程加2到3秒延迟完全可以胜任。一个视频的评论撑死几千条单个视频即使评论上万单线程也就是几十分钟的事完全在可接受范围内。并发和代理池会引入新的问题IP来源分散可能被判定为异常模式、代理的稳定性和速度参差不齐、代理的合规性又是一层额外考量。除非你在做全网级别的数据监测否则不要给自己找这个麻烦。技术选型的原则是——不引入超出需求数倍的复杂度。6. 实操过程记录一个真实案例的全流程演示6.1 案例背景与目标我用一个公开的技术分享视频作为实测对象。这个视频时长约15分钟播放量中等评论区有300多条根评论。目标很直接抓取全部根评论做词频统计和情感倾向初判。6.2 执行过程首先拿到视频BV号调用bv_to_cid函数获取cid紧接着测试单页评论请求确认接口返回正常。首次请求返回了约20条评论总评数为351条说明大约需要18页左右才能完成全量抓取。然后设置随机延迟2秒运行整个抓取过程耗时约50秒。中间有一页请求返回了网络错误按重试逻辑延时8秒后自动恢复没有中断。最终得到有效评论349条比接口显示的351条少2条——那2条是系统检测为异常或已删除的评论在返回的JSON里直接没有提供内容。最后把字段投影结果转为DataFrame同步导出Excel文件做人工质量复核。整个过程代码改动不到5行从写代码到跑完数据一气呵成。6.3 数据质量观察实际上抓下来的评论数据里有几条是空字符串这通常是因为用户发送的评论本身是图片或表情不包含文本。该情况在数据清洗时直接过滤掉即可。还有一个观察值得分享热度排序下前几页的评论点赞数动辄几百上千后面翻几页点赞数基本落在个位数这符合“头部集中”的内容分布规律。如果你做情感分析时只采集前一两页数据结论会明显偏向高互动用户的倾向而不代表整体评论的倾向。要得出更客观的结论就应该完整抓取全部评论。6.4 后续延展数据拿到之后我做了简单的词频统计把评论中的高频词拉出来对标视频的主题。整个过程只用了几行代码但输出的结果比人工爬评论直观得多。如果要进一步做情感倾向分析可以考虑引入情感词典做无监督打分也可以接入大模型批处理接口逐条做情绪分类——这完全取决于你的任务复杂度与资源预算。7. 常见问题与排查技巧实录7.1 请求返回code为-101或-111这两个错误码分别表示账号未登录或签名校验失败。出现-101时说明你请求的接口需要登录态而评论接口按现有参数设计不需要。这时要检查是否少传了参数比如type、mode必须在请求参数中保持完整。出现-111意味着请求头签名有缺失最常见的原因是未带上User-Agent或Referer把这两个请求头补上即可。另外一个容易忽略的原因是服务端时钟偏差如果本机时间误差过大校验也会失败先校时再看能不能解决。7.2 评论数据返回null返回data为null可能有两种情况一是这个视频确实没有评论二是你用了错误的oid。先用浏览器开发者工具在网络面板里查看视频页真实发出的评论请求对比你的请求参数着重检查oid值是否等于cid很多时候是把BV号直接当作oid传进去了这就是典型的参数错位。7.3 抓取中途被限制表现特征为请求返回正常但replies变成了空数组又或者响应里的所有内容被替换成了一段验证提示。解决办法很简单立即停掉任务休息30分钟以上之后降低请求频率重新开始。如果使用了公网IP进行批量采集受限可能性成倍增加建议先更新IP再继续。这里补充一个实测心得——对于长时间运行的任务每隔10分钟打印一次进度与当前游标一旦出错方便从最近的游标恢复而不是重头开始。7.4 评论数量与实际看到的不一致部分评论在接口返回中是折叠状态平台会根据内容识别结果或用户举报状态把部分评论隐藏正规接口不会返回这类折叠评论的数据。所以不必纠结于“差几条”接口返回的数据就是平台正常展示的数据。只要抓取过程中没有跳错误数据就是可信的。7.5 数据导出乱码或格式异常CSV文件用Excel打开出现乱码时保存时指定encodingutf-8-sig即可解决。评论正文中的换行符和特殊符号在导出到Excel时会把单元格内容截断或转义清洗时提前把换行符替换为空格一步到位省得后处理。8. 评论数据的常见分析玩法代码能稳定跑通后思路可以延伸到下游。这里分享几个易上手、效果又明显的分析玩法相信都值得一试。第一个是词频分析。把每条评论的文本切词后统计高频词结合停用词表过滤掉“哈哈”“的”“了”等无意义词得到的话题词云能快速反映出评论区最集中的讨论点。第二个是情感倾向初判用情感词典给每条评论计算正负向情感得分再做时间维度上的趋势曲线可以看出视频发布后观众情绪的变化过程。第三个是互动权重分析把评论的点赞数当作权重重新计算观点分布——高赞评论的倾向往往代表用户的主流态度低频但高赞的异议观点也很有观察价值。这些玩法都在数据抓取之外需要额外编写文本处理逻辑但对评论数据的价值挖掘来说抓回数据只是第一步分析才是目的。如果被问到“抓评论到底干嘛”这几个方向就能让回答变得很实在。9. 最后分享几点个人实操体会项目跑了一段时间后几个心得值得单独拿出来分享。第一接口文档不存在的日子里浏览器开发者工具是最可靠的老师。调试时打开页面的“网络”面板筛选XHR请求就能清晰看到平台自己发起的评论请求参数照着填准没错。这个方法放在任何平台的接口分析场景里都通用。第二数据抓取最需要认真对待的不是代码而是频率与节奏。抓取速度跑得太激进不仅影响自己被限制的风险也会增加平台的资源压力。调低频率、让请求“优雅”地慢下来长期看才是最可持续的方案。我的习惯是把延迟设置成随机值并且加上重试逻辑稳定性和速度兼得。第三抓取代码写完后记得把数据保存为结构化的表格文件并保留原始JSON响应备份不要只留处理后的成果。你永远无法预判后续分析会不会需要重新解析某个字段原始数据的留存能让你在做任何回溯分析时都不被动。第四字段文档要自己沉淀。评论接口的关键返回字段——rpid、mid、ctime、like、content——每换一个项目都重新翻阅一次很浪费时间给自己的笔记里维护一份接口字段速查表将来的抓取和数据分析工作都会简单很多。