直接在正文打字机开写。用从业者口吻不做任何前置说明从 ## 1. 开篇开始。1. 项目概述与路线规划说句实话写一个B站爬虫这件事在圈子里的热度一直没降过。不只是因为B站本身是年轻用户最集中的内容社区更是因为它的数据有很强的研究价值视频元数据、用户画像、弹幕情绪、充电互动、榜单趋势、评论观点每一个切面都能接出不少有意思的项目。我最早动手写B站爬虫是为了给一个内容分析的小工具补充数据源后来陆陆续续在爬虫基础上接了弹幕情感分析、视频封面批量下载、UP主作品盘点汇总前后迭代了好几版踩过不少坑也摸索出一套比较稳定的实现思路。这篇博文不打算把代码堆成完整项目贴出来而是把整个思路拆开讲清楚数据从哪来、接口怎么找、反爬怎么应对、并发怎么设计、数据怎么存。就算你之前没写过爬虫照着这个思路走一遍也能独立写出一套能稳定运行的B站数据采集工具如果你已经有经验这篇文章里关于接口细节、风控应对和常见错误码的梳理应该也能帮你省下不少排查时间。很多人一上来就会去找现成的开源项目然后直接跑。这种方式不是不行但现成代码往往只适配当时的环境B站接口一变、风控一升级就废了。真正要掌握的是如何分析一个视频页面背后用到了哪些接口这种通用能力。只要这套能力建立了今天爬B站、明天爬小红书、后天爬音频平台逻辑是完全一致的打开网页端控制台、观察网络请求、筛出JSON接口、构造请求头、处理分页和校验参数、最后落库。所以在开头我不急着给代码先讲清楚B站内容载体的特殊之处。B站的核心内容载体是视频 弹幕 评论区 用户资产的组合结构和传统纯图文网站很不一样。一个视频有bv号、av号、cid有多个分P有对应的字幕、封面、热评还可能挂在某个收藏夹、对应某个分区。这意味着爬虫不能只盯一个接口而是要有一个以视频为中心、向外辐射的数据模型。还有一点需要提前说清楚写爬虫这件事本身是技术学习和数据获取的正常行为但使用时要遵守目标平台的服务条款尊重内容版权和用户隐私采集数据时注意频率不要对目标服务造成压力。我后续所有方案都是在这个前提下设计的这也直接影响并发参数和数据存储策略的取舍。2. 接口分析与数据链路拆解2.1 先搞清楚视频标识体系的转换关系B站视频标识体系的转换是新手最容易卡住的第一个点。BV号是现在对外展示的字符串比如BV1xx411c7mD但很多核心接口在内层依然使用av号aid和分P编号cid做参数。值得庆幸的是B站提供了一个转换接口用BV号可以直接换到完整的视频元信息返回里就把aid和cid都带上了用不着自己实现base58解码算法。我常用的转换链路是这样拿到一个BV号之后先请求视频明细接口拿到基本信息包括aid、cid、标题、简介、分区、发布时间、UP主mid、封面、时长、点赞投币收藏数据。这一步是所有后续采集的起点。很多新手会误以为cid就是视频唯一的id实际上cid是某个视频下某一P的标识一个多P视频会有多个cid播放地址、弹幕都是按cid维度来取的。说个我踩过的坑刚开始我以为直接拿BV号就能取弹幕结果请求弹幕接口需要cid而一个视频有多个P时每个P的弹幕池是独立的。当时没有先取分P列表直接拿第一个cid去请求导致后面几个P的弹幕全是空的。正确的顺序是BV号 - 视频明细拿到分P列表每个P有cid - 指定cid获取弹幕、字幕、播放流。这个顺序是整个B站爬虫的最基本数据流。2.2 视频页与播放页的关键请求字段视频页面在浏览器里打开时会发出大量的网络请求。直接全部复刻这些请求没有必要核心其实就几个JSON接口。我以网页端为例把链路拆开视频明细接口传入bvid或aid返回JSON字段极其丰富里面最关键的有pic是封面地址、owner中的mid是UP主ID和时间轴信息。这些字段在后续做数据可视化时非常重要比如分析一个UP主的内容节奏就要用到pubdate字段。播放地址接口是另一个关键请求它需要视频的cid和bvid或aid作为参数在请求头中带上Referer必须是视频页地址返回内容里的accept_description字段会列出当前视频支持的清晰度选项。这个接口在B站改了风控之后对签名参数比较敏感网上能搜到一堆历史版本的签名算法但说实话最新版本即使不拼签名也能拿到较低清晰度的流地址普通应用场景够用。如果确实需要高清晰度建议用手机客户端协议或者官网推出的工具走正规渠道。弹幕接口这里要单独说一下。老式的弹幕地址返回的是XML格式解析不复杂但弹幕内容不全。要拿到完整弹幕需要看弹幕协议接口它能返回protobuf二进制的弹幕数据需要自己写解码逻辑。早期很多人直接请求XML接口发现弹幕条数明显偏少其实是拿错了接口。我在项目里直接集成了protobuf解码逻辑实测能拿到该cid弹幕池全部历史数据效率也很高。除了这三类用户信息接口、评论接口、收藏夹接口、动态流接口也都值得关注。以查某个UP主的成分为例这个需求其实就是用户画像分析把某个用户的历史评论、投稿、点赞记录全部拉出来做关键词统计和偏好分析。B站查成分工具在社区里火过一阵技术原理并不神秘就是用户接口 评论接口 动态接口的组合遍历。2.3 从分享链接反解目标mid的技巧有时候你手上只有一个分享链接比如手机端复制出来的一串短地址里面可能带了一个mid参数或者没有。这时候直接用短地址去请求是拿不到数据的需要先做一步重定向解析请求分享短链接让它302跳转到完整视频页或用户主页从跳转后的URL里提取bv号或mid。我在处理用户数据和UP主作品收集时经常用这个技巧。拿到一个用户主页链接先确认mid然后去请求用户投稿接口。这个接口和权限、限流关系不大返回的是UP主的视频列表和空间数据。要注意的是接口返回有分页每页的数量可以自己指定循环翻页时建议控制速度避免触发风控。这里补充一个实际经验用户投稿接口的返回里有一个字段表示总数但总数不可信爬虫时偶尔会遇到总数和实际翻页累计数对不上的情况。后来处理方式是直接以翻页结束为准如果当前页返回为空或者条数小于每页limit就视为已到末页。这个判断逻辑比依赖总数可靠得多。3. 爬虫主体框架与工具选型3.1 请求库、解析库与数据格式的整体搭配技术栈的选型不需要太花哨我用的是Python 3.10 requests 官方json解析配合Pandas做数据清洗存储则按规模选择SQLite或MySQL。这个组合的优势在于requests的会话保持功能可以统一管理cookies和headers内置的json解析器对B站接口返回的嵌套JSON处理非常方便Pandas可以在数据进入数据库之前做一轮快速去重和格式整理。有的朋友喜欢用Scrapy这当然没问题Scrapy的下载中间件和Item Pipeline机制非常适合大规模采集。但我的实际体验是B站这种中等体量的站点用requests配合线程池就能达到足够高的采集效率Scrapy反而多了一层框架约束。特别是当你需要反复调试接口参数时requests脚本的灵活度明显更高。所以我的建议是小型项目直接requests真正需要做全站级采集时再上Scrapy不要为了用框架而用框架。异步方案也可以考虑aiohttp asyncio在IO密集型的接口采集场景下效率非常恐怖。但异步方案在调试代理、处理超时重试时心智负担会重一些。我在实际项目中是先用requests把整套流程跑通再去把高频接口改成异步这样既保证了开发效率也保证了运行效率。3.2 请求头完整配置与第一道风控防线B站在今年的风控强度明显比几年前高了不少直接裸请求返回-412错误码的概率很高。所谓-412本质是风控拦截意思是请求被判定为脚本行为。要避免这个情况最基础也是最重要的一步就是把请求头伪装到位。我自己常用的请求头配置如下headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Referer: https://www.bilibili.com/, Origin: https://www.bilibili.com, Accept: application/json, text/plain, */*, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Cookie: 你的完整Cookie }这里有个容易被忽略的点Referer字段的值应该跟当前请求的页面语义匹配。比如请求视频播放地址时Referer要带完整的视频页URL请求用户主页接口时Referer就应该是用户主页URL。如果Referer和页面语义对不上虽然大多数接口不校验但有些风控策略就是在细节上卡你。Cookie是另一个关键因素。未登录状态能请求的数据接口非常有限很多接口会要求登录或者至少有一个有效的buvid。我强烈建议在开发调试阶段就登录网页版B站把Cookie完整复制出来放进请求配置里。同时要注意Cookie是有时效的B站会把过期的Cookie静默降级返回注册甚至未登录状态的数据看起来一切正常但关键字段是缺的。这种坑贼难排查后来我写了个检查函数每次跑数据前先请求一下登录状态接口如果检测到未登录就立刻告警。3.3 并发与调度策略到底用线程还是协程并发这个话题在技术圈讨论度一直很高。B站爬虫的并发设计我的个人结论是中小型项目用线程池就够了ThreadPoolExecutor配合一个任务队列就能把效率提升好几倍而且代码可读性好、出问题好排查。真正需要上分布式爬虫或者异步框架的场景是当你采集规模达到一定量级、单机性能受限、需要多节点协作的时候那种场景再去做复杂度叠加也不迟。我在项目中实际使用的方案是生产者-消费者模式 线程池。生产者负责把待采集的BV号或UID列表放入队列消费者线程从队列中取任务执行请求、解析、入库。这个模式的好处是将数据调度和实际采集解耦方便控制速率、随时暂停、动态扩充线程数量。线程数我一般控制在4到8之间每两个请求之间随机睡眠0.5到1.5秒整体效率和安全性能得到比较好的平衡。协程方案也不是不能考虑。在异步模式下IO等待时间被充分利用单进程可以同时挂起几百个请求吞吐量确实比线程池高一个量级。但异步爬虫在遇到代理超时、连接断开、需要重试时代码逻辑会变得复杂调试成本也更高。所以我建议异步方案放在第二阶段优化第一版先用最直观的方式把功能跑通。如果你真的要爬上百万量级的数据那分布式爬虫就该出场了。常见做法是Redis队列做任务分发多个节点同时消费多节点之间通过代理IP池分散出口IP。这种架构的好处是天然支持水平扩展但相应的监控、节点管理、任务去重都需要自己搭建成本不低。我的建议是除非你明确知道自己需要百万级以上的数据否则单机多线程已经足够了过度设计是很多人一开始最大的问题。4. 核心模块解析四大功能点的技术实现4.1 视频封面与多P资源的批量提取视频封面提取在热搜词里出现得非常频繁很多创作者做合集封面、做素材整理时都需要批量获取。实现起来其实非常简单视频明细接口返回的pic字段就是封面原图地址。但这里有一个细节B站的封面有多种分辨率pic字段默认给的是单张图片地址如果你想拿更高分辨率的超大图可以在原地址上做域名和路径的替换也可以去UP主封面上传目录下翻目录。常规做法是直接保存pic原图清晰度已经能满足大多数场景。批量提取封面时需要遍历一个批次里的所有BV号逐个请求明细接口并保存pic字段。这个过程会遇到一个问题视频太多时如果逐个请求接口再下载图片速度很慢。我的做法是分两步走第一步先把所有视频的元信息和封面URL整理成表格第二步再用一个独立的下载线程池去批量下载图片。这样即使某个封面下载失败也不影响元数据的采集需要重试时只要根据表格里的URL再次下载即可。顺带说一句多P资源处理起来比封面要麻烦不少。多P视频在明细接口里会有分P列表每个P都有独立的cid和标题。如果你要做按P下载视频流或者按P采集弹幕必须先将分P列表解析并存储到本地数据库再逐P处理否则很容易漏数据或者数据串P。4.2 SVG字幕与JSON字幕的解析转换B站的字幕机制比较特殊普通视频的字幕有两种存在形式一种是CC字幕存储在json字幕接口里每条字幕包含开始时间、结束时间和文本内容另一种是AI生成的字幕早期呈现为SVG形式需要从SVG文件里提取文字和坐标再拼接成完整的字幕文本。很多人在做视频内容分析时会被字幕解析这一步卡住。因为打开SVG字幕文件看到的全是标签和坐标数据跟正常字幕格式完全对不上。处理SVG字幕的思路并不复杂SVG里有多个文本节点每个节点对应一个字幕元素节点包含x坐标、y坐标、字号、颜色等信息有的还带透明度。字幕文本可能被拆分成多个元素需要根据坐标关系重新排列组合。比较实用的做法是先按y坐标分组同一行的元素按x坐标排序拼接最后再按时间顺序整理成标准字幕文件。如果你对SVG结构不熟处理起来会很耗时所以很多工具会直接优先用JSON字幕接口只有拿不到JSON字幕时才考虑SVG解析。我这里建议一个优先级先请求JSON字幕接口如果返回空数据或未开启字幕再降级到SVG字幕解析。JSON字幕接口返回的格式非常规整转成SRT或者纯文本都很快这也是在线B站JSON字幕转文本这类工具的技术基础。字幕数据在文本分析和内容总结场景中价值极高做完一次转换后面做词频统计、关键词提取、稿子复刻都会非常方便。4.3 弹幕解码与批量导出方案弹幕一直是B站研究的热点数据源无论是做情感分析还是做弹幕文化研究都需要完整地拿到弹幕数据。前面提过B站的历史弹幕有两种获取方式一个是老式XML接口一个是protobuf二进制接口。XML接口的响应结构简单、解析容易但它只返回部分弹幕特别是在弹幕数量多的视频里拿到的数据很不完整。protobuf接口返回的才是完整的弹幕池但需要自己解码。protobuf解码的核心在于理解B站弹幕消息的定义结构。简单来说弹幕消息里包含弹幕内容、发送时间、弹幕模式、字号、颜色、发送者uid等字段。使用Python的google.protobuf库把B站弹幕消息定义成proto文件然后编译成Python模块就可以直接对返回的二进制数据进行解析。解码之后的数据建议先落一份CSV或JSON再做后续的数据分析因为弹幕数据一旦丢失重新采集的成本非常高。批量导出弹幕时我建议按视频维度组织目录每个视频一个子目录目录下按P编号存放弹幕文件。这样目录结构清晰后面做数据分析时可以直接按目录遍历。还有一个技巧历史弹幕的获取有段接口可以把每一个段的数据保存下来避免一次性拉取过多数据导致超时或风控。4.4 评论区、动态流与充电内容的边界处理评论区是除了弹幕之外最有价值的用户反馈数据源。评论接口按视频aid拉取支持分页可以通过插入cursor参数来翻页也可以按时间范围或者热度排序获取评论。我实际采集时的策略是先按热度排序拿头部评论再按时间排序拿按时间倒序的全部评论宁可多请求几次也不要在翻页时漏数据。动态流接口可以拿到UP主发布的图文动态、转发信息对于了解用户行为习惯很有帮助。这个接口相对比较简单返回的是标准JSON包含动态类型、发布时间、内容文本、图片列表等字段。循环翻页时同样要注意速率控制动态流接口对频率限制比较敏感我之前就遇到过翻页翻到一半被临时限制的情况。说到充电视频这个需要特别注意边界。网上确实有各种充电视频解析工具和提取网站但那些手段我强烈不建议使用。充电视频本质是UP主设置的付费内容未经授权去解析和下载无论从平台规则还是版权角度看都有问题。如果你确实需要充电内容做研究可以联系UP主获取授权或者使用官方付费渠道观看。别小看这一条很多爬虫项目最后的翻车不是技术上不行而是没有守住合规底线。用户信息采集也有类似的边界要求。B站用户中心有很多字段是只对自己可见的比如手机号、邮箱、私密收藏夹这些不要尝试去碰。我处理的用户数据主要集中在公开的投稿、公开的动态、公开的评论上这些信息本来就是用户公开发布的内容采集和使用时注意保护用户隐私不做数据滥用就行。5. 数据存储与稳定性保障5.1 表结构设计从单表到关联查询当数据量小的时候把所有数据塞进一个CSV文件或者JSON文件是没有问题的。但如果你打算长期采集、增量更新、关联分析建议一开始就设计好数据库表结构。我自己最常用的B站数据表有这几张视频明细表、UP主信息表、弹幕数据表、评论数据表、字幕数据表、采集日志表。视频明细表的核心字段我用bvid做唯一键同时存av号、cid列表、UP主mid、标题、简介、封面URL、分区ID、标签列表、发布时间、点赞投币收藏等。UP主信息表用mid做唯一键存用户名、头像、签名、粉丝数、视频数等信息。弹幕表和评论表是明细表量会很大建议直接按视频维度加索引。采集日志表用来记录每次采集的批次、数量、耗时、失败原因对排查问题非常有帮助。我给你一个实际的DDL片段参考CREATE TABLE video_info ( bvid VARCHAR(16) PRIMARY KEY, aid BIGINT, cid INT, title VARCHAR(255), description TEXT, pic_url VARCHAR(512), owner_mid BIGINT, pubdate INT, duration INT, view_num INT, danmaku_num INT, reply_num INT, favorite_num INT, coin_num INT, share_num INT, partition_id INT, tags JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );这个表结构已经能满足大多数视频数据管理需求。如果你还要做趋势分析可以再加一张每日统计表每天把热点视频的点赞、投币、收藏、播放数据快照存一次后续做时间序列分析就很方便了。5.2 数据库连接与字符集防坑B站标题和评论里经常会出现emoji和特殊符号这类字符在MySQL中存储时经常会遇到字符集不支持的问题报错信息一般是Incorrect string value。解决办法非常简单建表时把字符集设置为utf8mb4连接时也指定charsetutf8mb4。我在去年帮一个朋友排查数据入库报错时发现他的表是utf8字符集存emoji时直接报错改完字符集之后问题立刻解决。如果你用的是SQLite那更简单SQLite天然支持UTF-8基本上不会遇到字符集问题。在小规模项目里SQLite完全够用单文件部署也方便迁移。但SQLite在高并发写入时会有锁竞争问题多线程同时写入时会偶尔报database is locked错误所以如果采集线程较多且并发写入频繁我建议直接上MySQL省心很多。另外再分享一个经验写入数据库之前尽量把所有文本字段统一做一次类型转换和空值处理。B站返回的JSON里有些字段可能缺失直接写入会让程序崩溃。我的做法是写一个通用的clean函数把所有需要的字段统一转换成字符串或整数缺失的用空字符串或0代替。这个处理看似多写了几行代码但能显著减少入库时的意外。5.3 采集日志与断点续采爬虫项目里采集日志和断点续采功能绝对值得花时间设计。我之前吃过一次大亏连续跑了几个小时的数据采集因为临时网络波动断掉了结果前面的进度全丢了只能从头再来。从那以后我的所有采集中间都会动态记录进度每处理一个BV号就更新到一个progress文件或者数据库表中重启时检查进度直接从断点继续。记录进度的最简单方式是维护一个已完成任务集合每完成一个任务就往集合里add一个ID同时定期把集合内容同步到本地文件或数据库。新一批任务开始时先加载已完成集合跳过已经处理过的ID只处理剩余部分。这个机制实现成本低但对效率和稳定性提升非常明显尤其是面对几万个视频采集任务时。同时建议给每次采集任务生成一个词汇表日志记录任务开始时间、任务类型、参数范围、完成数、失败数、异常信息。这不只是为了追踪问题也是为了日后复盘当你发现某天的数据质量有问题时可以根据日志里的采集批次定位到对应的源数据快速排查。6. 高频问题排查与风控规避技巧6.1 错误码手册从-404到-412B站接口返回的错误码对新手来说是个不小的门槛。我在项目中整理了高频错误码的含义和应对策略这里直接分享给大家错误码含义常见原因处理方式-404请求资源不存在视频被删除、稿件失效跳过该任务标记失效-403访问被拒绝风控策略触发、IP被限降低请求频率更换代理-412请求被拦截请求头伪装不足、高频访问增强请求头添加延时换IP重试-352风控校验失败缺少cookie或wbi签名补充cookie检查签名逻辑-101账号未登录没有登录cookie确认登录态是否有效-111csrf校验失败bili_jct字段缺失检查和更新csrf token0成功无无遇到-412时我的第一反应不是疯狂重试而是先停下来检查请求头和频率。很多时候只要把User-Agent换成最新版本、补上Referer、把请求间隔拉长到3秒以上-412就会自动消失。频率控制是规避-412最有效的手段没有之一。6.2 网页能正常打开爬虫却一直被拦这个问题的根源在于浏览器带上了一整套隐式的指纹信息和完整的请求上下文而爬虫只带了几个headers自然容易被识别。即使你完整复制了浏览器的Cookie和请求头B站还是有办法通过TLS指纹、请求频率、行为模式等手段识别脚本。针对这个问题我的经验是按渐进增强的思路去处理。第一步确保所有基础请求头都是完整且和浏览器一致的第二步加入行为模拟比如在翻页之间随机等待移动鼠标轨迹模拟真实的浏览节奏第三步如果还是被拦就考虑代理IP。每次切换代理时注意不要一个代理IP连续请求太多次也不要频繁切换中间加一些固定延时让流量看起来更像真人。另外有一个小技巧把请求中的WBI签名参数处理好。B站现在对部分接口要求带上WBI签名这是通过对参数排序、拼接、再取MD5生成的一个校验值签名算法在GitHub上有很多实现搜索B站WBI签名就能找到。实现之后被-352拦截的概率会大大降低。6.3 视频下载后只有画面没有声音这个问题看起来很玄学其实是接口选择的问题。B站现在的视频存储格式分为DASH和FLV两种高清视频基本都是DASH格式它会将视频流和音频流分开存放视频流没有声音是正常的需要把视频流和音频流合并才有完整效果。我在处理时直接使用了FFmpeg合并实测速度很快几秒钟就能完成一条视频。合并命令很简单先把视频流和音频流分别下载到本地然后执行ffmpeg -i video.m4s -i audio.m4s -c copy output.mp4这里要注意DASH返回的m4s文件在直接播放时会报错但用户一般不是直接播放这些文件。用FFmpeg合并时尽量用-c copy参数只做容器封装转换不做二次编码既快又不会损失画质。如果视频流和音频流的时长有细微偏差可以用-shortest参数截短。6.4 代理池维护与请求频率控制的实际参数代理IP是所有爬虫项目绕不开的话题。B站的封禁策略偏向于对单个IP的访问频率做限制。解决思路很直接要么降低频率让单个IP不超阈值要么使用多个IP分散请求。我在项目里采用的代理策略是静态代理为主动态代理为辅维护一个可以随时更新的代理列表请求时随机选择一个代理如果某个代理连续失败三次就把它移出列表。需要特别说明的是国内很多代理IP服务的质量差异巨大我踩过很多坑后得出的经验是先测延迟再测连通率最后测目标站成功率。一个代理IP如果对B站请求的失败率高于5%就直接弃用。如果只是做低频小数据量采集其实用不到代理直接用本机IP、控制好请求间隔安全系数已经很高了。请求频率控制方面我建议的初始值每请求之间间隔至少1秒每个IP每分钟不超过30次请求。如果触发风控先把间隔翻倍再观察一段时间。频繁切换IP、超高频请求反而更容易被平台标记。7. 总结思考与实践建议写B站爬虫这几年我越来越发现真正的难点往往不是技术本身而是对数据链路和平台规则的理解。技术方案选型、接口分析、并发控制这些技能是可迁移的学会了就能用在不同的网站上。但每个平台的内容结构、接口风格、风控策略都有差异需要花时间去研究和适配。就我个人经验而言从零开始写一个B站爬虫最佳路径是先用少量视频手动验证所有接口的返回结构理清bvid、aid、cid、mid之间的关系然后写一个单线程的采集脚本把流程跑通跑稳定之后再加并发、加代理、加断点续采最后再去考虑分布式扩展。整个过程不需要一开始就上复杂架构按部就班地迭代反而能做出最稳定、最适配自己需求的工具。最后分享一个细节我当时为了处理大量采集到的弹幕数据专门写了词频统计和情感分析脚本后来把分析结果接入到一个可视化面板中能实时展示不同分区视频的弹幕情绪变化趋势。这个功能在团队内部分享时反响不错也让我意识到爬虫只是数据链路的最前端真正有价值的是数据之后的分析和应用。如果你也想做类似的事情建议从一开始就把数据质量管好不要为了快而牺牲准确性否则后面分析全是在垃圾数据上浪费功夫。