企业官网建设流程全解析

做自媒体运营的人，谁还没被“查别人家数据”这事折磨过。想跟UP主谈合作要看他粉丝量，做竞品分析要盯他涨粉趋势，哪怕自己发视频，也总想对比一下同体量账号的粉丝数和关注数到底是什么水平。手动打开网页一个个看，翻两三个账号就烦了；用第三方数据站，要么数据滞后，要么关键字段要付费。其实B站自己就有公开的数据接口，只要你找对路径，几分钟就能写个小脚本，把任意用户的粉丝数、关注数一次性拉下来。今天这篇就把整个方案盘清楚，顺带把接口原理、鉴权方式、常见的坑都捋一遍。

1. 为什么需要批量获取粉丝数与关注数：真实场景与方案选型

1.1 三个高频场景：谈合作、做竞调、盯增长

先说我最常遇到的一类需求。很多做商务对接的朋友，每天要筛一批UP主，看他们的粉丝数、关注数、近期播放量，判断是不是适合投放。粉丝数和关注数往往是最先看的两个指标：粉丝数决定账号的量级，关注数能侧面反映这个UP主平时是不是也在持续刷B站、做内容调研。一个一个点开主页看，一天看几十个账号，眼睛都要瞎掉。

第二类是竞品分析。我自己做账号的时候就经常要看同类目的头部UP主，他们的粉丝涨得快不快、关注数有没有异常变化。比如一个账号粉丝涨得猛，但关注数也很高，可能说明他本身是重度用户，或者在做联动运营。这些信息单看某一个时间点没什么感觉，但一段时间内连续记录，就能看出对方的运营节奏。

第三类是自己账号的增长监控。把自己每天的粉丝数、关注数定时记录下来，配合视频发布节奏，能清楚地看到哪条内容真正带来了关注转化。这比只看后台的播放数据更有参考意义，因为粉丝数才是账号长期价值的核心。

1.2 手动查询、第三方数据站、直接调接口，到底选谁

先聊方案对比。手动查最直接，但效率太低，适合只看一两个账号的轻度需求。第三方数据站比如一些B站数据分析平台，确实方便，拿来就看，但它们普遍存在三个问题：一是数据更新有延迟，粉丝数这种实时变化的指标可能差好几个小时；二是很多关键功能要会员；三是数据口径不一定跟B站官方完全一致，有的站点把“粉丝数”和“获赞数”混着展示，挺误导人的。

直接调接口是效率最高、数据最准的方案。B站官方对用户空间信息是开放了接口的，只是没有挂在显眼的文档里，很多人不知道。自己写脚本拉数据，不仅实时，而且可以把历史数据存下来，做成自己的数据库。后面想看任何趋势分析，随时都能查。

但自己调接口也有门槛，需要处理登录态、签名校验、请求频率这些问题。这些坑我后面都会讲到。综合来看，如果你只是偶尔查一两个账号，用浏览器F12看接口也行；如果你要批量监控、长期跟踪，一定要用脚本方式。

1.3 核心概念先说清：关注数、粉丝数、B站账号体系

动手之前，先把几个概念理清，不然接口返回的数据会让你怀疑人生。

B站里每个用户有一个唯一的数字ID，叫mid（member 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是有有效期的，短则几天、长则几个月，过期之后重新复制一份就行。

除了Cookie，B站还搞了一套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-python：

pip 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, params=params, headers=HEADERS, timeout=10) 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", index=False, encoding="utf-8-sig") print(df)

这里有个细节：保存CSV时我用了utf-8-sig编码，而不是默认的utf-8。主要是因为后面如果用Excel直接打开CSV，utf-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_retry=3): 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 问题三：批量运行时频繁超时，怎么处理

批量跑几百个用户的时候，经常会出现某几个请求特别慢甚至超时。这通常不是你的代码问题，而是网络波动或者目标服务器响应压力。我遇到过一整个循环跑下来，中间断了七八个请求，数据不完整。

解决方案就是前面提到的重试机制。另外可以把超时时间设置得更保守一点，比如timeout=15。如果某个用户连续多次都查不到，记录下来，后续单独补查。不要因为个别失败就中断整个任务。

4.4 常见问题速查表

这里单独提醒一句：B站官方对数据接口有使用规范，个人学习、小规模数据分析都没问题，但千万不要搞大规模爬取，更不要拿别人的数据做商用变现，合规风险非常大。我的原则是：只采集自己做账号管理和竞品分析需要的最小数据集，控制在合理频率内，不做任何侵入性操作。

5. 拿到数据之后怎么用：数据分析和账号增长思路

5.1 用关注数与粉丝数判断账号健康度

很多人只看粉丝数就下结论，其实这是不够的。关注数和粉丝数配合起来看，能判断一个账号的健康度。

举个例子：一个UP主粉丝数很多，但关注数也非常高，比如说粉丝5万，关注8000多。这说明他虽然产出内容，但同时也在大量关注别人，通常是在做互助涨粉或者频繁参与活动，粉丝的含金量可能不如关注数低的账号。

反过来，一个账号粉丝数不高，但关注数很少，比如粉丝只有2000，关注数只有50，说明这个账号很可能靠优质内容自然涨粉，粉丝的黏度和忠诚度都相对较高，互动数据通常也会更好看。

还有一个小技巧是看粉丝数和获赞数的比值。如果粉丝数不高但获赞数很高，说明内容质量不错，只是曝光度还没起来，这类账号往往是“潜力股”，适合早期关注或合作。

5.2 跟踪涨跌趋势，发现内容方向的信号

单个时间点的数据价值有限，连续跟踪一段时间才有意义。我自己的做法是每天固定时间跑一次脚本，把关注的几十个竞品账号的粉丝数、关注数都记录下来，存到数据库里。

这样积累两到三周，就能画出涨粉曲线。曲线突然陡增的那一天，对应的往往就是他们发布爆款内容的时间点。回头去翻那天的视频，分析爆款的标题、封面、选题、节奏，就能总结出一些可复用的内容策略。

相反，如果某个账号出现掉粉，也要关注是内容质量下滑，还是发布了有争议的选题。这些信息不会直接写在数据里，但数据变化会提醒你去查看原因，这就是数据监控最大的价值。

5.3 想提升自己的粉丝数：从数据反推内容策略

聊回到“关注数和粉丝数”这个目标本身。如果你是想提升自己的账号数据，技术手段只是帮你把数据拿回来，真正让数据涨上去的还是内容。

我这里说的是从数据反推策略的方法。先找到你所在赛道的头部账号，用脚本拉近30天他们每天的粉丝增量，找出涨粉最快的几条视频，逐个拆解：选题是不是踩中了热点？标题是不是有强烈的情绪表达？封面是不是足够清晰直接？发布时段是不是卡在流量高峰期？

然后看你自己的内容，用同样的方式拉自己的粉丝数据，找出涨粉效果最好的内容和涨粉几乎为零的内容，对比其中的差异。我做了半年多账号之后，发现一个规律：真正带来粉丝转化的不是播放量最高的视频，而是那些“让人产生关注冲动”的视频，比如系列教程的第一期、人设鲜明的观点表达、或者极具识别度的个人风格内容。播放量只是入口，关注转化才是核心。

所以我的建议是：把脚本跑起来，把数据存起来，用数据指导内容，而不是盲目追热点。数据只是工具，最终的目标是通过内容让用户认可你、关注你。等你把整套流程跑顺了，就会发现关注数和粉丝数不再是每天焦虑的指标，而是你内容方向决策的参考坐标系。