微博舆情分析系统实战：从爬虫采集到情感分析可视化

简介：一套基于Python的微博舆情分析系统设计与实现源码及论文文档，属于个人高分毕业设计项目，答辩评审达98分，代码经调试测试可稳定运行。资源面向计算机、通信、人工智能、自动化等相关专业的在校学生、教师及从业者，可作为毕业设计、期末课程设计或课程大作业的完整参考。压缩包共60个文件，包含11个Python源文件、13个HTML页面及配套UI、QRC资源文件，另有PyC编译文件、XML配置、Excel数据表、TOC目录及Word论文文档等，整体约44.27MB，目录结构清晰，便于按模块阅读源码、运行系统或撰写论文。目前已有277人学习下载。除可运行的系统代码外，还附带详细论文文档与项目说明文件，覆盖爬虫采集、舆情分析、结果展示等关键环节；基础较好的读者可直接在此基础上扩展功能，也可作为新手理解Python项目架构与Web开发的进阶素材。

1. 微博舆情分析系统到底是什么：不只是爬虫，是一条能跑通的分析闭环

微博舆情分析系统在个人毕设里属于高频选题，市面上的免费Python源码大全里几乎都能找到同名项目，但多数版本只能跑通演示数据。它的本质是一条“采集-清洗-分析-展示”的完整数据流水线：用Python爬取微博某个话题下的实时内容，去掉URL、@用户和广告噪声，对每条文本做情感倾向判断，最后用词云、趋势曲线和情感占比图把结果可视化出来。这套系统能解决的具体问题很明确：某个事件在微博上整体是正面还是负面、热度在什么时段冲高、讨论集中在哪些关键词。

它适合有Python基础、想独立拿下一个完整Web系统的在校生，也适合想让简历多一个“爬虫+文本挖掘+可视化”完整项目的初学者。如果只是把微博搜出来存进Excel，那不叫舆情分析系统，真正的分水岭在于三个环节：采集层能不能稳定跑几天、情感分析结果经不经得起人工核对、可视化能不能直接支撑论文里的分析结论。

2. 从0搭建数据采集层：微博搜索接口、表结构与登录态维护

网上python教程教你跑通一个requests.get很容易，但让采集任务稳定跑两周，关键在表结构、接口参数和登录态这三件事。这一章先说建表，再给最小采集代码，最后讲cookie维护，顺序是按踩坑频率排的。

2.1 采集前先定表结构：微博舆情主表怎么建

很多翻车现场都是从“拿到热搜词就开爬”开始的。爬了两天，想统计某个话题的讨论量，却发现没有单独存话题字段，只能对着正文做模糊匹配；想按小时画热度曲线，created_at存成了字符串。我一般会先写建表SQL再写爬虫，字段定下来，采集的数据口径就不会乱。

CREATE TABLE weibo_post ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, topic_id INT UNSIGNED NOT NULL COMMENT '所属话题ID', mid VARCHAR(40) NOT NULL COMMENT '微博唯一ID', text TEXT NOT NULL COMMENT '清洗后的微博正文', user_name VARCHAR(64) NOT NULL DEFAULT '' COMMENT '博主昵称', created_at DATETIME NOT NULL COMMENT '发博时间', reposts_count INT NOT NULL DEFAULT 0 COMMENT '转发数', comments_count INT NOT NULL DEFAULT 0 COMMENT '评论数', likes_count INT NOT NULL DEFAULT 0 COMMENT '点赞数', source VARCHAR(32) NOT NULL DEFAULT '' COMMENT '客户端来源', sentiment_score FLOAT NOT NULL DEFAULT 0 COMMENT '情感得分 0到1', sentiment_label TINYINT NOT NULL DEFAULT 0 COMMENT '1正向 0中性 -1负向', UNIQUE KEY uk_mid_topic (mid, topic_id), KEY idx_topic_time (topic_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='微博舆情主表';

这里最重要的是 (mid, topic_id) 联合唯一索引。爬虫翻页时经常遇到重复微博，入库时用 INSERT IGNORE 或者 ON DUPLICATE KEY UPDATE 去重，后面统计才不会被重复数据污染。created_at 用 DATETIME 而不是 VARCHAR，是为了聚合查询时能直接用 DATE()、DATE_FORMAT() 做分组，不用在Python里二次转换时间字符串。

存储选型上，个人毕设优先用MySQL，不选MongoDB。MongoDB的文档模型确实适合微博这种格式松散的文本，但答辩时你必须额外解释为什么引入非关系型数据库，而MySQL可以很直观地回答：舆情数据本质是结构化记录，字段稳定，后期统计报表全是SQL聚合，MySQL写起来最短。索引方面，idx_topic_time 是给“某话题+时间段”的聚合查询用的，这个复合索引比单列索引高效得多，后端接口响应时间能控制在几十毫秒。

2.2 用requests直连微博搜索接口的最小闭环

爬取策略上，最常见的做法是走微博移动端的搜索接口，返回的是规整JSON，解析成本比PC端网页低得多，也不用模拟浏览器。具体接口地址和参数在不同时期会微调，我用的是下面这种结构，你落地时以自己抓包到的请求为准。

import time import random import requests SEARCH_URL = "https://m.weibo.cn/api/container/getIndex" HEADERS = { "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) " "AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148", "Referer": "https://m.weibo.cn/search?containerid=100103type%3D1%26q%3D热搜词", "X-Requested-With": "XMLHttpRequest", "Cookie": "浏览器登录后复制到这里", } def fetch_search_page(keyword: str, page: int): params = { "containerid": f"100103type=1&q={keyword}", "page_type": "searchall", "page": page, } resp = requests.get(SEARCH_URL, params=params, headers=HEADERS, timeout=10) if resp.status_code != 200: raise RuntimeError(f"请求失败 HTTP {resp.status_code}") cards = resp.json().get("data", {}).get("cards", []) posts = [] for card in cards: if card.get("card_type") != 9: continue m = card.get("mblog", {}) posts.append({ "mid": str(m.get("id")), "text": m.get("text", ""), "created_at": m.get("created_at", ""), "reposts_count": m.get("reposts_count", 0), "comments_count": m.get("comments_count", 0), "likes_count": m.get("likes_count", 0), "user_name": m.get("user", {}).get("screen_name", ""), }) return posts

这段代码的逻辑是：构造关键词搜索参数，请求一次返回一页JSON，遍历 cards 数组，只保留 card_type=9 的普通微博，从嵌套的 mblog 对象里取出正文和互动数据。card_type 是接口里区分微博类型的关键字段，9代表普通微博，29代表图文微博，还可能混入广告卡和视频卡，写代码时不要默认所有卡片都是正文微博。

参数说明里值得注意的有四点：page 从1开始，单关键词一般最多翻50页，超过会返回空列表；timeout 设10秒，防止网络抖动导致请求无限挂起；Referer 里的关键词要和请求参数里的 keyword 一致，否则部分接口会拒绝；resp.json() 之前必须先判断状态码，反爬返回的HTML文本会被解析成空JSON，让你误以为“这个关键词没有数据”。

接口地址怎么确定？用浏览器开发者工具切到手机模式，打开微博搜索页输入关键词，找到名为 getIndex 的请求，复制它的URL和参数模板。移动端接口的 containerid 是动态拼接的，关键词变了它也跟着变，这和PC端固定参数不一样，所以务必把URL模板和参数结构抽成常量，不要散落在业务代码里。

2.3 登录态与Cookie维护：舆情采集可持续性的分水岭

微博搜索接口不登录也能返回一部分数据，但匿名请求的限流阈值很低，翻几页就开始返回验证码或重复内容。个人毕设最省事的方案是：浏览器登录一次微博，把Cookie复制进代码，让采集请求带上登录态。这个方案能支撑单日几千条的采集量，前提是你接受Cookie过期后手动更新。

import json COOKIE_FILE = "cookie.json" def load_cookie(): # 第一次从浏览器复制，之后都从本地文件读，避免改代码 with open(COOKIE_FILE, "r", encoding="utf-8") as f: return json.load(f)["cookie"] def is_login_valid(): # 用小请求探测登录态是否过期 probe = requests.get("https://m.weibo.cn/api/config/session", headers=HEADERS | {"Cookie": load_cookie()}, timeout=10) return probe.json().get("data", {}).get("login", False)

is_login_valid 的用途是给定时采集任务加一道闸门：每天爬虫启动前先探测一次，登录态失效就中止任务并通知你刷新Cookie，而不是让任务在报错日志里反复重试。它背后的逻辑是 session 接口返回的 login 字段，值为 false 就代表Cookie已失效。

Cookie过期是这块最经典的翻车现场：你以为采集任务在正常跑，实际一整天存进来的全是“请先登录”的HTML页面。我的习惯是Cookie失效后不修改代码，而是重新登录一次，新Cookie写进 cookie.json。同时，采集循环里每页之间加1到3秒随机延时，配合失败重试和指数退避。

随机延时的作用不是“防封”，而是把请求节奏调得更像真人浏览，降低被风控系统打标记的概率。单话题单日采集量控制在几千条以内比较安全，如果你有多个话题要采，拆到每天的多个时段去跑，别一次性把所有话题爬完。

3. 舆情数据清洗与情感分析：微博短文本怎么算才靠谱

微博文本短、噪声多、反讽多，这三点决定了清洗规则和情感模型的选择不能照搬新闻语料。这一章按处理顺序来：先清洗，再打分，最后修正网络新词。

3.1 微博短文本清洗规则：去噪与保留的取舍

原始微博文本里充斥着URL、@用户、话题标签、HTML实体和表情符号。如果直接丢给jieba分词和SnowNLP，词频统计里会出现大量“转发”“链接”，词云的中心词毫无意义。清洗的核心是区分什么该删、什么该留：URL和@是噪声，必须去掉；话题标签里的词往往是舆情关键词，保留内容但去掉两边的#号；表情符号在词云里是噪声，但在情感分析里是情绪线索，不能一律删掉。

import re def clean_text(raw: str) -> str: # 去掉URL，微博短链形如 https://t.cn/xxxx text = re.sub(r"https?://\S+", "", raw) # 去掉@用户，保留昵称后面的正文 text = re.sub(r"@[\w\u4e00-\u9fa5\-]{1,20}[:：]?", "", text) # 话题标签：去掉##，但把话题词留下来 text = re.sub(r"#(.+?)#", lambda m: m.group(1), text) # 表情符号统一转成文本，如[嘻嘻] -> 嘻嘻 text = re.sub(r"\[(.*?)\]", lambda m: " " + m.group(1) + " ", text) # 连续重复标点压缩成单个 text = re.sub(r"(\W)\1{2,}", r"\1", text) # 还原常见HTML转义实体 text = (text.replace("&nbsp;", " ") .replace("&lt;", "<").replace("&gt;", ">") .replace("&amp;", "&")) return text.strip()

正则里的 https?://\S+ 匹配以http或https开头的非空白字符序列，微博短链和图片链接都能吃掉；@用户的匹配要小心，微博昵称允许中文，所以用 \u4e00-\u9fa5 和 \w 结合，后面的 [:：]? 处理“@某某：正文”的冒号。表情转文字这一步，如果只做词云可以改成直接删除；但要跑情感分析就建议保留，“开心”“愤怒”这类表情词本身就是极强的情绪信号。

清洗函数建议在入库前调用一次，结果直接存进 weibo_post.text，不要等到分析阶段再清洗，否则词云接口每次都要对全表跑正则，耗时指数上升。清洗后的文本可能变成空字符串，比如一张纯图片配一个表情，这类样本在情感分析阶段直接剔除。参数上唯一要注意的是 re.sub 的扫描开销，对十万级数据量影响不大，但到了百万级，建议预编译所有正则表达式。

3.2 SnowNLP情感打分与阈值设定：不要用0.5一刀切

微博舆情分析的常见情感方案有两种：基于情感词典统计正负词个数，或者直接用SnowNLP。词典方案透明、可控，工程量大，需要维护一份能覆盖微博缩略语的领域词典；SnowNLP开箱即用，但它的训练语料偏电商购物评论，在微博短文本上直接跑，精度会肉眼可见地下降。两者之间我选SnowNLP做底，配合自定义词典修正，理由是你永远不可能靠手工词典覆盖所有反讽表达。

from snownlp import SnowNLP def sentiment_of(text): s = SnowNLP(text) score = s.sentiments if score >= 0.6: return round(score, 4), 1 elif score <= 0.4: return round(score, 4), -1 return round(score, 4), 0

SnowNLP 的 sentiments 属性返回0到1之间的概率值，越接近1代表越正向，越接近0越负向。如果直接拿0.5当分界线，微博里大量“还行”“一般般吧”这类含混表达会被硬分成正或负，情感占比饼图就失真了。所以我用双阈值：0.6以上判正向，0.4以下判负向，中间算中性，让模糊样本留在中性区，不强行站队。

阈值0.6/0.4不是随手拍的，建议抽200条样本来回试，看阈值调到多少时人工标注的一致率最高。调成0.8/0.2会让大部分样本落到中性，饼图灰成一片；不设中性带又会让正负占比虚高。阈值本质是控制“不确定样本”比例，宁缺毋滥。参数名我习惯叫 threshold_pos 和 threshold_neg，写进配置中心，方便论文实验部分说明不同阈值下的准确率对比。

3.3 自定义词典与表情修正：舆情分析的最后一公里

SnowNLP处理不了“yyds”“绝绝子”“芭比Q了”这类网络新词，也识别不了“真好笑，又翻车了”这种反讽。这是短文本舆情分析的模型边界，不是换一个库就能解决的。最实际的折中方案是维护一个自定义先验词典，在SnowNLP打分结果上做加权修正。

PRIOR_WORDS = { "yyds": 0.9, "绝绝子": 0.9, "芭比Q了": 0.15, "翻车": 0.2, "笑死": 0.7, "无语": 0.2, } def adjust_score(text, score): # 命中词典词的样本，把预测分往先验方向拉 hit_count = 0 total_prior = 0.0 for word, prior in PRIOR_WORDS.items(): if word in text: hit_count += 1 total_prior += prior if hit_count == 0: return score avg_prior = total_prior / hit_count return round(score * 0.4 + avg_prior * 0.6, 4)

修正逻辑是简单加权平均：一条微博命中多个词典词时，先算所有先验值的平均，再与SnowNLP原始得分按4:6混合。混合系数0.4/0.6是我在微博语料上的经验值，既保留模型整体判断，又让强情绪词主导结果。你可以按自己语料调，原则是让网络热词命中的样本多听先验词的话。词典不要贪大，维护20到30个高频误判词就够，超过50个后修正的误伤率会上升。

词典收集方式应该和数据采集同步：每天抽20条新样本人工读一遍，看到错判就加词。比如把“冲上热搜”设为0.6，是因为这个词单独出现时中性偏正向，但SnowNLP经常把它算成负向。词典文件我建议单独存成 JSON 或 TSV，格式保持 word:prior_score 一行，不要硬编码在脚本里，这样论文实验里可以对比“加词典前 vs 加词典后”的准确率。

4. 系统设计与可视化：Flask、MySQL与ECharts的落地组合

python爬虫可视化界面最常用的落地方案就是Flask提供接口、ECharts渲染页面。选Flask不选Django，是因为这个项目不需要Django的admin后台、ORM全套和中间件机制，Flask一个蓝图加几个接口就能演示，答辩时也不用铺开讲复杂框架。

4.1 话题表与热词表：让舆情分析有维度、可统计

第2章的 weibo_post 是舆情事实表，但单独一张表撑不起“哪个话题讨论量最高”“今天的热词是什么”这类问题。我一般再建两张表：weibo_topic 记录采集任务配置，hotword_daily 存天级热词聚合结果。

CREATE TABLE weibo_topic ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, topic_name VARCHAR(64) NOT NULL COMMENT '展示用话题名', keyword VARCHAR(64) NOT NULL COMMENT '采集用搜索关键词', is_active TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0停用', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_keyword (keyword) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='话题配置表'; CREATE TABLE hotword_daily ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, topic_id INT UNSIGNED NOT NULL COMMENT '关联话题', word VARCHAR(32) NOT NULL COMMENT '热词', cnt INT NOT NULL DEFAULT 0 COMMENT '当天出现次数', stat_date DATE NOT NULL COMMENT '统计日期', UNIQUE KEY uk_word_date (topic_id, word, stat_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='热词日统计表';

topic 表和 post 表通过 topic_id 关联，post 里不直接存话题字符串，这样话题改名或关键词调整时历史数据不用跟着改。hotword_daily 的思路很直接：词频统计是计算密集操作，每天凌晨用定时任务把前一天的热词写进这张表，前端查询只做简单SELECT，不再对全表 text 跑分词。这个设计值得写进论文“系统设计”章节，它体现了批量计算与查询分离的工程思想。唯一索引 (topic_id, word, stat_date) 保证热词统计任务重复执行不产生脏数据，配合 INSERT ... ON DUPLICATE KEY UPDATE 实现幂等更新。

4.2 Flask后端：把舆情分析结果封装成聚合接口

接口设计遵循一个原则：聚合运算全部交给SQL完成，Python只做参数处理和结果格式化。这样接口代码短、响应快，也方便答辩时直接演示。

# app.py 片段 from flask import Blueprint, jsonify, request from db_utils import get_connection api = Blueprint("api", __name__) @api.route("/api/trend") def trend(): topic_id = request.args.get("topic_id", type=int) days = request.args.get("days", default=7, type=int) sql = """ SELECT DATE(created_at) AS d, COUNT(*) AS total, SUM(sentiment_label = 1) AS pos, SUM(sentiment_label = -1) AS neg FROM weibo_post WHERE topic_id = %s AND created_at >= DATE_SUB(CURDATE(), INTERVAL %s DAY) GROUP BY d ORDER BY d """ with get_connection() as conn: with conn.cursor() as cur: cur.execute(sql, (topic_id, days)) rows = cur.fetchall() return jsonify(rows)

这个接口对应前端时间趋势图。SELECT 里用 SUM(sentiment_label = 1) 是MySQL里布尔表达式转0/1的写法，等于按标签计数，比在Python里循环统计快得多。参数 topic_id 和 days 都经过 type=int 强制转换，避免前端传字符串导致类型错误。这里用参数化查询%s而不是字符串拼接，一方面是避免SQL注入，另一方面MySQL能复用查询计划。

参数说明：days 默认7，前端下拉框限制可选1、7、14、30天；日期临界点用 DATE_SUB(CURDATE(), INTERVAL %s DAY)，按自然日计算，包含今天但不包含未来数据。如果你关注小时粒度，把 DATE(created_at) 换成 DATE_FORMAT(created_at, '%Y-%m-%d %H:00')，但小时级数据量少时需要先检查曲线毛刺，别一上来就全量按小时聚合。连接管理用常见的数据库连接池封装 get_connection()，不要每个请求新建连接，Flask开发模式下会拖慢响应。

4.3 ECharts可视化：词云、趋势曲线与情感占比

可视化页面直接套一个开源的admin模板，把ECharts实例嵌进去，不用从零写CSS。真正的可视化工作集中在两点：后端把数据聚合成前端要的数组，前端按ECharts的option格式填充。下面是一段趋势图的核心逻辑。

// dashboard.js 片段 const trendChart = echarts.init(document.getElementById('trend')); async function loadTrend(topicId, days) { const res = await fetch(`/api/trend?topic_id=${topicId}&days=${days}`); const data = await res.json(); trendChart.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['总量', '正向', '负向'] }, xAxis: { type: 'category', data: data.map(item => item.d) }, yAxis: { type: 'value' }, series: [ { name: '总量', type: 'line', data: data.map(item => item.total) }, { name: '正向', type: 'line', data: data.map(item => item.pos) }, { name: '负向', type: 'line', data: data.map(item => item.neg) } ] }); }

这段代码用fetch把接口JSON直接映射成series数组。三个系列共用xAxis日期数据，后端返回的 date 是字符串，ECharts可以直接识别。tooltip 用 trigger: 'axis'，适合多折线对比场景。需要注意 fetch 在旧浏览器不支持，但毕设演示环境通常都是Chrome，不用考虑兼容性。

词云实现有两条路：一是用ECharts官方词云扩展，交互流畅；二是在Python里用wordcloud生成静态图。毕设推荐后者多些，因为论文需要贴图，静态图片可以直接导出，不依赖浏览器环境。词云数据来自 hotword_daily 表，SQL按 cnt 降序取前50词，Python侧再做一轮过滤，去掉“微博”“转发”“全文”这类无意义词。情感占比饼图更简单，一条SQL按 sentiment_label 分组取COUNT，前端用饼图渲染。趋势图加饼图，正好回答舆情系统最核心的两个问题：什么时候讨论最热、整体情绪是正是负。

5. 微博舆情分析系统避坑清单：5个让我改代码的翻车现场

5.1 cookie过期：采集任务全线报错

现象：爬虫日志里突然出现大量HTTP 401，或者返回的JSON里 data 为空，之前一直正常的采集任务一夜之间全变成登录页内容。

原因：微博登录态有效期不长，手动复制的Cookie一般撑几天到两周，过期后所有带Cookie的请求都被引导到登录接口。很多项目把Cookie硬编码在代码里，过期后还要改代码重启，排查链路特别长。

解决：Cookie单独存配置文件，运行时读取；每天采集前先调用 session 探测接口检查登录态，失效就中止任务并提示人工更新。我还会加一个“最近成功采集时间”字段，超过24小时没有新数据入库就告警，这样不用等答辩才发现数据断了一周。

5.2 SnowNLP把反讽当正向：情感分析数据失真

现象：采集“某产品翻车”话题，情感占比饼图里正向居然超过40%，随便翻几条原文，满屏都是“真好笑，又翻车了”。

原因：SnowNLP训练语料接近电商评论，对反讽、网络新词不敏感。它判断“真好笑”时会偏向“好”字，完全忽略语境里的否定和讽刺意味。

解决：把高频误判样本收进自定义先验词典，用分数加权修正。更重要的是在论文里承认这个局限，用人工标注数据算出模型在反讽场景的失败比例，这比假装系统完美更能拿分。答辩老师问“你的系统有什么不足”时，这个问题反而是最好的谈资。

5.3 中文乱码：MySQL里全是问号

现象：采集的微博文本写入MySQL后中文全变成“???”，Python控制台打印却正常。

原因：三处字符集不一致。建表时默认字符集不是utf8mb4、连接串没有指定charset、以及终端本身是GBK导致的误判。最隐蔽的是连接串问题，PyMySQL默认跑utf8mb4，但连接池封装可能丢参数。

解决：建库指定 DEFAULT CHARSET=utf8mb4，连接串显式加 charset=utf8mb4、use_unicode=True，代码文件头统一# -*- coding: utf-8 -*-。注意是 utf8mb4 不是 utf8，微博文本里的生僻字和Emoji需要4字节编码，utf8只支持到3字节。

5.4 高频采集触发风控：接口突然变慢

现象：采集同一关键词时前两页正常，从第三页开始返回重复内容、验证码，或者接口响应时间从0.5秒突然变成5秒。

原因：单线程连续请求且间隔固定。固定间隔也是个破绽，间隔恒定在1.000秒的脚本比间隔随机的机器人更容易被识别。

解决：请求间隔改成1到3秒随机值，单话题单日采集量控制在几千条以内。失败时先停止而不是立即重试，指数退避起始间隔设为30秒，连续失败3次就跳过当前页。如果需要采集多个话题，拆到每天不同时段跑，避免在同一时间窗口制造密集请求。这个现象不代表你要放弃采集，而是把节奏调回“像人”的状态。

5.5 微博接口改版：解析字段对不上

现象：某天开始，之前正常入库的微博突然全是空文本，或者mid从字符串变成了数字，程序不报错但数据是脏的。

原因：微博移动端接口的卡片结构不定期调整，card_type的类型码、mblog里的字段名都可能变。线上代码如果直接 data["cards"]["mblog"]["text"] 这种硬索引，一处字段变化就会连环报错，更麻烦的是有些接口返回了字段但类型变了。

解决：解析层封装成独立函数，字段统一用 dict.get() 带默认值，不要直接下标取值；min 的 id 强制转 str，避免类型漂移。保留一份最近成功的JSON样本做测试夹具，每次改版后跑一遍测试，能快速定位是接口变了还是代码写错。我在实际项目里见过mid是字符串和整数混用的情况，入库前强转是最后的防线。

6. 给毕设加分的验证方法：用准确率评估让论文有话可说

6.1 人工标注100条样本对比模型结果

情感分析的论文章节最容易写空。我的方法是准备100条采集原文，自己或找同学人工标注，每条标1（正向）、0（中性）、-1（负向），再用同一套清洗和情感函数跑一遍，算出整体准确率以及正负类各自的召回率。抽样时按发布时间分层，不要只抽前几页，否则正负类别不平衡，评估结果会虚高。

# evaluate.py from sentiment import sentiment_of def evaluate(samples): correct = 0 total = len(samples) for item in samples: text = item["text"] label = item["label"] pred = sentiment_of(text)[1] correct += (pred == label) return correct / total

这个脚本跑出来的数字直接写进论文“实验与结果”章节，再配一张混淆矩阵表格。即使准确率只有75%，也比不写任何评估强，因为你可以分析那25%错在哪，并据此调整词典和阈值，论文里形成“评估-调优-再评估”的闭环。

6.2 用两个对照话题验证系统区分度

另一种有效验证是选两个性质明确的话题做对照：一个普遍正面的体育夺冠事件，一个普遍负面的产品翻车事件，跑完整流程后对比情感占比和热词分布。如果夺冠话题的正向占比显著高于翻车话题，说明清洗和情感分析管线具备基本的舆情区分能力。这两个对照实验做成论文里的case study，配上趋势图和词云图，视觉说服力远强于“系统能正常运行”这句描述。

我的亲身教训是：所有验证都要保留中间产物——清洗前后的文本、模型打分和人工标注的对比表。答辩老师往往不只看架构图，而是顺手点开数据看分析得合不合理。保留中间数据，既是论文可复现性的基本要求，也方便你回溯“这个分数是怎么算出来的”。这个习惯帮我救回过至少两次数据口径对不上的情况，希望帮到你。

本文还有配套的精品资源，点击获取