简介这是一套面向高校学生的Python网络舆情分析系统完整项目可作为Python毕业设计或课程设计使用适合具备Python基础、需要完成综合实践项目的学习者。项目采用Python 3.7或3.8开发配合PyCharm与Navicat数据库为MySQL前后端代码齐全功能完善、界面美观、操作简单具有较高的实际应用价值。压缩包共287个文件约75.63MB包含42个py源码文件、35个pyc编译文件、34个js脚本、15个css样式、12个html页面以及gif、jpg、png等界面素材和sql数据库脚本、csv数据文件、pb模型文件等覆盖前端页面、后端逻辑与数据存储各环节。项目经过严格调试可正常运行部署时用PyCharm导入、pip安装依赖、配置数据库密码后即可启动。目前已有124人学习下载适合需要完整项目参考、快速搭建舆情分析系统并完成毕业设计的学生。1. 从一份毕业设计压缩包说起网络舆情分析系统到底在分析什么打开一份名为「基于python的网络舆情分析系统」的毕业设计压缩包多数人第一反应是找requirements.txt和数据库脚本然后卡在「数据从哪来」这一步。这个标题真正要解决的问题不是「做一个网站」而是把散落在社交平台、新闻评论区的非结构化文本变成能按时间、情感、关键词三个维度下钻的结构化结论。它适合两类人一类是正在做毕业设计、需要一套能跑通、能答辩、能写进论文的系统骨架另一类是刚接触 Python 数据分析、想拿一个完整项目练手的入门者。核心链路只有四段——采集、清洗、分析、可视化缺任何一段系统就退化成一张静态图表。下面按我实际搭过几套类似系统的顺序把每一段拆开讲。2. 技术选型与数据采集为什么用 Python 而不是 Java 或 PHP2.1 选型对比Flask SQLite 与 Django MySQL 的取舍毕业设计场景下选型的第一约束不是性能是「能不能在一台普通笔记本上跑起来并且让答辩老师看懂」。常见做法是 Flask 做后端、SQLite 做存储、ECharts 做前端图表这套组合的依赖最少pip install三条命令就能起步。如果学校要求必须用 MySQL那就换成 Flask MySQL代码改动量在数据库连接层不超过 20 行。方案依赖复杂度适合场景主要代价Flask SQLite低单机演示、数据量 10 万条以内并发写入弱不适合多用户Flask MySQL中需要展示数据库设计、数据量较大要装服务、配账号密码Django MySQL高要求完整后台管理、用户权限学习曲线陡答辩讲不清我一般会先问一句你的数据量级和答辩重点是什么如果重点是「分析算法」选 SQLite 把精力留给情感分析如果重点是「系统架构」选 MySQL 把 ER 图做扎实。2.2 采集层用 requests BeautifulSoup 抓取评论的最小实现采集是第一个翻车高发区。很多同学直接对着页面requests.get拿回来一堆空数据原因是目标页面是前端渲染的。稳妥做法是先确认数据是否在 HTML 源码里在的话用 BeautifulSoup 解析不在的话找接口返回的 JSON。import requests from bs4 import BeautifulSoup import time import random HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 } def fetch_comments(url, max_page5): 抓取评论列表返回 [(用户名, 评论内容, 时间), ...] results [] for page in range(1, max_page 1): # 分页参数名各站不同常见是 page / p / offset resp requests.get(url, params{page: page}, headersHEADERS, timeout10) if resp.status_code ! 200: print(f第 {page} 页返回 {resp.status_code}跳过) continue soup BeautifulSoup(resp.text, html.parser) # 选择器要按实际页面结构调整这里用 class 示例 for item in soup.select(.comment-item): user item.select_one(.user-name) content item.select_one(.comment-text) ts item.select_one(.time) if content: results.append(( user.get_text(stripTrue) if user else 匿名, content.get_text(stripTrue), ts.get_text(stripTrue) if ts else )) # 随机间隔降低被限流的概率 time.sleep(random.uniform(1.5, 3.5)) return results逻辑说明HEADERS里带 User-Agent 是基本礼貌很多站点没有它会直接返回 403。params传分页参数比手动拼 URL 更清晰。time.sleep的随机区间是关键固定间隔容易被识别为脚本行为。参数调整上max_page控制采集深度毕业设计演示 5 到 10 页足够timeout设 10 秒避免单页卡死拖垮整个流程。提示采集前先确认目标站点的 robots.txt 和使用条款只采集公开、允许抓取的数据不要碰需要登录才能看的内容。2.3 数据落库SQLite 建表与批量插入采集回来的数据要落库否则程序一关就没了。SQLite 不需要额外服务一个文件就是数据库适合毕业设计。import sqlite3 def init_db(db_pathopinion.db): conn sqlite3.connect(db_path) cur conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS comments ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT, content TEXT NOT NULL, publish_time TEXT, source TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) # 内容字段建索引后面按关键词查询会快很多 cur.execute(CREATE INDEX IF NOT EXISTS idx_content ON comments(content)) conn.commit() return conn def save_comments(conn, rows, sourcedemo): cur conn.cursor() cur.executemany( INSERT INTO comments (username, content, publish_time, source) VALUES (?, ?, ?, ?), [(u, c, t, source) for u, c, t in rows] ) conn.commit() print(f写入 {len(rows)} 条)逻辑说明executemany比循环execute快一个数量级几千条数据差距明显。idx_content索引是为后面的关键词统计服务没有索引时LIKE %关键词%在万级数据上会明显变慢。参数上source字段用来区分不同来源方便后续按平台做对比分析。3. 文本清洗与情感分析把评论变成可计算的分数3.1 中文分词与停用词过滤原始评论里全是表情、、链接和「哈哈哈哈」不洗一遍情感分析结果会严重失真。常见做法是 jieba 分词加一份停用词表。import jieba import re STOPWORDS set() with open(stopwords.txt, encodingutf-8) as f: for line in f: STOPWORDS.add(line.strip()) def clean_text(text): 去掉 URL、、表情符号和多余空白 text re.sub(rhttp\S, , text) text re.sub(r[\w\u4e00-\u9fa5], , text) text re.sub(r\[.*?\], , text) # 表情占位符 text re.sub(r\s, , text) return text.strip() def tokenize(text): words jieba.lcut(clean_text(text)) return [w for w in words if w not in STOPWORDS and len(w) 1]逻辑说明clean_text里四条正则分别处理链接、用户、表情占位符和空白。len(w) 1过滤掉单字因为中文单字噪声大。停用词表建议用哈工大停用词表再手动补上「转发」「点赞」这类平台词。3.2 基于 SnowNLP 的情感打分与阈值校准情感分析是这类系统的核心卖点。SnowNLP 开箱即用但它的默认阈值不一定适合你的数据必须校准。from snownlp import SnowNLP def sentiment_score(text): 返回 0~1 的情感分越接近 1 越正面 cleaned clean_text(text) if not cleaned: return None return SnowNLP(cleaned).sentiments def label(score, pos0.6, neg0.4): 按阈值打标签阈值需要根据实际数据调整 if score is None: return 无效 if score pos: return 正面 if score neg: return 负面 return 中性逻辑说明SnowNLP 返回的是 0 到 1 的连续值直接按 0.5 切会得到大量「中性」区分度差。我一般会先跑 200 条人工标注样本看正面和负面各集中在哪个区间再定pos和neg。参数上pos0.6、neg0.4是常见起点如果数据里负面评论多可以把neg提到 0.45。注意SnowNLP 在电商评论上表现尚可在新闻评论或论坛语境下准确率会下降答辩时如果被问到可以坦诚说明并给出人工抽检的准确率数据比硬撑更可信。3.3 关键词提取与词云数据准备除了情感舆情系统还要回答「大家在讨论什么」。TF-IDF 是性价比最高的方案。from sklearn.feature_extraction.text import TfidfVectorizer def extract_keywords(texts, top_k30): 从评论文本列表里提取 TF-IDF 关键词 tokenized [ .join(tokenize(t)) for t in texts] vectorizer TfidfVectorizer(max_features1000) matrix vectorizer.fit_transform(tokenized) scores matrix.sum(axis0).A1 words vectorizer.get_feature_names_out() ranked sorted(zip(words, scores), keylambda x: x[1], reverseTrue) return ranked[:top_k]逻辑说明tokenize复用前面的分词函数保证清洗逻辑一致。max_features1000限制词表大小避免内存爆掉。matrix.sum(axis0)把每篇文档的 TF-IDF 值按词累加得到全局权重。返回的ranked直接喂给前端词云组件即可。4. 可视化与 Web 展示让答辩老师三秒看懂结果4.1 Flask 路由设计与接口划分后端接口不用多四个就够总览统计、情感分布、关键词排行、时间趋势。from flask import Flask, jsonify, render_template import sqlite3 app Flask(__name__) def query(sql, args()): conn sqlite3.connect(opinion.db) conn.row_factory sqlite3.Row rows conn.execute(sql, args).fetchall() conn.close() return [dict(r) for r in rows] app.route(/) def index(): return render_template(index.html) app.route(/api/sentiment) def api_sentiment(): rows query(SELECT content FROM comments) dist {正面: 0, 中性: 0, 负面: 0} for r in rows: s sentiment_score(r[content]) dist[label(s)] 1 return jsonify(dist) app.route(/api/keywords) def api_keywords(): rows query(SELECT content FROM comments) texts [r[content] for r in rows] return jsonify(extract_keywords(texts, top_k30))逻辑说明query封装了连接和关闭避免每个接口重复写。row_factory sqlite3.Row让结果能直接转字典。情感接口每次请求都重新计算数据量大时应该加缓存毕业设计数据量下可以接受。4.2 ECharts 前端接入与数据绑定前端用 ECharts 的饼图和词云数据从上面的接口拿。// 情感分布饼图 fetch(/api/sentiment) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(sentiment)); chart.setOption({ series: [{ type: pie, data: Object.entries(data).map(([name, value]) ({ name, value })), // 正面绿、负面红符合直觉 color: [#52c41a, #faad14, #f5222d] }] }); });逻辑说明Object.entries把后端返回的{正面: 120, 中性: 80, 负面: 45}转成 ECharts 需要的数组格式。颜色顺序要和data的键顺序对应否则会出现「正面显示红色」这种低级错误。词云图需要额外引入echarts-wordcloud插件数据格式是[{name, value}]直接把/api/keywords的返回结果传进去。4.3 时间趋势折线图的 SQL 聚合时间趋势要按天聚合SQL 里用substr截取日期。SELECT substr(publish_time, 1, 10) AS day, COUNT(*) AS total, SUM(CASE WHEN sentiment 负面 THEN 1 ELSE 0 END) AS negative FROM comments WHERE publish_time IS NOT NULL GROUP BY day ORDER BY day;逻辑说明substr(publish_time, 1, 10)假设时间格式是2024-01-15 10:30:00截前 10 位得到日期。如果采集时时间格式不统一先在清洗阶段标准化。SUM(CASE WHEN ...)是条件计数的标准写法比跑两次查询高效。5. 避坑与排查那些让系统跑不起来的细节5.1 采集返回空列表现象fetch_comments返回[]但浏览器里能看到评论。原因页面是 JavaScript 渲染的requests拿到的 HTML 里没有评论节点。解决打开浏览器开发者工具的 Network 面板找返回 JSON 的接口直接请求接口或者用 Selenium 渲染后再解析但毕业设计里优先找接口更轻量。5.2 中文乱码现象数据库里存进去的中文变成????或乱码。原因SQLite 默认编码没问题问题通常出在requests的resp.text上当响应头没声明编码时requests会猜错。解决显式指定resp.encoding resp.apparent_encoding再取resp.text。5.3 SnowNLP 首次调用报错现象SnowNLP(text).sentiments抛异常或返回 0.5。原因SnowNLP 依赖内置语料首次调用会加载模型如果安装不完整或文本为空会出问题。解决先判断cleaned是否为空空文本直接返回None确认snownlp安装完整必要时重装。5.4 词云图不显示现象前端词云区域空白控制台报series.wordCloud is not a function。原因只引入了echarts没引入echarts-wordcloud插件。解决在 ECharts 之后引入echarts-wordcloud.min.js并确认series.type写的是wordCloud大小写敏感。5.5 数据库锁死现象程序运行中报database is locked。原因SQLite 同一时刻只允许一个写操作采集线程和 Web 请求同时写会冲突。解决采集和展示分开跑采集完再启动 Web或者把连接超时设长sqlite3.connect(opinion.db, timeout15)。6. 进阶技巧把情感分析准确率从 70% 提到 85% 的验证方法SnowNLP 的默认模型在通用语料上训练直接用在你的数据上准确率大概七成。想提上去最有效的不是换模型是校准阈值加人工抽检。具体做法从数据库随机抽 200 条人工标注正面、中性、负面然后跑一遍你的label函数算混淆矩阵。from sklearn.metrics import classification_report # y_true 是人工标注y_pred 是系统输出 y_true [...] # 200 条人工标签 y_pred [label(sentiment_score(t)) for t in texts] print(classification_report(y_true, y_pred, labels[正面, 中性, 负面]))看classification_report的输出重点看负面类的recall。如果负面召回低说明阈值neg定高了把负面评论误判成了中性调低neg再跑一遍。这个过程迭代两三轮准确率通常能到 85% 左右。如果学校允许可以在论文里把这套校准流程写成一个小节比单纯说「用了 SnowNLP」有说服力得多。另一个技巧是分来源校准。不同平台的评论风格差异大微博的负面表达和新闻评论区的负面表达不一样。按source字段分组每组单独定阈值比全局一个阈值更准。代价是要维护多套参数毕业设计里如果数据来源单一可以跳过。最后说个我自己的习惯每次改完阈值或清洗规则都把当次的classification_report存一份到logs/目录文件名带日期。答辩前翻一遍能清楚说出「我调了哪几次、每次为什么调、效果变化多少」。这套记录比任何 PPT 都管用老师问细节时直接翻日志比临场编靠谱。希望帮到你。本文还有配套的精品资源点击获取