引言
在视频平台日益成为内容消费主阵地的今天，理解平台生态的运作规律——头部创作者如何崛起、粉丝群体如何形成、不同分区的内容如何吸引不同类型的受众——已经成为内容创作者、品牌方和数据研究者共同的刚需。某站作为国内最具代表性的视频社区之一，其UP主与粉丝之间形成的复杂社交网络，蕴含着巨大的分析价值。
比如，你想知道某个UP主的粉丝增长趋势，或者想分析某个分区头部创作者的共同特征。手动去一个个页面查看显然不现实。这时候，自动化抓取数据就成了刚需。无论是做数据分析、市场研究，还是单纯想监控自己的账号成长，掌握从某站获取用户数据的方法，都像拥有了一把打开数据宝库的钥匙。
然而，爬取某站的粉丝数据绝非易事。某站对爬虫有严格限制，直接高频请求会返回403错误。其反爬虫机制较为严格，拥有相对完善的反爬虫体系——如IP检测、频率限制及登录验证等，一旦爬取任务超出阈值，IP很容易被限制或封禁。
本文将从零开始，系统介绍如何爬取某站UP主的粉丝数据，并以此为基础构建用户画像、分析平台生态。文章将涵盖API接口分析、反爬突破策略、隧道代理集成以及数据应用的完整路径。
一、为什么要爬取粉丝数据？
1.1 从数据理解平台生态
某站的生态并非铁板一块——游戏区、知识区、生活区、音乐区等不同分区的用户画像迥然不同。通过爬取UP主的粉丝数据，我们可以回答一系列有趣的问题：
- 粉丝增长规律：一个UP主从0到百万粉，增长曲线是什么样的？爆发点在哪里？
- 粉丝重叠度：不同分区的头部UP主，粉丝重叠程度如何？跨圈层传播的路径是什么？
- 粉丝活跃特征：某个UP主的粉丝，同时关注了哪些其他UP主？这反映了怎样的内容偏好？
- 创作者生命周期：UP主从“冷启动”到“破圈”再到“稳定期”，各阶段的关键驱动因素是什么？
有开源项目以图结构视角建模某站的社交关系网络——将UP主视为节点，关注关系视为有向边，通过广度优先或改进的PageRank启发式策略进行种子扩展，从而系统性发现潜在高成长性创作者群体。这种基于粉丝关系网络的分析方法，显著区别于传统热门榜单式采集，能有效规避“马太效应”带来的样本偏差。
1.2 粉丝数据的商业价值
对于品牌方和MCN机构而言，粉丝数据是评估UP主商业价值的关键依据。粉丝数量、粉丝增长趋势、粉丝活跃度、粉丝画像（年龄、地域、兴趣偏好）等指标，直接决定了投放策略和报价谈判的底气。
二、某站粉丝数据API解析
某站提供了不少公开的API接口，允许我们在合规的范围内获取非敏感的用户公开信息。关键在于，我们要学会怎么礼貌地“敲窗”，而不是粗暴地“破门”。
2.1 核心API接口
接口一：获取用户关系统计数据
这是最基础的粉丝数据接口，用于获取一个用户的核心社交数据——关注数、粉丝数等：
GET https://api.bilibili.com/x/relation/stat?vmid={用户UID}
这里的vmid参数就是用户的UID，也就是一串数字ID。把链接直接粘贴到浏览器地址栏里回车，会返回JSON格式的数据：
{
"code": 0,
"message": "0",
"data": {
"mid": 35199034,
"following": 287,
"follower": 15234,
"black": 0
}
}
其中follower字段就是粉丝总数。
接口二：获取粉丝明细列表
如果需要获取具体的粉丝列表（而非仅有粉丝总数），可以使用以下接口：
GET https://api.bilibili.com/x/relation/followers?vmid={用户UID}&pn={页码}&ps={每页数量}
其中pn为页码，ps为每页数量（某站接口通常限制最大50，不可随意修改）。该接口返回的数据包含每个粉丝的UID、昵称、头像、签名等信息，是构建用户画像的核心数据来源。
接口三：获取用户详细信息
GET https://api.bilibili.com/x/space/acc/info?mid={用户UID}
返回用户的详细资料，包括昵称、性别、等级、注册时间、签名等。
接口四：获取用户关注列表
GET https://api.bilibili.com/x/relation/followings?vmid={用户UID}&pn={页码}&ps={每页数量}
用于获取某个用户关注了哪些UP主，这对分析粉丝的兴趣偏好和跨圈层传播路径至关重要。
2.2 鉴权与Cookie
对于公开数据的接口，部分情况下无需登录即可访问。但如果需要获取更详细的粉丝信息或进行高频采集，则需要携带登录态Cookie。
关键Cookie字段包括：
- SESSDATA：核心的会话凭证，证明已经登录
- bili_jct：通常用于需要安全验证的操作，虽然在某些接口中可能不是必须的，但带上它能更好地模拟浏览器行为，降低被风控的概率
获取方式：在浏览器中登录某站，打开开发者工具（F12）→ Network标签 → 找到任意请求 → 复制Cookie中的这两个值。
三、反爬挑战与应对策略
3.1 某站的反爬机制
某站的风控策略是多层次的：
| 反爬手段 | 具体表现 | 触发条件 |
| 请求频率限制 | 短时间内来自同一IP的请求过多时触发临时封禁 | 请求间隔<1-2秒 |
| 下载/采集量阈值 | 系统可能设置了单IP单日采集量上限 | 连续大量请求（如100次以上） |
| 行为模式识别 | 连续、规律的批量行为容易被识别为爬虫 | 请求模式过于规律 |
| User-Agent检测 | 对识别为自动化工具的请求进行拦截 | 使用默认UA或异常UA |
| 验证码拦截 | 弹出滑块验证码或人机校验 | 频率过高或IP异常 |
某站锁定机制的核心作用是控制和限制某些操作的执行，以保障系统的健康运行、防止作弊、维护数据的真实性与一致性。在实际应用中，锁定往往是与风控策略密切结合的，通过判断平台、用户等级和行为模式来做出动态的调整。
3.2 基础反爬措施
（1）User-Agent轮换
许多网站会检测HTTP请求的User-Agent字段来区分正常浏览器和爬虫程序。如果未设置或使用默认值，网站可能拒绝访问或返回错误页面。
建议构建多样化的UA池，每次请求随机选择一个：
USER_AGENTS = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/120.0.0.0",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/121.0",
# 覆盖不同操作系统和浏览器版本
]
（2）请求间隔随机化
新手最容易遇到的问题就是请求过快导致IP被封禁。建议合理设置请求间隔，使用正态分布或均匀分布模型控制操作间隔，避免固定频率触发风控。
单次访问间隔建议不低于3秒。
（3）Referer伪装
动态生成Referer列表，模拟从不同页面跳转过来的访问行为。
3.3 隧道代理：解决IP封禁的终极方案
即使你完美配置了User-Agent轮换和请求间隔控制，当采集规模达到一定量级时，IP封禁依然不可避免。某站对单个IP的请求频率有着严格的限制——同一个IP在短时间内发出大量请求，必然触发保护机制。
传统的解决方案是自行维护代理IP池，但这种方法存在两个核心痛点：
- IP质量参差不齐：免费代理资源已被大量滥用，可用性低、成功率无法保证
- 手动维护繁琐：需要持续检测IP有效性，被封后手动更换，爬虫频繁中断
隧道代理正是为解决这些问题而生。它的工作原理是：你不需要手动维护IP池，只需配置好隧道代理的接入信息。每次发送请求时，隧道代理会自动把流量引导至不同的出口IP——相当于给你的爬虫配备了一条专属的“IP安全隧道”。
站大爷隧道代理在爬虫场景中有几个突出的优势：
- 自动切换无感知：每次请求自动更换出口IP，无需手动干预
- 覆盖范围广泛：覆盖全国99%地域，即使是爬取那些需要本地化数据的场景时，也能够精确定位到相应地区
- 高可用架构：采用分布式集群设计，支持每秒万级IP切换，且自带IP质量检测模块，可自动淘汰低效节点
- 主备双隧道：持续更新IP池，稳定性有保障
- 灵活配置：支持精细化的IP轮换周期自定义设置
在爬虫中集成站大爷隧道代理
import requests
import time
import random
from typing import Optional, Dict, List
# 站大爷隧道代理配置
PROXY_CONFIG = {
"http": "http://隧道代理地址:端口",
"https": "https://隧道代理地址:端口"
}
USER_AGENTS = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/120.0.0.0",
]
def get_random_ua() -> str:
return random.choice(USER_AGENTS)
def fetch_with_tunnel(url: str, params: Dict = None, retry: int = 3) -> Optional[Dict]:
"""
使用隧道代理发送请求，自动处理IP切换
"""
headers = {
"User-Agent": get_random_ua(),
"Referer": "https://www.bilibili.com",
"Accept": "application/json"
}
for i in range(retry):
try:
response = requests.get(
url,
params=params,
headers=headers,
proxies=PROXY_CONFIG,
timeout=15
)
if response.status_code == 200:
return response.json()
elif response.status_code in [403, 429]:
# 隧道代理会自动切换出口IP，等待后重试即可
print(f"第{i+1}次请求被拒绝({response.status_code})，隧道代理自动切换IP重试...")
time.sleep(3 * (i + 1))
else:
print(f"请求失败，状态码: {response.status_code}")
time.sleep(2)
except Exception as e:
print(f"第{i+1}次请求异常: {e}")
time.sleep(3 * (i + 1))
return None
实际应用中，隧道代理可以将IP封禁率从80%以上降至5%以下，大幅提升采集的稳定性。
四、完整实战：爬取粉丝数据构建用户画像
下面我们组合以上技术，完成一个完整的粉丝数据采集和用户画像分析脚本。
4.1 环境准备
pip install requests pandas
4.2 完整代码实现
import requests
import json
import time
import random
import pandas as pd
from typing import Optional, List, Dict
from datetime import datetime
class BilibiliFansScraper:
def __init__(self, cookie: str = "", use_proxy: bool = False):
"""
初始化爬虫
:param cookie: 登录后的Cookie字符串（含SESSDATA和bili_jct）
:param use_proxy: 是否启用隧道代理
"""
self.session = requests.Session()
self.session.headers.update({
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
"Accept": "application/json"
})
if cookie:
self.session.headers.update({"Cookie": cookie})
self.use_proxy = use_proxy
if use_proxy:
self.proxies = {
"http": "http://隧道代理地址:端口",
"https": "https://隧道代理地址:端口"
}
else:
self.proxies = None
# User-Agent池
self.ua_pool = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/120.0.0.0",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/121.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 Safari/605.1.15",
]
def _request(self, url: str, params: Dict = None, retry: int = 3) -> Optional[Dict]:
"""发送请求，支持重试和隧道代理"""
self.session.headers.update({
"User-Agent": random.choice(self.ua_pool),
"Referer": "https://www.bilibili.com"
})
for i in range(retry):
try:
response = self.session.get(
url,
params=params,
proxies=self.proxies,
timeout=15
)
if response.status_code == 200:
data = response.json()
if data.get('code') == 0:
return data
else:
print(f"API返回错误: {data.get('message', '未知错误')}")
return None
elif response.status_code in [403, 429]:
print(f"第{i+1}次请求被拒绝({response.status_code})，等待后重试...")
time.sleep(5 * (i + 1))
else:
print(f"请求失败，状态码: {response.status_code}")
time.sleep(2)
except Exception as e:
print(f"第{i+1}次请求异常: {e}")
time.sleep(3 * (i + 1))
return None
def get_user_stat(self, uid: int) -> Optional[Dict]:
"""
获取用户关系统计数据（粉丝数、关注数等）
"""
url = "https://api.bilibili.com/x/relation/stat"
return self._request(url, {"vmid": uid})
def get_user_info(self, uid: int) -> Optional[Dict]:
"""
获取用户详细信息
"""
url = "https://api.bilibili.com/x/space/acc/info"
return self._request(url, {"mid": uid})
def get_followers(self, uid: int, page: int = 1, page_size: int = 50) -> Optional[Dict]:
"""
获取粉丝列表（单页）
"""
url = "https://api.bilibili.com/x/relation/followers"
params = {
"vmid": uid,
"pn": page,
"ps": page_size
}
return self._request(url, params)
def get_all_followers(self, uid: int, max_pages: int = 20) -> List[Dict]:
"""
获取所有粉丝（多页）
"""
all_fans = []
page = 1
while page <= max_pages:
data = self.get_followers(uid, page)
if not data:
break
fans = data.get('data', {}).get('list', [])
if not fans:
break
for fan in fans:
all_fans.append({
'uid': fan.get('mid'),
'name': fan.get('uname'),
'sign': fan.get('sign', ''),
'face': fan.get('face', '')
})
total = data.get('data', {}).get('total', 0)
print(f"第{page}页采集完成，已采集 {len(all_fans)}/{total} 人")
# 检查是否还有下一页
if len(all_fans) >= total:
break
page += 1
# 随机延迟，避免触发反爬
time.sleep(random.uniform(2, 5))
return all_fans
def batch_get_user_stats(self, uids: List[int]) -> List[Dict]:
"""
批量获取多个用户的粉丝统计数据
"""
results = []
for uid in uids:
data = self.get_user_stat(uid)
if data:
stat = data.get('data', {})
results.append({
'uid': uid,
'follower_count': stat.get('follower', 0),
'following_count': stat.get('following', 0),
'black_count': stat.get('black', 0)
})
time.sleep(random.uniform(1, 3))
return results
# 使用示例
if __name__ == "__main__":
# 1. 初始化爬虫（启用隧道代理）
COOKIE = "SESSDATA=你的令牌; bili_jct=你的验证参数"
scraper = BilibiliFansScraper(cookie=COOKIE, use_proxy=True)
# 2. 获取目标UP主的粉丝列表
TARGET_UID = 35199034 # 替换为目标UP主的UID
print(f"开始采集UP主 {TARGET_UID} 的粉丝数据...")
fans = scraper.get_all_followers(TARGET_UID, max_pages=10)
print(f"共采集 {len(fans)} 位粉丝")
# 3. 保存粉丝列表
pd.DataFrame(fans).to_csv("fans_list.csv", index=False, encoding="utf-8-sig")
# 4. 批量获取粉丝的统计数据（粉丝的粉丝数，用于分析粉丝影响力）
if fans:
sample_uids = [f['uid'] for f in fans[:100]] # 采样100人进行分析
fan_stats = scraper.batch_get_user_stats(sample_uids)
pd.DataFrame(fan_stats).to_csv("fan_stats.csv", index=False, encoding="utf-8-sig")
print(f"已采集 {len(fan_stats)} 位粉丝的统计数据")
4.3 定时采集与粉丝增长监控
如果需要监控粉丝增长趋势，可以定时执行采集任务：
import schedule
import time
def daily_fan_monitor(uid: int):
"""每日定时采集粉丝数"""
scraper = BilibiliFansScraper(cookie=COOKIE, use_proxy=True)
data = scraper.get_user_stat(uid)
if data:
follower = data.get('data', {}).get('follower', 0)
timestamp = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
with open('follower_history.csv', 'a', encoding='utf-8') as f:
f.write(f"{timestamp},{uid},{follower}\n")
print(f"[{timestamp}] 粉丝数: {follower}")
# 每天上午9点执行
schedule.every().day.at("09:00").do(daily_fan_monitor, TARGET_UID)
while True:
schedule.run_pending()
time.sleep(60)
定时采集的数据可以形成时间序列，进而分析粉丝增长量和增长时间点。
五、从粉丝数据到用户画像
5.1 粉丝画像的构建维度
采集到的粉丝数据可以从以下几个维度构建用户画像：
| 维度 | 数据来源 | 分析价值 |
| 粉丝规模 | 粉丝总数、增长趋势 | 评估UP主影响力 |
| 粉丝活跃度 | 粉丝的粉丝数、投稿数 | 判断粉丝质量 |
| 粉丝构成 | 粉丝等级分布、注册时间分布 | 了解受众结构 |
| 兴趣偏好 | 粉丝关注的UP主列表 | 分析内容偏好 |
| 地域分布 | 粉丝IP归属地（需高级接口） | 了解受众地域特征 |
5.2 典型应用场景
场景一：UP主影响力评估
通过分析粉丝总数、粉丝增长速度、粉丝活跃度等指标，综合评估UP主的真实影响力。一个UP主的粉丝数可能是百万级，但如果粉丝大多为“僵尸粉”或低活跃用户，其商业价值会大打折扣。
场景二：内容定位优化
通过分析粉丝同时关注的其他UP主，可以了解粉丝群体的内容偏好。如果一个知识区UP主的粉丝大量关注游戏区UP主，说明可能存在跨圈层的内容机会。
场景三：竞品分析
对比同一分区多个UP主的粉丝数据，可以发现头部创作者的共同特征——更新频率、内容风格、互动模式等，为内容策略提供数据支撑。
5.3 数据可视化
采集到的数据可以通过可视化工具呈现：
- 粉丝增长曲线：展示UP主粉丝数量的时间变化趋势
- 粉丝等级分布图：展示粉丝群体的等级构成
- 粉丝网络图：展示粉丝与UP主之间的关注关系网络
六、常见问题与避坑指南
6.1 Cookie过期怎么办？
某站的Cookie有效期通常为数天到数周。当遇到大量401错误或数据返回异常时，说明Cookie已过期，需要重新登录获取新的Cookie。
建议：编写定时任务，每周自动重新登录并更新Cookie。
6.2 遇到验证码怎么处理？
- 降低采集频率：出现验证码时自动降低采集速率，暂停数小时再继续
- 切换账号：准备多个小号轮换使用
- 半自动方案：检测到验证码时暂停脚本，人工完成验证后继续
6.3 粉丝列表采集不全怎么办？
某站的粉丝列表接口可能存在页数限制。解决方案：
- 分时间段采集：如按粉丝关注时间分段
- 使用多个入口采集：结合关注列表和粉丝列表交叉验证
6.4 短时间内大量请求被封怎么办？
- 使用隧道代理自动切换IP
- 设置合理的请求延迟，建议不低于3秒
- 采用“礼貌爬取”策略，在获取数据的同时尽量减少对目标服务器的压力
- 分批采集，中间加入人工暂停
6.5 数据准确性问题
- API返回的粉丝数可能存在缓存延迟（通常为数分钟到数小时）
- 建议在固定时间点（如每天上午9点）采集，保证数据可比性
七、总结
本文从某站UP主粉丝数据的价值出发，系统介绍了爬取粉丝数据以构建用户画像的完整方案。核心要点可以概括为：
| 挑战 | 解决方案 |
| 获取粉丝总数 | x/relation/stat API接口 |
| 获取粉丝明细列表 | x/relation/followers API接口（分页采集） |
| User-Agent检测 | UA池轮换，模拟不同浏览器 |
| 请求频率限制 | 随机延迟（2-5秒），避免固定间隔 |
| IP封禁 | 站大爷隧道代理，每次请求自动切换IP |
| 用户画像构建 | 粉丝规模、活跃度、构成、兴趣偏好多维度分析 |
技术选型速览：推荐“API接口调用 + Cookie认证 + UA池轮换 + 站大爷隧道代理”的组合方案，兼顾效率与稳定性。
某站的粉丝数据是一座尚未被充分开采的金矿。通过合理的爬虫策略和数据建模，我们可以将这座金矿转化为结构化的用户画像数据，为内容创作、品牌投放、平台研究等应用提供坚实的数据基础。
最后需要提醒的是：数据采集行为应当遵循行业规范，控制请求频率以避免对目标服务器造成过载。请遵守目标网站的robots.txt协议及相关法律法规，仅将爬虫技术用于学习和研究目的，勿对目标网站造成过大压力。希望本文能帮助你在平台生态研究的道路上迈出坚实的一步。
