Python爬虫实战：抓取微博公开数据做情感分析与词云可视化

朋友让我帮忙分析张雪峰微博下面的公众反馈，我的方案很简单：先用Python爬虫把他公开发过的微博抓下来，再用AI情感分析给每条内容打分，最后用词云可视化把高频话题摆到一张图里。这里的张雪峰不是陌生人，就是那位长期聊高考志愿、考研规划和就业方向的教育博主，微博内容自带讨论度和对立情绪，拿来做文本分析样本再合适不过。

开始之前朋友问了一句：这活不是人工也能干吗？我说能干，但你翻不到两百条就想放弃，而且靠肉眼判断情绪比例很容易出现“看什么都像骂他”的主观偏差。今天这篇内容，我不打算只贴代码，还会把每个环节为什么这样处理讲清楚，包括接口选型、清洗逻辑、情感模型的选择依据和踩坑过程，希望能帮到正在学爬虫又不知道能做什么完整项目的朋友。

1. 为什么拿张雪峰微博当训练场：三类数据各有各的用途

这类项目最忌讳的事，就是吭哧吭哧把几千条微博抓下来，最后只生成一张谁都能拍脑袋画出来的图。既然花了时间写爬虫，就得让采集回来的每个字段都有出口。

1.1 微博正文是分析主料，但不是唯一主料

很多人一想到爬微博，脑子里只有“正文”。实际上正文只能回答“博主说了什么”，回答不了“网友为什么买账”。所以我采集时会连带保存发布时间、点赞数、评论数、转发数和微博ID，后几个字段在做内容分析时能帮上大忙。

我拿张雪峰的内容做实验时，发现一个特别明显的现象：单纯看正文字数，很多微博写得轻描淡写，但转发数忽然飙到几千。这时候如果只有正文，你根本不知道这条微博是引爆了什么话题。把互动数据带上以后，你可以很自然地把“高互动微博”单独筛出来，看看它和普通微博在情绪倾向上有没有差异。

1.2 技术选型没有新花样，组合起来才是练手重点

这个项目本质上就是把四样东西串成一条流水线：requests负责抓取，pandas负责清洗和聚合，SnowNLP负责情感打分，jieba加wordcloud负责词云输出。每一块单独拎出来都不算难，难的是它们在真实网页环境里会互相牵扯。

例如requests抓下来的内容带着一堆HTML标签和表情符号，这部分脏数据如果不处理，pandas清洗时会正常，但到了SnowNLP阶段可能直接拉低情感分析的准确率，最后进词云时又会冒出一堆“展开全文”和“网页链接”。所以每一步怎么处理上一步留下的坑，就是这项目真正的学习价值。

准备环境时我多说一句：如果你电脑上还没有Python，安装时记得勾选“Add python.exe to PATH”，否则命令行里敲python会提示找不到命令。装完以后执行pip install requests pandas snownlp jieba wordcloud matplotlib beautifulsoup4，基本就齐了。

2. 微博公开微博抓取：我为什么绕开网页版而走移动端接口

写爬虫的第一步是搞清楚数据从哪来。很多新手上来就对微博网页版发起请求，然后用BeautifulSoup解析HTML，结果发现返回的内容要么是登录框，要么是验证码。我在这个项目里没走那条路，直接用了微博移动端的JSON接口。

2.1 网页版反爬强度高，移动端接口更“敞亮”

这里先说明一句：我抓的是账号公开发布的微博内容，而且请求频率压得很低，只用于个人学习演示。如果你想把数据拿去做商用产品，必须先评估授权问题，这是底线。

微博网页版之所以难爬，不是因为它用了多高级的加密，而是因为HTML结构里混入了大量动态模块。你以为你看到的是正文，实际渲染出来的DOM节点可能是前端二次请求后拼接的。相比之下，移动端m.weibo.cn有一套接口，直接返回结构化JSON，省去了大量解析工作。

2.2 第一步是拿到目标用户的containerid

先用手机浏览器打开张雪峰的微博主页，地址栏会显示一串纯数字UID，例如m.weibo.cn/u/后面跟的那串数字。每个微博用户都有自己独特的containerid，它决定了接口返回的是这个账号的哪一类内容。

我们可以先访问“type=uid”接口，让服务器根据UID返回第一版信息，其中会包含cardlistInfo.containerid字段。这个字段格式通常像“107603”加UID，拿到以后，后续翻页请求都要带上它。

python复制import requests
import time
import random
import re
from bs4 import BeautifulSoup
import pandas as pd

UID = "替换成你在m.weibo.cn/u/后面看到的数字"

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Mobile/15E148 Safari/604.1",
    "Referer": "https://m.weibo.cn/",
    "X-Requested-With": "XMLHttpRequest"
})

BASE_URL = "https://m.weibo.cn/api/container/getIndex"

def get_first_container_and_cards(uid):
    params = {"type": "uid", "value": uid}
    resp = session.get(BASE_URL, params=params, timeout=10)
    if resp.status_code != 200:
        raise RuntimeError(f"接口异常，状态码: {resp.status_code}")
    data = resp.json()
    if data.get("ok") != 1:
        raise RuntimeError("接口返回异常，可能触发了风控，建议稍后再试")
    cards = data.get("data", {}).get("cards", [])
    containerid = data.get("data", {}).get("cardlistInfo", {}).get("containerid")
    return containerid, cards

我特别说下这个User-Agent，直接用iPhone Safari的标识成功率最高。如果U-A太像纯requests的默认值，接口很容易拒绝；反而是带点浏览器特征的请求，配合Referer和X-Requested-With头，经常能顺利通过。

2.3 翻页策略：把“没有新数据”当成终止条件

微博移动端接口的翻页逻辑很简单，往参数里加page就行。问题是每页最多返回多少条不固定，在移动端一屏能展示的卡片数量有限，通常一页十几条到二十几条。如果目标账号有几万条微博，一口气全抓不现实，所以我一般只抓最近一两百条，足够分析近期公众反馈趋势。

翻页时最忌讳用固定页数硬跑。如果账号只有三十条微博，你硬抓五十页，后半程全是空响应，浪费流量还可能触发风控。正确做法是每次请求后判断cards列表是否为空，为空就立刻停止。

python复制def fetch_recent_weibo(uid, max_pages=15):
    containerid, _ = get_first_container_and_cards(uid)
    rows = []
    for page in range(1, max_pages + 1):
        params = {
            "type": "uid",
            "value": uid,
            "containerid": containerid,
            "page": page
        }
        resp = session.get(BASE_URL, params=params, timeout=10)
        if resp.status_code != 200:
            print(f"第{page}页状态码异常，暂停")
            break

        data = resp.json()
        cards = data.get("data", {}).get("cards", []) if data.get("ok") == 1 else []
        if not cards:
            print(f"第{page}页没有更多卡片，停止翻页")
            break

        for card in cards:
            if card.get("card_type") not in (9, 11):
                continue
            mblog = card.get("mblog")
            if not mblog:
                continue
            raw_html = mblog.get("text", "")
            text = BeautifulSoup(raw_html, "html.parser").get_text()
            rows.append({
                "id": mblog.get("id"),
                "created_at": mblog.get("created_at"),
                "text": text,
                "attitudes": mblog.get("attitudes_count"),
                "comments": mblog.get("comments_count"),
                "reposts": mblog.get("reposts_count"),
                "source": mblog.get("source", "")
            })

        print(f"第{page}页完成，累计{len(rows)}条")
        time.sleep(random.uniform(1, 2.5))

    return rows

这里sleep的那几秒很重要。微博接口不是完全禁爬，但它的风控对请求频率极其敏感，你连续快速翻页，十几页后就会收到一坨登录提示。每页随机停1到2.5秒，体感上是“人肉翻手机”的节奏，实际抓下来也稳定很多。

3. 抓回来只是开始：正文清洗与存储方式直接影响后续结果

用BeautifulSoup把text字段里的HTML标签剥掉以后，你以为得到的是干净句子？不是。真正的微博正文里还藏着话题符、@用户名、短链、emoji、表情符和一堆零宽字符，这些不处理干净，后面所有分析都会跑偏。

3.1 我整理的清洗顺序：先剥标签，再删噪声，最后收拾表情

清洗顺序有讲究。先把HTML转成纯文本，再处理@和话题，最后处理表情符号，不能让表情符号带着它的Unicode尾巴进入分词。下面是这个项目里最终用的清洗函数，思路也能复用到其他平台。

python复制def clean_weibo_text(raw):
    if not isinstance(raw, str):
        return ""
    # 去HTML标签
    text = re.sub(r"<[^>]+>", "", raw)
    # 去掉@用户名，保留话题中间的文字
    text = re.sub(r"@[\w\u4e00-\u9fa5_\-]+", "", text)
    # 去掉完整URL
    text = re.sub(r"https?://\S+", "", text)
    text = text.replace("网页链接", "")
    # 去掉收藏、转发、评论这种自动拼接的尾巴
    text = text.replace("转发微博", "").replace("收起全文", "").replace("展开全文", "")
    # 去掉常见emoji区间和变体选择符
    emoji_pattern = re.compile("[^\U00000000-\U0000FFFF]")
    text = emoji_pattern.sub("", text)
    # 压缩空白
    text = re.sub(r"\s+", " ", text).strip()
    return text

这里我用了范围比较粗暴的“非BMP字符删除法”。微博里绝大多数emoji都落在BMP区域之外，用这招能把火星文和奇怪符号一次性清掉。代价是会误伤部分生僻字，但对于统计型分析完全可接受。

3.2 哪些字段值得留下来

很多新手把数据存成一个大字符串，等到分析时再到处找字段，这是给自己埋雷。我建议用pandas先整理成结构化表格，字段宁多勿少，存CSV时一次到位。

我最终保留的字段如下：

存储格式我推荐CSV，原因是中间过程需要肉眼检查，CSV用Excel打开就能看到清洗后的文本，比闷在SQLite里可视化效率高。不过Windows下写CSV有个编码坑，必须用utf-8-sig，否则Excel打开会是乱码。

python复制df = pd.DataFrame(rows).drop_duplicates(subset=["id"])
df["text_clean"] = df["text"].map(clean_weibo_text)
df.to_csv("weibo_data.csv", index=False, encoding="utf-8-sig")
print(f"一共保存{len(df)}条微博")

3.3 注意“Process finished with exit code 0”假成功

我第一次跑完整脚本，在PyCharm里看到控制台只显示Process finished with exit code 0，什么都没打印。新手容易认为这是程序没执行，实际上这代表程序正常结束，只是代码路径里没有触发任何输出。

顺着排查发现，问题出在第一页接口返回的响应不是JSON而是HTML登录页，data.get("ok")变成None，代码在if判断里把cards设为空列表，循环根本没执行，于是程序“正常”退出。处理方式就是所有解析步骤前先做状态码和ok字段检查，只要异常就显式打印并中断，不要默默吞掉。

4. 情感分析选型：为什么我先用SnowNLP而不是直接召唤大模型

爬虫只是搬运工，真正“分析”的部分从情感打分开始。市面上的方案很多，我看到有人一上来就调大模型API，也有人用在线舆情分析工具。都不是不行，只是对于这个项目有点大材小用。

4.1 三种常见方案背后的取舍

我先后对比了三类方案。第一种是调通用大模型API，效果确实好，能理解上下文和反讽，但每段文本都要单独请求，几百条还能忍，几千条就是时间和金钱双重消耗，而且还要处理API密钥和隐私问题。第二种是在线舆情平台，开箱即用，但对个人项目来说免费额度有限，数据上传到第三方平台也总有顾虑。第三种就是本地运行的SnowNLP，离线、免费、秒级出结果。

SnowNLP默认是在电商评论语料上训练出来的，对“好吃”“垃圾”这种极性明确的词把握得好。张雪峰微博的内容偏长文本的议论文风格，语气偶尔带点自嘲和反问，SnowNLP理解不了太复杂的修辞。不过我的目标不是精确判断每条微博是支持还是反对，而是从整体数据里看出情绪分布倾向，SnowNLP完全够用。

4.2 打分策略：分高不代表认同，分低不代表骂人

情感分数在0到1之间，越接近1越积极，越接近0越消极。实际操作中我给了一个区间判断：大于0.6算正向，小于0.4算负向，中间当中性。这个阈值不是死的，你可以根据语料分布调整。

SnowNLP有一个让人哭笑不得的点：它会把“笑死”判成比较低的分数，会把“无敌”判成高分，但微博语境里“笑死”往往是调侃，不是绝望。所以我建议不要在单条微博上过度解读，要相信统计的力量——几千条微博的整体比例不会因为个别误判而失真。

python复制from snownlp import SnowNLP

def get_sentiment(text):
    if len(text) < 2:
        return 0.5
    try:
        return SnowNLP(text).sentiments
    except Exception:
        return 0.5

df["sentiment"] = df["text_clean"].map(get_sentiment)
df["sentiment_label"] = pd.cut(
    df["sentiment"],
    bins=[-0.001, 0.4, 0.6, 1.001],
    labels=["负向", "中性", "正向"]
)

跑完之后我喜欢用一句print统计比例：print(df["sentiment_label"].value_counts(normalize=True))。第一次跑出结果时我专门算了算，发现正向比例其实不低，这和大家在评论区吵翻天的印象有点反差，原因是他微博里有很多纯粹的报考知识分享，那些内容不吵架、不站队，自然偏正向。这就是整体分析的价值，它能纠正你凭评论区局部信息得出的偏见。

4.3 情绪曲线比平均分更有信息量

只看整体比例还不过瘾，我更建议把时间维度拉进来。把created_at解析成日期，按周聚合，算每周情感均值，能直观看到某个时间段情绪是突然高涨还是持续阴跌。

微博的created_at是类似“Tue Feb 22 12:00:00 +0800 2022”的英文格式，用pandas直接解析不一定认，建议用dateutil的parser去做兼容。

python复制from dateutil import parser

df["dt"] = df["created_at"].map(lambda x: parser.parse(x, fuzzy=True))
df["week"] = df["dt"].dt.to_period("W")
trend = df.groupby("week")["sentiment"].mean()
trend.plot(kind="line", title="微博情感趋势")
plt.savefig("sentiment_trend.png", dpi=200)

注意Windows下matplotlib默认字体也不支持中文，图里的标题如果要显示中文，得提前调用plt.rcParams["font.sans-serif"] = ["Microsoft YaHei"]，否则标题会是方框。这个坑和后面词云的中文字体问题同源。

5. 词云可视化：真正的功夫全在分词和停用词上

最后一步的词云可视化，看起来是最出效果的一步，实际上也是最容易被“效果”骗过去的一步。很多人直接拿清洗后的文本丢给wordcloud，生成出来的图全是“一个”“我们”“什么”这种废词，主题完全看不出来。

5.1 jieba分词之后，停用词表决定词云的质量

jieba是中文分词的主流工具，它会先试着自己把句子切成词。像“张雪峰”这种人名，初始词典不一定切得准，使用前先手动添加自定义词，否则可能被切成“张雪”和“峰”两个词，后续全乱套。

我处理时还会把两个字的无意义词全部砍掉，单字基本不留，只保留长度大于等于2的词。另外需要准备一份停用词表，微博场景里优先级最高的是“展开全文”“网页链接”“现在”“觉得”“真的”这类词。停用词表越贴合场景，词云越能反映真实主题。

python复制import jieba
from wordcloud import WordCloud
import matplotlib.pyplot as plt

jieba.setLogLevel(20)
jieba.add_word("张雪峰")
jieba.add_word("考研")
jieba.add_word("高考志愿")

extra_stopwords = {"一个", "什么", "我们", "你们", "他们", "已经", "就是", "时候", "现在", "自己", "可能", "真的", "这个", "那个", "展开全文", "网页链接"}
all_words = []
for text in df["text_clean"].dropna():
    for word in jieba.cut(text):
        word = word.strip()
        if len(word) < 2 or word in extra_stopwords:
            continue
        all_words.append(word)

content = " ".join(all_words)

5.2 中文字体和遮罩是两个最容易栽的坑

默认生成的词云图会出现满屏方框，因为wordcloud自带的字体不支持中文，解决办法是指定一个系统里存在的中文字体路径。Windows系统一般有C:/Windows/Fonts/msyh.ttc，这是微软雅黑；如果你没有优先使用ttf文件，可以统一用simhei.ttf。

设置遮罩图能让词云呈特定轮廓，比如拿一个圆形logo或者书本素材当底。实现方式是用PIL读入图片转成数组，再传给WordCloud的mask参数。需要注意的是遮罩图主体要和背景对比足够明显，纯白背景加黑色轮廓效果最好，背景不是纯白的话很难看。

python复制from PIL import Image
import numpy as np

mask = np.array(Image.open("mask.png"))
wc = WordCloud(
    font_path="C:/Windows/Fonts/msyh.ttc",
    mask=mask,
    width=1600,
    height=1000,
    background_color="white",
    max_words=200,
    collocations=False
).generate(content)

wc.to_file("result_wordcloud.png")

collocations=False也很关键。如果保持默认True，wordcloud会把相邻词拼成短语，词云里到处都是“考研 专业”和“学校 选择”这种二元组，整个图的信息密度反而下降，看起来像重复刷屏。

5.3 用词云的结果反过来校正清洗逻辑

我习惯在做完词云后回头检查一遍高频词。有一次词云里出现了“遇见”“阳光”这种明显不是教育博主高频词的词汇，一查发现是清洗时把“遇见更好的自己”这种宣传式话语里的词留下了，这说明我的停用词表还不够狠。

词云的另一个价值，是能帮你发现情感分析解释不了的主题。比如某段时间你可能看到词云里高频出现某个专业名称，而情感分数整体没变化，那不一定代表大家不关注，只是相关讨论处于中性表达状态。词云提供的是“大家在谈什么”，情感分析提供的是“谈得是否激烈”，两个结果交叉看才是完整的舆情简报。

6. 实测时的三个坑位和我的最终调优记录

任何爬虫项目最后都会落到“调试”两个字上。这里我专门把这次过程里最典型的三个问题写出来，按排查链路记录，方便你复现时少走弯路。

6.1 坑一：PyCharm只显示“Process finished with exit code 0”，什么都没有

这个问题的排查链路是这样的。我一开始以为代码写错了，但程序明明正常退出，后来在代码里加了print探测，发现连第一页请求都没进去。原因就是参数containerid没有取到，接口虽然返回了响应，但data.cardlistInfo是空的，服务器把我归入“异常访客”。

解决办法分两层。第一层是增强健壮性，所有接口响应都检查resp.status_code和data.get("ok")，不是理想的JSON结构就抛错。第二层是加日志，每一页至少打印一行状态，这样就算程序静默退出，你也能从最后一条日志看出卡在哪里。一个好的爬虫脚本，一定是时刻让你知道它活到第几行的脚本。

6.2 坑二：清洗后分词结果混入乱码和无意义词

张雪峰微博里偶尔会出现“狗头”和“doge”这类表情代表的网络语言，这些词在图里虽然醒目，但对主题判断没有贡献。我后来用自定义停用词表把这些网络语料也加进去，第二次生成的词云明显干净得多。

还有一个细节是繁体字。部分转发内容会混繁体，SnowNLP对繁体也能处理，但jieba分词遇到繁体词库覆盖不全，容易把“专业”切成“專”“业”这种单字。如果你发现词云里出现很多繁体单字，考虑加一步开放转换，把繁体统一转成简体再分词。

6.3 坑三：请求频率过高导致需要验证码

我试过把sleep间隔缩到0.3秒，结果第七页就开始要求验证，第八页直接是登录墙。把间隔恢复到1到2.5秒以后，连续抓几百条都没再翻车。这个现象说明微博的风控不是凭单一IP访问次数触发，而是跟请求节奏强相关。

另外，如果爬的过程中断，不要马上重跑，等几分钟再继续，让服务端的访问记录降一降温。有人会想用一堆User-Agent轮换伪装，实测下来对移动端接口未必有帮助，因为你还要保持会话一致性，频繁换头反而容易触发风险。稳定的单会话加低频请求，比花哨的技巧更靠谱。

6.4 这个项目还能怎么扩展

等基础版跑通以后，扩展方向很多。比如把抓取对象从正文换成评论，分析网友在评论区里到底吵什么，这需要额外定位评论接口；也可以把时间拉长到一年，按月做情感趋势，观察博主观点变化和舆情关联。更进阶一点的玩法是把微博中的院校和专业名做实体识别，再和情感分数联动，看公众对不同专业方向的情绪差异。

就目前这个版本而言，我已经能回答朋友最初的问题：公众对张雪峰微博的态度，整体是偏正向的，但争议内容确实能拉高互动量。这个结论靠人工翻完几千条微博也许也能得出，但换成今天这套方法，半小时内就能用数据把判断讲清楚。

项目做到这里，最让我有成就感的反而不是那张词云图，而是整个调试过程中建立的排查习惯：数据抓不到先看状态码，文本不干净先从清洗函数找原因，结果不合理就回查停用词。你如果也想跑一遍这个案例，建议先拿任何一位你感兴趣的博主试手，UID换成他的主页数字即可，流程完全通用，只是换了个数据集而已。