樱桃小公举这几年我给不少教育类账号做过舆情和内容分析，有一个需求反反复复出现：把某个博主的公开微博全部抓下来，给每一条文本打个情绪标签，最后汇总出一个词云，看看这个人到底在聊什么、粉丝情绪是正向还是负向。这个需求听起来很常规，但真正动手做的时候，你会发现爬虫只是最轻松的一环，后面的文本清洗、情感模型选择、中文词云渲染，每一个步骤都是坑。今天我把这套完整的流程拆开讲一遍，从接口分析、数据采集到SnowNLP情感打分，再到jieba分词和wordcloud出图，所有代码和配置都会给到，踩过的坑也一并列出来。
这个项目适合刚学完Python基础、想找一个综合练习项目的读者，也适合已经在做爬虫但没接触过文本分析的从业者。它麻雀虽小但五脏俱全，覆盖了网络请求、数据解析、文本处理、机器学习模型调用和可视化展示，是一条非常完整的Python实战链路。
1. 这个项目到底值不值得做：目标拆解与预期收获
1.1 为什么选微博而不是其他平台
微博是目前中文互联网里最适合练手情感分析的公开数据源之一。它的文本长度适中，单条微博通常在几十到几百字之间，刚好是情感分析模型处理起来最舒服的长度范围；其次微博带有天然的社交属性，转发、评论、点赞这些元数据可以辅助判断一条内容的情绪强度；最重要的是，微博的手机版页面保留了非常干净的JSON数据接口，不需要像某些平台那样解析复杂的动态渲染页面，对爬虫学习者极度友好。
有人可能会问，为什么不去爬某书、某音？这些平台的反爬机制更强，接口返回的数据经过加密，很多还需要逆向破解，对新手来说学习曲线太陡。微博手机版接口中的containerid和page参数非常直白，返回的是标准JSON，你用requests就能直接解析出文本内容，这个渐进式的学习路径对建立信心很重要。
1.2 技术栈选型的底层逻辑
这个项目的技术栈由四部分组成：requests做页面请求、pandas做数据存储与管理、snownlp做中文情感分析、jieba+wordcloud做分词和词云渲染。
先说requests和Scrapy的选择。Scrapy是更专业的爬虫框架，自带并发调度和中间件机制，适合大规模分布式采集。但单就这个项目来说，微博单用户的历史微博最多几千条，用requests写一个带循环的脚本就能完成，没必要引入框架的复杂度。而且requests的代码逻辑更透明，每一步做了什么都在你眼前，排查问题也容易。
情感分析这块，很多人一上来就想上大模型，但这里有个成本问题：一条微博调用一次大模型接口，抓几千条就是几千次调用，费用先不说，光是API频率限制就够你排队等半天。我的建议是先拿SnowNLP做基线模型，跑通整个流程之后，再决定要不要对特定类别的文本做二次判断。SnowNLP的原理是基于朴素贝叶斯训练的 sentiment 模型，输入一段文本，输出一个0到1之间的情感倾向值，大于0.5偏向正面，小于0.5偏向负面。它虽然不如大模型聪明，但胜在免费、离线、速度快。
词云部分没有太多选择余地，Python生态里做中文词云基本就是wordcloud库，配合jieba分词。但这里藏着这个项目最大的坑：中文显示。后面我会详细说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备是第一个坑：依赖版本与中文支持
2.1 安装清单与Python版本建议
先给一份完整的安装清单，我实测过Python 3.9到3.11都没问题，更低的版本建议先升级。
bash复制pip install requests pandas jieba snownlp wordcloud matplotlib pillow
这里重点说三个库的版本问题。第一个是wordcloud，1.8.1以后的版本在macOS和Linux上有预编译的wheel包，安装基本不会报错，但如果你用的是Python 3.12，早期版本可能找不到对应的wheel，会触发源码编译，然后大概率报gcc相关的错误。这时候不要硬刚编译环境,直接执行pip install --upgrade wordcloud，让它拉最新版本即可。
第二个是pillow，它是wordcloud处理遮罩图片的底层依赖，如果漏装，wordcloud在导入时报错会非常隐晦，报的却是ImportError: cannot import name 'Image' from 'PIL'这一类，容易把人带偏。
第三个是snownlp，它有个比较老的依赖问题，会在安装时一并装上scikit-learn等一堆库，耗时较长。装的时候耐心等即可，不要中途Ctrl+C，容易留下不完整的安装记录，后面import时报错又得排查半天。
2.2 中文字体是词云的第一道坎
我见过太多人跑通了所有代码，却在最后一步生成词云时得到一张全是方块的图。原因很简单：wordcloud默认字体是不支持中文的，你需要手动指定一个中文字体文件路径。
三个操作系统的常见字体路径我列在下面：
| 系统 | 常见中文字体路径 |
|---|---|
| Windows | C:/Windows/Fonts/simhei.ttf 或 msyh.ttc |
| macOS | /System/Library/Fonts/PingFang.ttc 或 /System/Library/Fonts/STHeiti Light.ttc |
| Linux | /usr/share/fonts/truetype/wqy/wqy-microhei.ttc（需安装文泉驿字体） |
如果你是Windows用户，建议优先用simhei.ttf（黑体），它在wordcloud里渲染出来的效果最均匀。macOS用户用PingFang.ttc效果好，但在部分wordcloud版本里对.ttc格式支持不稳定，如果真的遇到问题，下载一个思源黑体的.ttf文件放到项目目录下，就没有兼容性烦恼了。这个细节比任何代码都能决定你的词云最终长啥样，务必在动手前确认。
3. 数据采集：摸清微博的接口规律再动手
3.1 优先选择手机版微博的JSON接口
微博网页版的HTML结构变了好几次，而且里面大量内容靠JavaScript动态渲染，requests直接拿到的是空壳页面。但手机版微博m.weibo.cn保留了老式的API接口风格，请求一个URL就能直接返回JSON数据，解析起来极其舒服。
核心接口是这个：
bash复制https://m.weibo.cn/api/container/getIndex?type=uid&value={用户id}&containerid=107603{用户id}&page={页码}
这个接口的参数逻辑是固定的：type=uid表示按用户ID查询，value是用户的数字ID，containerid固定以107603开头后接用户ID，page是分页页码。每页大约返回10条微博。
那用户ID去哪找？打开微博网页版，进入目标用户的主页，看地址栏的URL：https://weibo.com/u/1234567890，那一串数字就是。不需要额外抓取接口，直接在浏览器看最方便。
3.2 Cookie获取与请求头伪装细节
手机版微博的接口虽然干净，但不是完全开放的。首次请求时大概率会返回418状态码，这是微博的反爬策略之一，意味着它发现了你是异常请求。解决方法是带上完整的请求头，尤其是User-Agent和Referer。我实测可用的请求头配置如下：
python复制import requests
headers = {
'User-Agent': 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1',
'Referer': 'https://m.weibo.cn/',
'X-Requested-With': 'XMLHttpRequest',
}
如果你发现加上请求头还是被拒，那大概率需要登录后的Cookie。获取方式不复杂：用浏览器无痕模式打开https://m.weibo.cn，手动登录一次，打开开发者工具（F12），在Network面板里找到任意一个请求，复制请求头里的Cookie字段值，粘贴到代码里即可。注意微博的Cookie会不定期过期，短则几小时长则几天，一旦发现请求结果里没有cards字段，先检查Cookie是否失效。
3.3 分页抓取、频率控制与增量保存
有了接口和请求头，抓取逻辑就很简单了。我这里给一个完整的抓取函数，包含延时和错误重试：
python复制import requests
import time
import pandas as pd
headers = {
'User-Agent': 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1',
'Referer': 'https://m.weibo.cn/',
'Cookie': '你的_cookie_替换这里',
}
def fetch_weibo_data(user_id, max_pages=100):
all_texts = []
for page in range(1, max_pages + 1):
url = f'https://m.weibo.cn/api/container/getIndex?type=uid&value={user_id}&containerid=107603{user_id}&page={page}'
try:
resp = requests.get(url, headers=headers, timeout=10)
resp.raise_for_status()
data = resp.json()
cards = data.get('data', {}).get('cards', [])
if not cards:
break
for card in cards:
mblog = card.get('mblog', {})
text = mblog.get('text', '')
if text:
all_texts.append({
'id': mblog.get('id'),
'text_raw': text,
'created_at': mblog.get('created_at'),
'reposts_count': mblog.get('reposts_count'),
'comments_count': mblog.get('comments_count'),
'attitudes_count': mblog.get('attitudes_count'),
'page': page,
})
print(f'第{page}页完成，累计{len(all_texts)}条')
except Exception as e:
print(f'第{page}页出错: {e}')
time.sleep(3) # 每页延时3秒，别贪快
return pd.DataFrame(all_texts)
df = fetch_weibo_data(你的用户ID, max_pages=100)
df.to_csv('weibo_data.csv', index=False, encoding='utf-8-sig')
print(df.head())
为什么每页要延时3秒？以我一贯的实测经验，连续快速请求大概到第5页左右就会触发微博的临时风控，表现为IP被限流，所有请求都返回418，短则几十秒长则几小时才能恢复。延时3秒看起来慢，但100页也就多花5分钟，换来的是整个抓取过程的稳定，这笔账非常划算。
另外一个容易忽略的点：encoding='utf-8-sig'。如果直接用utf-8保存CSV，用Excel打开时会乱码，因为Excel默认按ANSI编码读取。utf-8-sig会在文件头部加入BOM标记，Excel就能正确识别。这是从CSV导出到其他工具这一环最容易踩的隐藏坑。
这里我设定max_pages=100，实际执行时如果某页返回的cards为空，循环就会自动终止。所以我建议抓取时从第1页开始逐页观察，到第60页左右如果还能抓到数据，就说明用户发博量很大，要留意自己有没有被限流。
3.4 微博HTML文本的预处理：标签剥离
抓下来的text字段看着是文本，实际上是HTML片段。微博在接口里返回的文本会夹杂<a>标签、<span>标签和各类转义符。比如一条典型的微博文本长这样：
html复制今天在办公室跟学生聊了聊就业问题<a href="https://weibo.cn/sinaurl?..." rel="noopener noreferrer">#就业推荐#</a>，大家还是要提前规划。 <br />来自 <a href="...">张雪峰老师</a>
如果直接拿这段文本去做情感分析和词云，结果会惨不忍睹：词频统计里全是href、rel这种碎片。所以采集之后必须马上做一轮HTML标签剥离，我用的是BeautifulSoup，你也可以用正则，但BeautifulSoup处理标签粘连的情况更稳。
python复制from bs4 import BeautifulSoup
def clean_html(text):
if not text:
return ''
soup = BeautifulSoup(text, 'html.parser')
# 提取纯文本，同时把<br/>等标签替换为空格，避免单词粘连
clean_text = soup.get_text(separator=' ')
return clean_text.strip()
这一步虽然简单，但极大影响后续所有环节的质量。爬虫搞定之后，CSV里存的应该是干净文本，而不是带着一堆监控代码的HTML。
4. 文本清洗：真正花时间的环节
4.1 清洗规则设计：URL、@提及、话题标签与emoji
很多人把清洗理解成"去掉标签"，实际上清洗远不止这一步。做完HTML剥离之后，文本里还残留以下几类噪声：
- URL链接：
https://t.cn/xxxxxx - @提及：
@张雪峰老师 - 话题标签：
#就业推荐#，这个有时需要保留内容但去掉#号 - emoji和特殊符号：😀、🔥这类
- 转发标识：
转发微博、//开头的转发链 - 空格和多余换行
我整理了一套清洗函数，按顺序执行：
python复制import re
def clean_text(text):
if not text:
return ''
# 1. 去除URL
text = re.sub(r'http[s]?://\S+', '', text)
# 2. 去除@用户
text = re.sub(r'@\S+', '', text)
# 3. 话题标签#xxx#替换为xxx，保留话题内容
text = re.sub(r'#([^#]+)#', r'\1', text)
# 4. 去除emoji（匹配大部分unicode emoji）
text = re.sub(r'[\U0001F300-\U0001FAFF]', '', text)
# 5. 去除多余空白
text = re.sub(r'\s+', ' ', text).strip()
return text
这个顺序是有讲究的。URL和@用户要直接剔除，因为对情感判断毫无贡献；话题标签的内容反而要保留，#就业推荐#去掉#之后变成就业推荐，作为分词结果是很有价值的特征。emoji虽然理论上承载情感信息，但SnowNLP对emoji无法理解，强行保留只会让词云里出现一堆无意义的符号，所以直接剔除。如果你以后想升级到大模型情感分析，那时候再单独解析emoji也不迟。
4.2 jieba分词与停用词：词云质量的灵魂
词云的基础是高频词统计，中文和英文最大的区别在于词和词之间没有空格，必须先分词。这里用的jieba是目前最流行的中文分词库，使用方式如下：
python复制import jieba
def segment_text(text, stopwords):
words = jieba.lcut(text)
# 过滤单字词、空格和停用词
return [w for w in words if w.strip() and w not in stopwords and len(w) > 1]
但问题来了，jieba的默认词表对特定领域的人名和专业词汇识别并不好。比如"张雪峰"可能会被切成"张"和"雪峰"，"研究生"这种词没问题，但"择校""调剂""考研党"等如果不在词表里，会被切得七零八落。解决办法是加载自定义词典：
python复制jieba.add_word('张雪峰')
jieba.add_word('考研')
jieba.add_word('调剂')
jieba.add_word('就业')
如果你的爬取对象有大量特定术语，可以维护一个userdict.txt，每一行一个词，然后通过jieba.load_userdict('userdict.txt')加载。这是分词环节里性价比最高的一步。
停用词表同样关键。中文分词后最常出现的往往是"我们""你们""这个""就是""真的""现在"这类无实际意义的词，如果不过滤，词云会被它们霸屏。网上有很多现成的中文停用词表，比如哈工大停用词表，基本够用。我在项目里还会根据具体数据动态添加一些停用词，比如微博语料里高频出现的"微博""转发""网页链接"等。
5. 情感分析：模型选择与结果校准
5.1 用SnowNLP跑基线：最省力的情感打分方案
情感分析是项目里看起来最简单、实际最容易翻车的环节。SnowNLP的调用方式很简单：
python复制from snownlp import SnowNLP
def get_sentiment_score(text):
if not text:
return 0.5
s = SnowNLP(text)
return s.sentiments
sentiments输出范围是0到1：越接近0越负面，越接近1越正面，0.5左右是中性。跑完全量数据后，你可以按0.5为分界线做一个初分类。
但SnowNLP默认是基于购物评论文本训练的模型，对微博这种短文本 + 网络语言的场景，准确率通常只在70%到80%。这意味着每10条微博就有2到3条被误判。如果只是做粗粒度的整体情绪分布，这个误差还能接受；但如果你把情感分析结果当成"某一句话是正面还是负面"的确定性结论，那就是自欺欺人。
5.2 误判的典型场景：反讽、否定结构、贺喜类短句
我在实测中总结了三类最典型的误判场景：
- 反讽和反话：比如"真的谢谢你了，让我多等了两小时"，SnowNLP会判定为正面（因为"谢谢"），但实际情绪是抱怨。
- 否定结构："不开心"会被正确判为负面，但"不是不开心"这种双重否定，模型经常处理成负面，实际是偏正面。
- 带有明确正面词的短句："热搜第一，恭喜！"这类祝福/恭贺文本，经常被误判为中性，因为模型对短文本的上下文理解不足。
针对这些情况，一个实用做法是增加规则校准层。比如在模型输出之后，检查文本中是否包含特定词：
python复制negative_emojis = ['呵呵', '醉了', '无语', '服了', '真行', '牛哇', '太棒了(反讽)', '毛坯', '真香']
如果文本包含这些词，就在模型得分基础上做一个偏移。比如命中反讽词列表就让得分降低0.3，命中否定结构就反转。这种"模型 + 规则"的组合方式，比单纯调模型参数更可控，也更适合没有标注数据的情况。
5.3 情感倾向统计与分段解读
拿到全部微博的得分后，不要急着下结论。建议做两个统计维度：
维度一：整体分布
python复制import pandas as pd
df['sentiment'] = df['text_clean'].apply(get_sentiment_score)
df['sentiment_type'] = df['sentiment'].apply(
lambda x: 'positive' if x > 0.6 else ('negative' if x < 0.4 else 'neutral')
)
print(df['sentiment_type'].value_counts(normalize=True))
分布饼图能让你快速判断这个博主的整体内容基调。
维度二：时间维度（如果数据跨度够长）
把微博按时间分桶（按月/季度），做情感均值曲线。这条曲线可以反推博主在哪个时间段因为什么事件产生了情绪波动。这一步能把情感分析从"玩具应用"提升到"有业务价值"的层面。这里不做展开，但思路很重要。
6. 词云可视化：让数据“看得见”
6.1 中文字体的指定方式
词云部分的核心代码不长，但字体参数就是你前面准备的那个中文字体路径，不指定就是一个方块堆。
python复制import matplotlib.pyplot as plt
from wordcloud import WordCloud
from collections import Counter
# 统计词频
word_counts = Counter(all_words)
top_words = dict(word_counts.most_common(100))
# 生成词云，font_path 必须指向一个中文字体
wc = WordCloud(
font_path='/System/Library/Fonts/PingFang.ttc', # 换成你的系统字体路径
width=1200,
height=800,
background_color='white',
max_words=200,
colormap='coolwarm',
random_state=42,
)
wc.generate_from_frequencies(top_words)
plt.figure(figsize=(12, 8))
plt.imshow(wc, interpolation='bilinear')
plt.axis('off')
plt.savefig('wordcloud.png', dpi=300, bbox_inches='tight')
plt.show()
这段代码里几个参数值得解释。colormap='coolwarm'是让词频最高的词偏红、低频偏蓝，视觉上区分度明显。random_state=42是固定随机种子，保证每次运行出图的布局一致，方便排错和复现。max_words=200控制词的数量，太多会显得画面拥挤。
6.2 用遮罩图片做形状词云
默认的矩形词云有点单调，如果你想让词云呈现特定形状，可以用pillow处理一张黑白的遮罩图。做法是先准备一张轮廓清晰的PNG图片（黑色背景、白色形状），代码改造如下：
python复制from PIL import Image
import numpy as np
mask = np.array(Image.open('mask.png'))
wc = WordCloud(
font_path='/System/Library/Fonts/PingFang.ttc',
width=1200,
height=800,
background_color='white',
max_words=200,
mask=mask,
contour_width=1,
contour_color='steelblue',
)
稍微提醒一下，使用彩色或过于复杂的图片做遮罩有可能导致渲染失败或形状不完整，最好先用图片处理软件把主体变成纯色。
6.3 词云结果如何反哺情感分析
这一步是我特别想强调的：词云不只是用来"好看".它能反过来验证情感分析的准确性。比如说，你跑完情感分析发现整体偏正面，词云中却频繁出现"崩溃""焦虑""压力"这类词，说明情感模型很可能大量误判了负面内容为中性或正面。这时候就要回去检查情感分析阈值和规则校准是否生效了。
词云也适合做分组对比。把情感得分为正的和负的微博分别做两个词云，对比它们的核心主题差异。比如教育类博主的正向微博里高频词是"上岸""录取""复习进度"，负向微博里高频词是"焦虑""错过""二战"，这种对比能帮你在几分钟内抓住内容的情绪标签和主题脉络，比逐条看文本高效太多。
7. 复盘与优化：这套代码还能怎么升级
7.1 采集层：从requests到更健壮的方案
用requests手动写循环虽然清晰，但生产环境里会暴露几个问题：断点续传、异常恢复、增量更新。万一抓到第50页时网络断了，没有断点续传就得从头再来。升级方案有两个：一是把已抓取的微博ID存到set里，每次抓取前先判断ID是否重复，实现天然的去重和断点续传；二是迁移到Scrapy框架，利用它的AutoThrottle自动限速和RetryMiddleware重试机制，采集稳定性会明显提升。但如果只是单次几千条数据，requests加一个去重判断就完全够用了，没必要为了"专业"上框架。
7.2 情感分析层：从SnowNLP到预训练模型
如果未来数据量变大、对准确率要求更高，可以用Hugging Face上的中文情感分析预训练模型（比如uer/roberta-base-finetuned-jd-binary-chinese），或者直接用大模型的API做批量分析。但要注意，大模型API的情感分析结果非常依赖于你的Prompt设计，需要明确要求模型输出JSON格式的positive/negative/neutral标签，否则输出文本形态不统一又得二次清洗。这个升级路径我建议等项目稳定跑通之后再考虑，先有个能用的基线比什么都重要。
7.3 一个容易被忽略的细节：结果版本管理
做数据分析和可视化项目时，我习惯给每一轮产出打上版本标签，比如v1_snownlp.csv、v2_roberta.csv。因为你会发现，当你调整情感分析阈值或者停用词表之后，生成的词云完全不一样。如果没有版本管理，过两天回头看，你根本分不清哪张图是用哪套参数跑出来的。这个习惯看似简单，但在个人项目中特别能避免重复劳动。
回到开头那个需求，我用这套流程完成了无数次类似的任务。整个项目最花时间的不是爬虫代码，而是理解数据的过程：每条微博都有它的语境，你想让模型理解它，就必须先清洗好、切好词、选对模型，再去解读结果。现在这几步跑通了，完整的脚本其实不到200行。如果你们也想拿Python练手一个综合项目，这个选题值得一试，它真的能把爬虫、文本处理和可视化三个技能串成一条线，学到的经验之后换任何领域都能复用。