做自媒体运营的人谁还没被“查别人家数据”这事折磨过。想跟UP主谈合作要看他粉丝量做竞品分析要盯他涨粉趋势哪怕自己发视频也总想对比一下同体量账号的粉丝数和关注数到底是什么水平。手动打开网页一个个看翻两三个账号就烦了用第三方数据站要么数据滞后要么关键字段要付费。其实B站自己就有公开的数据接口只要你找对路径几分钟就能写个小脚本把任意用户的粉丝数、关注数一次性拉下来。今天这篇就把整个方案盘清楚顺带把接口原理、鉴权方式、常见的坑都捋一遍。1. 为什么需要批量获取粉丝数与关注数真实场景与方案选型1.1 三个高频场景谈合作、做竞调、盯增长先说我最常遇到的一类需求。很多做商务对接的朋友每天要筛一批UP主看他们的粉丝数、关注数、近期播放量判断是不是适合投放。粉丝数和关注数往往是最先看的两个指标粉丝数决定账号的量级关注数能侧面反映这个UP主平时是不是也在持续刷B站、做内容调研。一个一个点开主页看一天看几十个账号眼睛都要瞎掉。第二类是竞品分析。我自己做账号的时候就经常要看同类目的头部UP主他们的粉丝涨得快不快、关注数有没有异常变化。比如一个账号粉丝涨得猛但关注数也很高可能说明他本身是重度用户或者在做联动运营。这些信息单看某一个时间点没什么感觉但一段时间内连续记录就能看出对方的运营节奏。第三类是自己账号的增长监控。把自己每天的粉丝数、关注数定时记录下来配合视频发布节奏能清楚地看到哪条内容真正带来了关注转化。这比只看后台的播放数据更有参考意义因为粉丝数才是账号长期价值的核心。1.2 手动查询、第三方数据站、直接调接口到底选谁先聊方案对比。手动查最直接但效率太低适合只看一两个账号的轻度需求。第三方数据站比如一些B站数据分析平台确实方便拿来就看但它们普遍存在三个问题一是数据更新有延迟粉丝数这种实时变化的指标可能差好几个小时二是很多关键功能要会员三是数据口径不一定跟B站官方完全一致有的站点把“粉丝数”和“获赞数”混着展示挺误导人的。直接调接口是效率最高、数据最准的方案。B站官方对用户空间信息是开放了接口的只是没有挂在显眼的文档里很多人不知道。自己写脚本拉数据不仅实时而且可以把历史数据存下来做成自己的数据库。后面想看任何趋势分析随时都能查。但自己调接口也有门槛需要处理登录态、签名校验、请求频率这些问题。这些坑我后面都会讲到。综合来看如果你只是偶尔查一两个账号用浏览器F12看接口也行如果你要批量监控、长期跟踪一定要用脚本方式。1.3 核心概念先说清关注数、粉丝数、B站账号体系动手之前先把几个概念理清不然接口返回的数据会让你怀疑人生。B站里每个用户有一个唯一的数字ID叫midmember ID。这个mid是后续所有查询的关键参数。账号主页URL里那串数字就是mid比如space.bilibili.com/2这个2就是该用户的mid。粉丝数也就是常说的follower数指关注了这个账号的B站用户总数。关注数即following数指这个账号自己主动关注了其他多少个账号。这两个数据在接口里分别用follower和following表示。还有一个容易混淆的点B站接口里粉丝数和关注数并不一定在同一个接口里返回。用户空间信息接口返回的是一个用户的基本资料包含粉丝数而关注关系的统计接口返回的是更精确的关注/粉丝对偶数据字段上也分得更细。所以你在取数的时候不要只依赖一个接口要组合着用才能拿全数据。后面我会详细说这两个接口怎么配合。2. 获取用户数据的核心原理接口路径、鉴权方式与请求要点2.1 用到的两个核心接口用户空间信息与关注关系统计实际取数过程中我用的最多的两个接口分别是https://api.bilibili.com/x/space/acc/info这个接口根据mid返回用户的空间信息包括用户名、签名、头像、等级以及一个关键的字段follower也就是粉丝数。属于最常用的基础接口。另一个是https://api.bilibili.com/x/relation/stat?vmid某个mid这个接口返回关注关系的统计数据里面的follower是粉丝数following是关注数。和上一个接口的主要区别在于它更专注于关系链数据而且返回速度相对稳定适合批量查询时做交叉验证。我常用的策略是批量查询时优先请求relation/stat因为它的返回字段更干净、数据量小、请求成本低。只有在需要同时获取用户昵称、简介、等级等展示信息时才去请求space/acc/info。这样既能拿全数据又能降低被风控的概率。2.2 Cookie与wbi签名为什么必须带上身份标识这里要重点说明鉴权问题。B站很多接口早期可以匿名访问后来逐渐收紧现在调用用户相关信息接口至少要带一个有效的Cookie否则很容易返回-101未登录或-352风控校验失败。Cookie从哪来最简单的办法是浏览器登录B站后按F12打开开发者工具在网络请求里随便点开一个api接口从请求头里复制Cookie字段。注意这个Cookie是有有效期的短则几天、长则几个月过期之后重新复制一份就行。除了CookieB站还搞了一套wbi签名机制不少接口都需要对请求参数做特定规则的签名否则服务端会拒绝响应。这个wbi签名早期版本固定且简单后来不断升级现在版本会定期更换密钥。如果你用Python的requests库直接请求没做签名可能一开始能通过一阵子就突然报错。很多第三方库已经把这套逻辑封装好了比如bilibili-api-python这个库用起来就省心很多。这里也给个建议如果你是第一次接触B站接口不要一上来就自己造轮子处理wbi签名先直接用封装好的库跑通流程等理解原理之后再自己实现细节不然很容易被各种签名报错劝退。2.3 返回字段拆解follower、following、mid、name各代表什么接口返回的是一个JSON结构这里以relation/stat为例正常的返回长这样{ code: 0, message: 0, ttl: 1, data: { mid: 2, following: 7, whisper: 0, black: 0, follower: 28659832 } }code为0表示请求成功。data里最关键的就是following和follower分别代表关注数和粉丝数。whisper是悄悄关注数black是拉黑数一般用不上。mid是查询的用户ID可以用来确认返回的数据就是目标用户的。如果code不是0需要对照B站公开的错误码表排查常见的有-101未登录、-352风控、-404资源不存在等。space/acc/info的返回结构会更复杂一些包含name、sign、sex、level等字段粉丝数也在data.follower里。有一点要留心这两个接口的follower字段在绝大多数情况下数值一致但偶尔会存在短时间不同步的情况遇到的时候别慌重试几次或者过几分钟再查一般就恢复正常了。3. 手把手实操用Python批量获取多个用户的粉丝数和关注数3.1 环境准备与依赖安装我默认你已经装了Python 3.8以上版本。需要用到两个关键库requests负责HTTP请求pandas负责数据保存和分析。如果你之前没装过直接在终端执行pip install requests pandas如果想省去手写签名的麻烦可以加装一个bilibili-api-pythonpip install bilibili-api-python用这个库的话内部会把wbi签名、请求头封装好代码写起来更简洁。不过我个人还是建议先学会用requests直接请求一遍接口知道底层在干什么遇到问题排查起来才有方向。3.2 核心代码实现与参数说明直接上完整示例代码这是我自己一直在用的简化版注释已经写得很细import requests import time import pandas as pd # 从浏览器复制的Cookie注意替换成你自己的 COOKIE SESSDATA你的会话数据; bili_jct你的csrf_token; buvid3你的buvid3 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.bilibili.com/, Cookie: COOKIE } def get_user_stat(mid): 查询单个用户的粉丝数和关注数 :param mid: B站用户ID :return: dict包含mid、follower、following等 url https://api.bilibili.com/x/relation/stat params {vmid: mid} resp requests.get(url, paramsparams, headersHEADERS, timeout10) data resp.json() if data[code] ! 0: print(f查询mid{mid}失败错误码: {data[code]}, 信息: {data.get(message)}) return None info data[data] return { mid: info[mid], follower: info[follower], following: info[following] } if __name__ __main__: # 测试查询一个用户 result get_user_stat(2) print(result)这里说一下几个关键点。COOKIE里的SESSDATA是最核心的登录凭证一般很长bili_jct是CSRF Token部分接口写操作会用到查询接口不一定需要但带着更稳妥buvid3是设备标识不填有时候也能通但带上可以降低被风控的概率。HEADERS里面的User-Agent和Referer也必须带很多反爬逻辑会校验这两个字段。我不止一次遇到不带Referer导致请求被拒的情况开始还以为是自己代码写错了排查了半天才发现是请求头问题。3.3 批量查询与数据保存从一个用户到一百个用户单个用户能查了批量就很简单。准备好一批mid列表循环调用上面的函数把结果存到DataFrame里就行。注意加一个延时我一般设为1到2秒宁可慢一点也别触发风控。if __name__ __main__: mid_list [2, 5, 10, 100, 1000] # 这里换成你要查询的mid列表 results [] for mid in mid_list: r get_user_stat(mid) if r: results.append(r) # 延时1.5秒避免请求过快 time.sleep(1.5) df pd.DataFrame(results) # 保存到本地CSV文件 df.to_csv(b站用户粉丝数据.csv, indexFalse, encodingutf-8-sig) print(df)这里有个细节保存CSV时我用了utf-8-sig编码而不是默认的utf-8。主要是因为后面如果用Excel直接打开CSVutf-8格式会乱码而utf-8-sig带BOM头Excel可以正确识别。mid列表从哪来我一般用B站的排行榜、分区热门视频的UP主ID或者已有的账号列表。如果你想查自己的关注列表可以调用x/relation/followings接口通过vmid参数拿到自己关注的所有用户mid然后再逐个查询他们的粉丝数和关注数这样就构建出一个完整的竞品监控列表了。3.4 请求频率设计怎么防止把接口调到风控这一段特别重要因为我早期吃过亏。B站对接口请求频率是有限制的短时间高频请求很容易触发风控返回-352错误码严重的会临时封禁IP或Cookie持续时间从几分钟到几小时不等。我的经验是低频场景一天查几次随便查一般不会被风控。中频场景每小时查几百个账号每个请求间隔至少1秒。高频场景秒级监控大量账号不建议个人脚本硬扛优先用官方提供的更完整的接口或者考虑降低监控频率。另外建议给脚本加上异常重试机制。遇到网络超时或-352的时候先等几秒再重试。重试三次仍然失败就跳过当前用户继续后面的任务最后统一看日志。不要死循环重试那样反而更容易被加大风控力度。一个简化版的重试逻辑可以参考def get_user_stat_with_retry(mid, max_retry3): for attempt in range(max_retry): try: r get_user_stat(mid) if r: return r # 如果返回None可能是风控或临时错误多等一会再试 time.sleep(3 attempt * 2) except Exception as e: print(f请求异常: {e}, 重试第{attempt 1}次) time.sleep(3 attempt * 2) return None这套重试逻辑看起来简单但在实际运营中帮我挡掉了大量偶发性的请求失败数据完整率从90%左右提升到99%以上。4. 实战中踩过的坑常见问题与排查技巧4.1 问题一接口返回-101或-352是什么情况-101基本上就是未登录或登录态失效。最常见的原因是Cookie过期了。B站的SESSDATA有效期不是永久的有时候人还在浏览器里登录着但脚本里的Cookie已经失效了。我的处理方式是写脚本前先测一次test get_user_stat(2) if test is None: print(Cookie可能已失效请重新复制) else: print(Cookie正常)-352是风控校验失败通常是因为请求频率太高、请求头异常、或者IP被临时限制。遇到-352先停下来歇几分钟再试不要硬顶着冲。如果频繁出现把请求间隔拉长到3到5秒同时检查User-Agent和Referer有没有设置对。4.2 问题二粉丝数为什么和网页上看到的不一样这种情况我也遇过。刚发布完全新数据之后接口返回的粉丝数和网页上显示的粉丝数偶尔会差几百甚至几千。原因在于B站的数据是分库的不同业务模块的数据同步存在延迟。尤其是大UP主粉丝数变动非常频繁实时数、展示数、接口数三者之间本来就不是强一致的。正常做法是脚本采集的数据主要用于趋势分析轻微的短时差异不影响结论。如果你要精确核对某个时间点的数据建议连续采集三次取中位数或者明确记录采集时间不要纠结于某个瞬间的数值差异。4.3 问题三批量运行时频繁超时怎么处理批量跑几百个用户的时候经常会出现某几个请求特别慢甚至超时。这通常不是你的代码问题而是网络波动或者目标服务器响应压力。我遇到过一整个循环跑下来中间断了七八个请求数据不完整。解决方案就是前面提到的重试机制。另外可以把超时时间设置得更保守一点比如timeout15。如果某个用户连续多次都查不到记录下来后续单独补查。不要因为个别失败就中断整个任务。4.4 常见问题速查表错误码 / 现象可能原因解决办法-101Cookie失效或未登录从浏览器重新复制Cookie-352请求频次过高触发风控降低请求频率延长间隔时间检查请求头-404用户不存在或mid错误核对mid是否正确确认用户未注销返回的follower和网页不一致数据多端同步延迟多次采集取稳定值记录采集时间请求超时网络波动或服务器响应慢设置超时时间增加重试机制部分mid查询成功、部分失败目标用户隐私设置或账号异常跳过该用户记录日志后续补查这里单独提醒一句B站官方对数据接口有使用规范个人学习、小规模数据分析都没问题但千万不要搞大规模爬取更不要拿别人的数据做商用变现合规风险非常大。我的原则是只采集自己做账号管理和竞品分析需要的最小数据集控制在合理频率内不做任何侵入性操作。5. 拿到数据之后怎么用数据分析和账号增长思路5.1 用关注数与粉丝数判断账号健康度很多人只看粉丝数就下结论其实这是不够的。关注数和粉丝数配合起来看能判断一个账号的健康度。举个例子一个UP主粉丝数很多但关注数也非常高比如说粉丝5万关注8000多。这说明他虽然产出内容但同时也在大量关注别人通常是在做互助涨粉或者频繁参与活动粉丝的含金量可能不如关注数低的账号。反过来一个账号粉丝数不高但关注数很少比如粉丝只有2000关注数只有50说明这个账号很可能靠优质内容自然涨粉粉丝的黏度和忠诚度都相对较高互动数据通常也会更好看。还有一个小技巧是看粉丝数和获赞数的比值。如果粉丝数不高但获赞数很高说明内容质量不错只是曝光度还没起来这类账号往往是“潜力股”适合早期关注或合作。5.2 跟踪涨跌趋势发现内容方向的信号单个时间点的数据价值有限连续跟踪一段时间才有意义。我自己的做法是每天固定时间跑一次脚本把关注的几十个竞品账号的粉丝数、关注数都记录下来存到数据库里。这样积累两到三周就能画出涨粉曲线。曲线突然陡增的那一天对应的往往就是他们发布爆款内容的时间点。回头去翻那天的视频分析爆款的标题、封面、选题、节奏就能总结出一些可复用的内容策略。相反如果某个账号出现掉粉也要关注是内容质量下滑还是发布了有争议的选题。这些信息不会直接写在数据里但数据变化会提醒你去查看原因这就是数据监控最大的价值。5.3 想提升自己的粉丝数从数据反推内容策略聊回到“关注数和粉丝数”这个目标本身。如果你是想提升自己的账号数据技术手段只是帮你把数据拿回来真正让数据涨上去的还是内容。我这里说的是从数据反推策略的方法。先找到你所在赛道的头部账号用脚本拉近30天他们每天的粉丝增量找出涨粉最快的几条视频逐个拆解选题是不是踩中了热点标题是不是有强烈的情绪表达封面是不是足够清晰直接发布时段是不是卡在流量高峰期然后看你自己的内容用同样的方式拉自己的粉丝数据找出涨粉效果最好的内容和涨粉几乎为零的内容对比其中的差异。我做了半年多账号之后发现一个规律真正带来粉丝转化的不是播放量最高的视频而是那些“让人产生关注冲动”的视频比如系列教程的第一期、人设鲜明的观点表达、或者极具识别度的个人风格内容。播放量只是入口关注转化才是核心。所以我的建议是把脚本跑起来把数据存起来用数据指导内容而不是盲目追热点。数据只是工具最终的目标是通过内容让用户认可你、关注你。等你把整套流程跑顺了就会发现关注数和粉丝数不再是每天焦虑的指标而是你内容方向决策的参考坐标系。