拓冰网站定制 
简介这是一套基于Python构建的网络舆情分析系统完整源代码项目面向毕业设计、课程设计或舆情分析初学者帮助快速掌握前后端分离开发与舆情数据处理流程。系统覆盖言论采集、情感判断、饼状统计图可视化、用户密码维护及管理员用户管理等功能采用Python 3.6.8与MySQL 5.7开发内置数据库脚本和详细部署文档便于直接运行或二次开发。压缩包共289个文件包含42个Python后端源码、34个前端JavaScript脚本、15个CSS样式、12个HTML页面以及大量GIF演示图、JPG截图、SQL脚本和说明文档整体约83.39MB结构清晰可按模块对照学习。配套的说明文档、论文及演示资源能直观展示系统运行效果帮助理解从数据采集到可视化呈现的完整链路。已有一百人学习下载适合需要快速搭建舆情分析原型或完成课程设计的学生参考。1. 一套能交差的Python舆情分析系统先看它到底解决什么拿到“基于python的网络舆情分析系统源代码完整前后端mysql说明文档LW.zip”这类包的同学多数不是来研究自然语言处理的而是要在两周内交一份能演示、能答辩的毕设或课设。但根据我帮人跑通这类项目的经验真正拦住你的从来不是那几千行代码而是环境Python版本、MySQL能不能连、前端请求有没有打到后端80%的翻车都发生在这三件事上跟算法关系不大。这套系统的价值在于把一条完整的舆情数据链路摆在你面前爬虫采评论、清洗分词、情感打分、结果入MySQL、后端出接口、前端画图表。它适合两类人一是做毕业设计的学生二是想快速搭一个舆情监测Demo给团队看效果的开发者。LW指项目自带的论文文档也就是说代码结构、图表、结论最好能和论文里的系统设计章节一一对上这决定了你后面改代码的边界。2. 拆系统架构与MySQL数据模型建表脚本和关键字段2.1 五段式数据链路采集、清洗、分析、存储、展示我先说这类舆情系统最常见的组织方式因为你要改代码前得先知道每一段在哪。整套系统按数据流向分成五段爬虫负责从新闻、微博、电商评论等渠道抓文本清洗段去掉HTML标签、噪声字符和停用词分析段做情感打分和热词统计MySQL存清洗后的文本和计算结果Flask后端把数据包装成JSON接口Vue前端用ECharts画趋势图和词云。这五段在源码包里通常对应五个目录命名可能是spider/、clean/、analysis/、api/、web/也可能叫别的但结构大致如此。为什么这套选型是“标准答案”因为Flask比Django轻路由写法直观而且和Python数据分析栈天然亲和MySQL是文档里最好交代的存储方案Vue加ECharts能在一页里展示表格、饼图、词云三种图答辩时视觉效果够用。我建议你拿到包后先别急着跑按这个五段结构把代码目录过一遍在说明书上标注每一段对应的文件路径后面改Bug会快很多。模块常见选型选型理由采集requests BeautifulSoup轻量、上手快、适合静态页面清洗re jieba中文分词事实标准情感分析SnowNLP装完即用微博语料训练适合评论存储MySQL SQLAlchemy事务可靠答辩好讲展示Vue ECharts词云和趋势图组件成熟2.2 建库建表舆情源表、评论表、情感结果表这套系统的数据库一般拆三张表舆情源表存新闻或商品页面的元信息评论表存每条评论文本情感结果表存打分结果。拆开的好处是评论和源是一对多关系情感结果独立成表后可以单独导出做统计分析。下面是建表SQL字段名和类型我按最常见的设计写你拿到源码包后对比看缺了哪张补哪张。CREATE DATABASE IF NOT EXISTS opinion_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE TABLE news_source ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) NOT NULL, source VARCHAR(100) DEFAULT NULL, url VARCHAR(500) NOT NULL, publish_time DATETIME DEFAULT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_url (url) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE comment_info ( id INT AUTO_INCREMENT PRIMARY KEY, news_id INT NOT NULL, content TEXT NOT NULL, comment_time DATETIME DEFAULT NULL, sentiment_score DECIMAL(3,2) DEFAULT NULL, sentiment_label VARCHAR(10) DEFAULT neutral, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_news_id (news_id), CONSTRAINT fk_news FOREIGN KEY (news_id) REFERENCES news_source(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段设计有几个细节值得注意。url建唯一索引是因为爬虫重复运行时同样的文章不能插两遍配合INSERT IGNORE可以实现幂等写入。sentiment_score用DECIMAL(3,2)而不是FLOAT是因为情感分数范围在-1到1之间定点数在文档里更好解释也避免浮点误差。comment_info里的news_id建了外键和索引统计“某文章的平均情感分”这类SQL就能走索引不拖慢接口响应。字符集用utf8mb4而不是utf8因为用户评论里可能带emojiutf8mb4才能存下四字节字符。另外注意comment_info表里没有显式写comment_count字段因为评论数量可以随时用COUNT(*)算出来。如果源码包的表结构里有这个字段它多半是冗余设计用于列表页快速展示记得在说明文档里解释一句“该字段为冗余字段由定时任务更新”不然答辩时老师问起来你会愣住。2.3 连接池与字符集SQLAlchemy连接串的两个必修参数源码包里连接MySQL的代码一般长这样但很多人直接复制下来就踩坑。问题不出在账号密码而出在没写charset和连接池参数。from sqlalchemy import create_engine engine create_engine( mysqlpymysql://opinion_user:password127.0.0.1:3306/opinion_db?charsetutf8mb4, pool_size5, pool_recycle3600, pool_pre_pingTrue, echoFalse )这段配置里有两个参数是你的后悔药。pool_recycle3600表示连接超过3600秒会被回收重建这直接对治MySQL默认的wait_timeout——MySQL服务器空闲8小时会断开连接如果你程序里的连接池不回收第二天再来请求就会报InterfaceError页面白屏。pool_pre_pingTrue是每次从池里取连接时先探活断掉的连接直接扔掉换新的代价是每次请求多一次极轻量的ping换来的是稳定性。charsetutf8mb4写在连接串里能保证读出来和写进去的中文不乱码这个等第5章具体排查时还会再碰见。提示不要把root账号写死在代码里。常见做法是单独建一个opinion_user账号只授opinion_db库的权限服务器部署时用环境变量注入密码。这样就算代码泄露数据库也不至于裸奔。3. 舆情数据采集与清洗爬虫、jieba与入库的完整代码3.1 用requestsBeautifulSoup抓评论限速与重试采集段是整个系统的数据源头。常见做法是用requests抓页面再用BeautifulSoup解析HTML拿评论。这里我不讨论绕过复杂反爬的骚操作那是另一个话题且容易踩线正规做法是抓那些公开可见、无需登录的静态页面。下面这段代码是抓取评论列表的最小可用版本我按通用逻辑写你换成自己的目标页面和选择器就能跑。import time import random import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 } def fetch_comments(page_url, max_retries3): for attempt in range(max_retries): try: resp requests.get(page_url, headersHEADERS, timeout(5, 10)) if resp.status_code ! 200: print(fHTTP {resp.status_code}, retry {attempt 1}) time.sleep(2) continue soup BeautifulSoup(resp.text, html.parser) items soup.select(div.comment-item p.comment-content) return [item.get_text(stripTrue) for item in items] except requests.RequestException as e: print(fRequest error: {e}) time.sleep(2) return []这段代码有三个参数值得调。timeout(5, 10)分别指连接超时5秒、读取超时10秒不设超时的话某个页面卡住会让整个爬虫进程挂起。重试次数max_retries建议设3超过3次直接放弃这条页面因为舆情采集追求的是覆盖面单条页面失败不影响整体。UA字符串要改成你自己浏览器的很多页面会拒绝默认的python-requests标识。代码里我加了time.sleep(2)兜底实际跑的时候更推荐随机延时。time.sleep(random.uniform(0.5, 1.5))随机延时的作用是避免请求间隔过于规律而被限流。你在说明书里写“本系统采集时采用随机延时降低对目标站点的访问压力”这句话在答辩时很加分说明你考虑过礼貌性问题。3.2 清洗文本并用jieba分词去HTML标签、去停用词、加自定义词典抓回来的评论不能直接做情感分析里面全是换行符、HTML实体和表情符号。清洗的目标是只留下中文、数字和少量标点。分词的目的是把评论切成有意义的词方便后面做词频统计。下面是清洗和分词一起处理的代码。import re import jieba STOP_WORDS set() with open(stopwords.txt, encodingutf-8) as f: for line in f: STOP_WORDS.add(line.strip()) def clean_text(raw_text): text re.sub(r[^], , raw_text) # 去HTML标签 text re.sub(r[a-zA-Z];, , text) # 去HTML实体 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9], , text) # 只留中文英文数字 return text.strip() def segment(text): words jieba.cut(text) result [] for word in words: w word.strip() if len(w) 2: # 过滤单字 continue if w in STOP_WORDS: # 过滤停用词 continue if not re.search(r[\u4e00-\u9fa5], w): # 过滤纯数字/英文碎片 continue result.append(w) return result这里有个在中文舆情处理时特别实际的点jieba默认词典对网络新词和品牌词切分不准。比如“骁龙”会被切成“骁”和“龙”情感分析拿这种词做特征意义不大。解法是在项目里放一个自定义词典文件dict.txt一行一个词然后在程序启动时加载。jieba.load_userdict(dict.txt)dict.txt里建议放三类词品牌词、产品系列名、网络热词。每行一个词可以带词频和词性不写也行。这个文件是你在文档里可以重点说明的优化点——“系统内置自定义词典可扩展领域词”老师一听就知道你理解分词器的工作原理。3.3 批量写入MySQLexecutemany与去重策略清洗后的评论要落库。最直观的写法是一条一条INSERT但在评论量上千条时性能差得明显。正确姿势是使用executemany批量插入配合INSERT IGNORE和url唯一索引做去重。from pymysql import connect def insert_comments(conn, comments): sql INSERT IGNORE INTO comment_info (news_id, content, comment_time) VALUES (%s, %s, %s) batch_size 500 for i in range(0, len(comments), batch_size): batch comments[i:i batch_size] with conn.cursor() as cur: cur.executemany(sql, batch) conn.commit() print(finserted batch, size{len(batch)})批量大小batch_size在200到500之间性价比最高太小退化为逐条插入太大容易超过MySQL的max_allowed_packet限制。INSERT IGNORE依赖comment_info表里news_source表的url唯一键吗不是它依赖comment_info本身的业务主键或唯一键——如果一张表没有唯一键IGNORE就没有去重依据。所以设计表时务必给“能唯一标识一条评论”的字段建UNIQUE KEY比如(news_id, comment_time, content前若干字符)的组合唯一键。4. 情感倾向计算SnowNLP调参与结果落库4.1 为什么先选SnowNLP而不是BERT情感分析是这套系统最像“黑匣子”的部分。市面上主流方案有三档词典法、SnowNLP、BERT。词典法是自己维护正负词表简单透明但漏掉语境比如“这也太刑了”这种反讽它完全无能为力。BERT准确率高但要标注语料、要GPU训练一个毕设周期根本玩不转。SnowNLP恰好卡在中间它自带基于电商和微博语料的训练模型装完就能用一句代码出分数。from snownlp import SnowNLP text 续航完全不行用半天就关机 score SnowNLP(text).sentiments print(score) # 0.27 左右越接近0越负面需要注意的是SnowNLP输出的是0到1之间的概率值越接近1越正面不是对称的-1到1。这一点在第5章排查时经常会再踩一遍有人拿0.5当分界线结果发现“太赞了”得分很高但“很赞”却只有0.55然后就开始怀疑模型坏了。其实模型没坏是阈值需要按业务重标定。4.2 自定义语料再训练把阈值和业务对齐如果你拿默认的SnowNLP跑新闻评论会发现结果勉强能用但跑某个垂直领域比如数码产品评论准确率可能只有六成。原因很简单SnowNLP内置语料是多年前的微博里面没有“发热严重”“充电慢”这类现代数码黑话。解法是收集你自己的正负语料重训情感分类器。from snownlp import sentiment # neg.txt 每行一条负面评论pos.txt 每行一条正面评论 sentiment.train(neg.txt, pos.txt) sentiment.save(sentiment.marshal)训练语料规模建议正负各500条起步1000条效果就比较稳定。语料格式是一行一条不要带表头。这里有个血泪经验正负语料一定要均衡我见过有人拿800条负面、200条正面去训结果所有文本都倾向判负阈值怎么调都拉不回来。训练完的sentiment.marshal文件要放在主程序能读到的路径通常在项目根目录或model/目录然后在代码里替换默认路径。阈值怎么设也值得展开。默认0.5是模型的先验分布但舆情预警场景一般不用0.5而是分三档分数范围标签业务含义score 0.6positive正面舆情不预警0.4 score 0.6neutral中性持续观察score 0.4negative负面需关注def map_label(score): if score 0.6: return positive elif score 0.4: return negative return neutral把阈值从0.5换成0.6/0.4之后中性区的评论不再被强行归类预警准确率反而更高。这一步建议写进说明文档的“参数调优”章节属于你比默认Demo多做的一点增量。4.3 热词TopN与ECharts数据接口情感分只有配上看得到的词云才有冲击力。词频统计的代码不难但要注意过滤策略如果不过滤“我们”“这个”“还是”这类无意义词词云里全是虚词答辩时很尴尬。在3.2节我们已经准备了停用词表这里直接复用即可。from collections import Counter def top_keywords(segmented_comments, top_n50): counter Counter() for words in segmented_comments: counter.update(words) return counter.most_common(top_n)Flask接口把这组词返回给前端词云组件时推荐结构是下面这样ECharts的wordCloud直接吃这个格式app.route(/api/hotwords) def hotwords(): words, counts top_keywords(all_segments) return {words: words, counts: counts}top_n设50就够了词云图显示太多词会糊成一团。如果你想让热词更有说服力可以换TF-IDF而不是纯词频但要额外引入sklearn接口响应会慢一些。纯词频在演示场景足够文档里写清楚“基于词频统计未做TF-IDF加权”即可。5. 前后端与MySQL联调部署6个必避的坑与排查路径5.1 后端接口与前端跨域配置前后端分离是这套系统的标配形态后端跑5000端口前端Vue开发服务器跑8080端口。浏览器会拦截跨端口请求报CORS错误。解法是在Flask端统一加上跨域支持。from flask import Flask, jsonify from flask_cors import CORS app Flask(__name__) CORS(app, resources{r/api/*: {origins: [http://localhost:8080]}})CORS配置里要写明允许的来源origin。只在开发时需要放开跨域部署上线后前后端通常由同一个Nginx提供服务同源就不需要CORS了。排查时先打开浏览器Network面板如果看到红色报错里带CORS字样先看后端有没有加CORS头如果返回的是404问题在前端请求路径先确认前端的axios请求有没有写错/api前缀。5.2 后端连库的三种写法与参数坑后端读数据库常见三种写法直接pymysql、用SQLAlchemy、用Flask-SQLAlchemy插件封装的db对象。源码包里一般用第二种或第三种核心就是我们在2.3节写的create_engine连接串。但部署到服务器后你会发现本机能连、服务器连不上问题多半出在三处。第一处是host写成了127.0.0.1。服务器上MySQL和Flask在同一台机器没问题如果是分开的机器必须把host改成MySQL所在机器的内网IP。第二处是MySQL默认只监听127.0.0.1需要在my.cnf里把bind-address改成0.0.0.0再重启。第三处是MySQL 8的默认认证插件是caching_sha2_password老版本pymysql连不上报Authentication plugin错误。解决办法是升级pymysql或者给程序用的账号指定老式认证。CREATE USER opinion_user% IDENTIFIED WITH mysql_native_password BY your_password; GRANT ALL PRIVILEGES ON opinion_db.* TO opinion_user%; FLUSH PRIVILEGES;5.3 部署gunicorn跑后端Nginx托前端静态页本机能跑通后部署是另一道坎。很多人照着一些Java项目的习惯往Tomcat里塞Python代码方向就错了。Python后端不用容器服务器直接用gunicorn进程启动。pip install gunicorn nohup gunicorn -w 2 -b 0.0.0.0:5000 app:app --timeout 60 app.log 21 -w 2表示开2个worker进程舆情系统这种低并发场景2个够用多了反而吃内存。-b 0.0.0.0:5000绑定所有网卡这样才能被外部访问。app:app指app.py文件里的app实例。--timeout 60是给接口预留的响应时间情感分析加词频统计首次运行可能要几秒。nohup和保证关掉终端后进程不退出日志写到app.log。前端构建产物是纯静态文件Nginx配置里把前端dist目录指到根路径把/api开头的请求转发到5000端口即可。这一步不涉及反向代理的花哨玩法保持简单。5.4 联调最常踩的6个坑现象、原因、解决我按出现频率排一排这些翻车点几乎每个来问我的朋友都遇到过。现象后端启动报 (2003, Cant connect to MySQL server on 127.0.0.1)。 原因MySQL服务没启动或者端口不是3306或者账号密码错。 解决先netstat -an | grep 3306确认端口监听再在Navicat或MySQL Workbench里用同一套账号试连能连上说明是程序问题连不上说明是MySQL侧问题。Linux服务器上还要排查防火墙和bind-address。现象命令行敲mysql能进程序连不上报error 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock。 原因MySQL客户端默认走socket文件而程序可能在不同环境里找不到该socket。 解决连接串里明确写host127.0.0.1强制走TCP而不是依赖socket默认路径macOS上先确认brew services list里MySQL服务是否在跑。现象pymysql报Authentication plugin caching_sha2_password cannot be loaded。 原因MySQL 8默认认证插件是caching_sha2_password而pymysql老版本不认识。 解决pip install -U pymysql升级到新版或者执行上面5.2节那条SQL给程序账号指定mysql_native_password。现象MySQL里存入中文后显示问号或乱码。 原因库、表、连接串三层中某一层不是utf8mb4。 解决ALTER DATABASE opinion_db CHARACTER SET utf8mb4; 再把表也ALTER一遍连接串务必带?charsetutf8mb4。三层全改完一般就好了。现象前端能拿到后端JSON但ECharts图显示空白。 原因JSON字段名和前端代码里取的字段名对不上常见是后端返回snake_case前端却在取camelCase。 解决在浏览器Network里找到响应数据CtrlF搜前端要的字段名统一按后端定义为准修改前端。现象爬虫跑完睡一觉第二天请求接口报InterfaceError (0, )。 原因MySQL的wait_timeout默认8小时空闲连接被服务端断开连接池里的旧连接失效。 解决加pool_recycle3600和pool_pre_pingTrue这是2.3节强调过的配置属于典型的“没看文档提前踩坑”。提示判断前后端Bug时先固定一端。前端页面报错先打开Network看请求到底发出去了没有后端接口异常先用curl http://127.0.0.1:5000/api/xxx直接测绕过前端定位问题。别两头一起猜那是白费时间。6. 进阶验证把情感分析准确率从毛估到可交代6.1 用留出集算出能写进文档的准确率很多人跑完Demo文档里写“情感分析准确率较高”这种话答辩时一问就露馅。正确做法是人工标注100到200条评论跑一遍模型对比算准确率。import random from sklearn.metrics import classification_report # labels: 0负面 1中性 2正面 truth [0, 1, 2, 0, 2, ...] # 人工标注 pred [0, 1, 1, 1, 2, ...] # 模型预测 target_names [negative, neutral, positive] print(classification_report(truth, pred, target_namestarget_names))你会得到每个类别的精确率和召回率。常见结果是负面召回率低因为负面评论常带反讽和省略语。如果你测出来负面召回率低于60%回去补训练语料而不是调阈值——阈值只改变分类边界改变不了模型对语义的理解。我把这步看作整个项目最值的半小时它能直接变成说明书里的一章“系统测试”。6.2 把阈值升级成舆情预警分级按4.2节的0.6/0.4阈值把情感分映射成红橙黄三级预警这就是从“能算分”到“能用”的跨越。接口里返回的不只是sentiment_score还带上label和预警级别前端页面按级别变色。这块在说明书里对应“舆情预警模块”属于实现简单但展示效果很好的功能每年答辩老师都吃这套。6.3 是否值得从SnowNLP换到BERT我的习惯是先问三个问题标注语料有没有超过5000条、有没有GPU或云端推理服务、项目周期还剩几周。三个答案都是否就用SnowNLP重训版本它能交差且你讲得清楚原理真要换也是先把现有数据链路跑稳再单独替换分析模块——因为采集、清洗、存储、展示四段代码全部复用只有情感打分那一行换掉。我自己做这类项目时最后一定会拿人工标注的语料做一次盲测这比调参更能说服自己“这套代码值得交出去”。希望帮到你。本文还有配套的精品资源点击获取 Python舆情分析系统搭建：从爬虫采集到情感分析的全链路实战
简介这是一套基于Python构建的网络舆情分析系统完整源代码项目面向毕业设计、课程设计或舆情分析初学者帮助快速掌握前后端分离开发与舆情数据处理流程。系统覆盖言论采集、情感判断、饼状统计图可视化、用户密码维护及管理员用户管理等功能采用Python 3.6.8与MySQL 5.7开发内置数据库脚本和详细部署文档便于直接运行或二次开发。压缩包共289个文件包含42个Python后端源码、34个前端JavaScript脚本、15个CSS样式、12个HTML页面以及大量GIF演示图、JPG截图、SQL脚本和说明文档整体约83.39MB结构清晰可按模块对照学习。配套的说明文档、论文及演示资源能直观展示系统运行效果帮助理解从数据采集到可视化呈现的完整链路。已有一百人学习下载适合需要快速搭建舆情分析原型或完成课程设计的学生参考。1. 一套能交差的Python舆情分析系统先看它到底解决什么拿到“基于python的网络舆情分析系统源代码完整前后端mysql说明文档LW.zip”这类包的同学多数不是来研究自然语言处理的而是要在两周内交一份能演示、能答辩的毕设或课设。但根据我帮人跑通这类项目的经验真正拦住你的从来不是那几千行代码而是环境Python版本、MySQL能不能连、前端请求有没有打到后端80%的翻车都发生在这三件事上跟算法关系不大。这套系统的价值在于把一条完整的舆情数据链路摆在你面前爬虫采评论、清洗分词、情感打分、结果入MySQL、后端出接口、前端画图表。它适合两类人一是做毕业设计的学生二是想快速搭一个舆情监测Demo给团队看效果的开发者。LW指项目自带的论文文档也就是说代码结构、图表、结论最好能和论文里的系统设计章节一一对上这决定了你后面改代码的边界。2. 拆系统架构与MySQL数据模型建表脚本和关键字段2.1 五段式数据链路采集、清洗、分析、存储、展示我先说这类舆情系统最常见的组织方式因为你要改代码前得先知道每一段在哪。整套系统按数据流向分成五段爬虫负责从新闻、微博、电商评论等渠道抓文本清洗段去掉HTML标签、噪声字符和停用词分析段做情感打分和热词统计MySQL存清洗后的文本和计算结果Flask后端把数据包装成JSON接口Vue前端用ECharts画趋势图和词云。这五段在源码包里通常对应五个目录命名可能是spider/、clean/、analysis/、api/、web/也可能叫别的但结构大致如此。为什么这套选型是“标准答案”因为Flask比Django轻路由写法直观而且和Python数据分析栈天然亲和MySQL是文档里最好交代的存储方案Vue加ECharts能在一页里展示表格、饼图、词云三种图答辩时视觉效果够用。我建议你拿到包后先别急着跑按这个五段结构把代码目录过一遍在说明书上标注每一段对应的文件路径后面改Bug会快很多。模块常见选型选型理由采集requests BeautifulSoup轻量、上手快、适合静态页面清洗re jieba中文分词事实标准情感分析SnowNLP装完即用微博语料训练适合评论存储MySQL SQLAlchemy事务可靠答辩好讲展示Vue ECharts词云和趋势图组件成熟2.2 建库建表舆情源表、评论表、情感结果表这套系统的数据库一般拆三张表舆情源表存新闻或商品页面的元信息评论表存每条评论文本情感结果表存打分结果。拆开的好处是评论和源是一对多关系情感结果独立成表后可以单独导出做统计分析。下面是建表SQL字段名和类型我按最常见的设计写你拿到源码包后对比看缺了哪张补哪张。CREATE DATABASE IF NOT EXISTS opinion_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE TABLE news_source ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) NOT NULL, source VARCHAR(100) DEFAULT NULL, url VARCHAR(500) NOT NULL, publish_time DATETIME DEFAULT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_url (url) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE comment_info ( id INT AUTO_INCREMENT PRIMARY KEY, news_id INT NOT NULL, content TEXT NOT NULL, comment_time DATETIME DEFAULT NULL, sentiment_score DECIMAL(3,2) DEFAULT NULL, sentiment_label VARCHAR(10) DEFAULT neutral, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_news_id (news_id), CONSTRAINT fk_news FOREIGN KEY (news_id) REFERENCES news_source(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段设计有几个细节值得注意。url建唯一索引是因为爬虫重复运行时同样的文章不能插两遍配合INSERT IGNORE可以实现幂等写入。sentiment_score用DECIMAL(3,2)而不是FLOAT是因为情感分数范围在-1到1之间定点数在文档里更好解释也避免浮点误差。comment_info里的news_id建了外键和索引统计“某文章的平均情感分”这类SQL就能走索引不拖慢接口响应。字符集用utf8mb4而不是utf8因为用户评论里可能带emojiutf8mb4才能存下四字节字符。另外注意comment_info表里没有显式写comment_count字段因为评论数量可以随时用COUNT(*)算出来。如果源码包的表结构里有这个字段它多半是冗余设计用于列表页快速展示记得在说明文档里解释一句“该字段为冗余字段由定时任务更新”不然答辩时老师问起来你会愣住。2.3 连接池与字符集SQLAlchemy连接串的两个必修参数源码包里连接MySQL的代码一般长这样但很多人直接复制下来就踩坑。问题不出在账号密码而出在没写charset和连接池参数。from sqlalchemy import create_engine engine create_engine( mysqlpymysql://opinion_user:password127.0.0.1:3306/opinion_db?charsetutf8mb4, pool_size5, pool_recycle3600, pool_pre_pingTrue, echoFalse )这段配置里有两个参数是你的后悔药。pool_recycle3600表示连接超过3600秒会被回收重建这直接对治MySQL默认的wait_timeout——MySQL服务器空闲8小时会断开连接如果你程序里的连接池不回收第二天再来请求就会报InterfaceError页面白屏。pool_pre_pingTrue是每次从池里取连接时先探活断掉的连接直接扔掉换新的代价是每次请求多一次极轻量的ping换来的是稳定性。charsetutf8mb4写在连接串里能保证读出来和写进去的中文不乱码这个等第5章具体排查时还会再碰见。提示不要把root账号写死在代码里。常见做法是单独建一个opinion_user账号只授opinion_db库的权限服务器部署时用环境变量注入密码。这样就算代码泄露数据库也不至于裸奔。3. 舆情数据采集与清洗爬虫、jieba与入库的完整代码3.1 用requestsBeautifulSoup抓评论限速与重试采集段是整个系统的数据源头。常见做法是用requests抓页面再用BeautifulSoup解析HTML拿评论。这里我不讨论绕过复杂反爬的骚操作那是另一个话题且容易踩线正规做法是抓那些公开可见、无需登录的静态页面。下面这段代码是抓取评论列表的最小可用版本我按通用逻辑写你换成自己的目标页面和选择器就能跑。import time import random import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 } def fetch_comments(page_url, max_retries3): for attempt in range(max_retries): try: resp requests.get(page_url, headersHEADERS, timeout(5, 10)) if resp.status_code ! 200: print(fHTTP {resp.status_code}, retry {attempt 1}) time.sleep(2) continue soup BeautifulSoup(resp.text, html.parser) items soup.select(div.comment-item p.comment-content) return [item.get_text(stripTrue) for item in items] except requests.RequestException as e: print(fRequest error: {e}) time.sleep(2) return []这段代码有三个参数值得调。timeout(5, 10)分别指连接超时5秒、读取超时10秒不设超时的话某个页面卡住会让整个爬虫进程挂起。重试次数max_retries建议设3超过3次直接放弃这条页面因为舆情采集追求的是覆盖面单条页面失败不影响整体。UA字符串要改成你自己浏览器的很多页面会拒绝默认的python-requests标识。代码里我加了time.sleep(2)兜底实际跑的时候更推荐随机延时。time.sleep(random.uniform(0.5, 1.5))随机延时的作用是避免请求间隔过于规律而被限流。你在说明书里写“本系统采集时采用随机延时降低对目标站点的访问压力”这句话在答辩时很加分说明你考虑过礼貌性问题。3.2 清洗文本并用jieba分词去HTML标签、去停用词、加自定义词典抓回来的评论不能直接做情感分析里面全是换行符、HTML实体和表情符号。清洗的目标是只留下中文、数字和少量标点。分词的目的是把评论切成有意义的词方便后面做词频统计。下面是清洗和分词一起处理的代码。import re import jieba STOP_WORDS set() with open(stopwords.txt, encodingutf-8) as f: for line in f: STOP_WORDS.add(line.strip()) def clean_text(raw_text): text re.sub(r[^], , raw_text) # 去HTML标签 text re.sub(r[a-zA-Z];, , text) # 去HTML实体 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9], , text) # 只留中文英文数字 return text.strip() def segment(text): words jieba.cut(text) result [] for word in words: w word.strip() if len(w) 2: # 过滤单字 continue if w in STOP_WORDS: # 过滤停用词 continue if not re.search(r[\u4e00-\u9fa5], w): # 过滤纯数字/英文碎片 continue result.append(w) return result这里有个在中文舆情处理时特别实际的点jieba默认词典对网络新词和品牌词切分不准。比如“骁龙”会被切成“骁”和“龙”情感分析拿这种词做特征意义不大。解法是在项目里放一个自定义词典文件dict.txt一行一个词然后在程序启动时加载。jieba.load_userdict(dict.txt)dict.txt里建议放三类词品牌词、产品系列名、网络热词。每行一个词可以带词频和词性不写也行。这个文件是你在文档里可以重点说明的优化点——“系统内置自定义词典可扩展领域词”老师一听就知道你理解分词器的工作原理。3.3 批量写入MySQLexecutemany与去重策略清洗后的评论要落库。最直观的写法是一条一条INSERT但在评论量上千条时性能差得明显。正确姿势是使用executemany批量插入配合INSERT IGNORE和url唯一索引做去重。from pymysql import connect def insert_comments(conn, comments): sql INSERT IGNORE INTO comment_info (news_id, content, comment_time) VALUES (%s, %s, %s) batch_size 500 for i in range(0, len(comments), batch_size): batch comments[i:i batch_size] with conn.cursor() as cur: cur.executemany(sql, batch) conn.commit() print(finserted batch, size{len(batch)})批量大小batch_size在200到500之间性价比最高太小退化为逐条插入太大容易超过MySQL的max_allowed_packet限制。INSERT IGNORE依赖comment_info表里news_source表的url唯一键吗不是它依赖comment_info本身的业务主键或唯一键——如果一张表没有唯一键IGNORE就没有去重依据。所以设计表时务必给“能唯一标识一条评论”的字段建UNIQUE KEY比如(news_id, comment_time, content前若干字符)的组合唯一键。4. 情感倾向计算SnowNLP调参与结果落库4.1 为什么先选SnowNLP而不是BERT情感分析是这套系统最像“黑匣子”的部分。市面上主流方案有三档词典法、SnowNLP、BERT。词典法是自己维护正负词表简单透明但漏掉语境比如“这也太刑了”这种反讽它完全无能为力。BERT准确率高但要标注语料、要GPU训练一个毕设周期根本玩不转。SnowNLP恰好卡在中间它自带基于电商和微博语料的训练模型装完就能用一句代码出分数。from snownlp import SnowNLP text 续航完全不行用半天就关机 score SnowNLP(text).sentiments print(score) # 0.27 左右越接近0越负面需要注意的是SnowNLP输出的是0到1之间的概率值越接近1越正面不是对称的-1到1。这一点在第5章排查时经常会再踩一遍有人拿0.5当分界线结果发现“太赞了”得分很高但“很赞”却只有0.55然后就开始怀疑模型坏了。其实模型没坏是阈值需要按业务重标定。4.2 自定义语料再训练把阈值和业务对齐如果你拿默认的SnowNLP跑新闻评论会发现结果勉强能用但跑某个垂直领域比如数码产品评论准确率可能只有六成。原因很简单SnowNLP内置语料是多年前的微博里面没有“发热严重”“充电慢”这类现代数码黑话。解法是收集你自己的正负语料重训情感分类器。from snownlp import sentiment # neg.txt 每行一条负面评论pos.txt 每行一条正面评论 sentiment.train(neg.txt, pos.txt) sentiment.save(sentiment.marshal)训练语料规模建议正负各500条起步1000条效果就比较稳定。语料格式是一行一条不要带表头。这里有个血泪经验正负语料一定要均衡我见过有人拿800条负面、200条正面去训结果所有文本都倾向判负阈值怎么调都拉不回来。训练完的sentiment.marshal文件要放在主程序能读到的路径通常在项目根目录或model/目录然后在代码里替换默认路径。阈值怎么设也值得展开。默认0.5是模型的先验分布但舆情预警场景一般不用0.5而是分三档分数范围标签业务含义score 0.6positive正面舆情不预警0.4 score 0.6neutral中性持续观察score 0.4negative负面需关注def map_label(score): if score 0.6: return positive elif score 0.4: return negative return neutral把阈值从0.5换成0.6/0.4之后中性区的评论不再被强行归类预警准确率反而更高。这一步建议写进说明文档的“参数调优”章节属于你比默认Demo多做的一点增量。4.3 热词TopN与ECharts数据接口情感分只有配上看得到的词云才有冲击力。词频统计的代码不难但要注意过滤策略如果不过滤“我们”“这个”“还是”这类无意义词词云里全是虚词答辩时很尴尬。在3.2节我们已经准备了停用词表这里直接复用即可。from collections import Counter def top_keywords(segmented_comments, top_n50): counter Counter() for words in segmented_comments: counter.update(words) return counter.most_common(top_n)Flask接口把这组词返回给前端词云组件时推荐结构是下面这样ECharts的wordCloud直接吃这个格式app.route(/api/hotwords) def hotwords(): words, counts top_keywords(all_segments) return {words: words, counts: counts}top_n设50就够了词云图显示太多词会糊成一团。如果你想让热词更有说服力可以换TF-IDF而不是纯词频但要额外引入sklearn接口响应会慢一些。纯词频在演示场景足够文档里写清楚“基于词频统计未做TF-IDF加权”即可。5. 前后端与MySQL联调部署6个必避的坑与排查路径5.1 后端接口与前端跨域配置前后端分离是这套系统的标配形态后端跑5000端口前端Vue开发服务器跑8080端口。浏览器会拦截跨端口请求报CORS错误。解法是在Flask端统一加上跨域支持。from flask import Flask, jsonify from flask_cors import CORS app Flask(__name__) CORS(app, resources{r/api/*: {origins: [http://localhost:8080]}})CORS配置里要写明允许的来源origin。只在开发时需要放开跨域部署上线后前后端通常由同一个Nginx提供服务同源就不需要CORS了。排查时先打开浏览器Network面板如果看到红色报错里带CORS字样先看后端有没有加CORS头如果返回的是404问题在前端请求路径先确认前端的axios请求有没有写错/api前缀。5.2 后端连库的三种写法与参数坑后端读数据库常见三种写法直接pymysql、用SQLAlchemy、用Flask-SQLAlchemy插件封装的db对象。源码包里一般用第二种或第三种核心就是我们在2.3节写的create_engine连接串。但部署到服务器后你会发现本机能连、服务器连不上问题多半出在三处。第一处是host写成了127.0.0.1。服务器上MySQL和Flask在同一台机器没问题如果是分开的机器必须把host改成MySQL所在机器的内网IP。第二处是MySQL默认只监听127.0.0.1需要在my.cnf里把bind-address改成0.0.0.0再重启。第三处是MySQL 8的默认认证插件是caching_sha2_password老版本pymysql连不上报Authentication plugin错误。解决办法是升级pymysql或者给程序用的账号指定老式认证。CREATE USER opinion_user% IDENTIFIED WITH mysql_native_password BY your_password; GRANT ALL PRIVILEGES ON opinion_db.* TO opinion_user%; FLUSH PRIVILEGES;5.3 部署gunicorn跑后端Nginx托前端静态页本机能跑通后部署是另一道坎。很多人照着一些Java项目的习惯往Tomcat里塞Python代码方向就错了。Python后端不用容器服务器直接用gunicorn进程启动。pip install gunicorn nohup gunicorn -w 2 -b 0.0.0.0:5000 app:app --timeout 60 app.log 21 -w 2表示开2个worker进程舆情系统这种低并发场景2个够用多了反而吃内存。-b 0.0.0.0:5000绑定所有网卡这样才能被外部访问。app:app指app.py文件里的app实例。--timeout 60是给接口预留的响应时间情感分析加词频统计首次运行可能要几秒。nohup和保证关掉终端后进程不退出日志写到app.log。前端构建产物是纯静态文件Nginx配置里把前端dist目录指到根路径把/api开头的请求转发到5000端口即可。这一步不涉及反向代理的花哨玩法保持简单。5.4 联调最常踩的6个坑现象、原因、解决我按出现频率排一排这些翻车点几乎每个来问我的朋友都遇到过。现象后端启动报 (2003, Cant connect to MySQL server on 127.0.0.1)。 原因MySQL服务没启动或者端口不是3306或者账号密码错。 解决先netstat -an | grep 3306确认端口监听再在Navicat或MySQL Workbench里用同一套账号试连能连上说明是程序问题连不上说明是MySQL侧问题。Linux服务器上还要排查防火墙和bind-address。现象命令行敲mysql能进程序连不上报error 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock。 原因MySQL客户端默认走socket文件而程序可能在不同环境里找不到该socket。 解决连接串里明确写host127.0.0.1强制走TCP而不是依赖socket默认路径macOS上先确认brew services list里MySQL服务是否在跑。现象pymysql报Authentication plugin caching_sha2_password cannot be loaded。 原因MySQL 8默认认证插件是caching_sha2_password而pymysql老版本不认识。 解决pip install -U pymysql升级到新版或者执行上面5.2节那条SQL给程序账号指定mysql_native_password。现象MySQL里存入中文后显示问号或乱码。 原因库、表、连接串三层中某一层不是utf8mb4。 解决ALTER DATABASE opinion_db CHARACTER SET utf8mb4; 再把表也ALTER一遍连接串务必带?charsetutf8mb4。三层全改完一般就好了。现象前端能拿到后端JSON但ECharts图显示空白。 原因JSON字段名和前端代码里取的字段名对不上常见是后端返回snake_case前端却在取camelCase。 解决在浏览器Network里找到响应数据CtrlF搜前端要的字段名统一按后端定义为准修改前端。现象爬虫跑完睡一觉第二天请求接口报InterfaceError (0, )。 原因MySQL的wait_timeout默认8小时空闲连接被服务端断开连接池里的旧连接失效。 解决加pool_recycle3600和pool_pre_pingTrue这是2.3节强调过的配置属于典型的“没看文档提前踩坑”。提示判断前后端Bug时先固定一端。前端页面报错先打开Network看请求到底发出去了没有后端接口异常先用curl http://127.0.0.1:5000/api/xxx直接测绕过前端定位问题。别两头一起猜那是白费时间。6. 进阶验证把情感分析准确率从毛估到可交代6.1 用留出集算出能写进文档的准确率很多人跑完Demo文档里写“情感分析准确率较高”这种话答辩时一问就露馅。正确做法是人工标注100到200条评论跑一遍模型对比算准确率。import random from sklearn.metrics import classification_report # labels: 0负面 1中性 2正面 truth [0, 1, 2, 0, 2, ...] # 人工标注 pred [0, 1, 1, 1, 2, ...] # 模型预测 target_names [negative, neutral, positive] print(classification_report(truth, pred, target_namestarget_names))你会得到每个类别的精确率和召回率。常见结果是负面召回率低因为负面评论常带反讽和省略语。如果你测出来负面召回率低于60%回去补训练语料而不是调阈值——阈值只改变分类边界改变不了模型对语义的理解。我把这步看作整个项目最值的半小时它能直接变成说明书里的一章“系统测试”。6.2 把阈值升级成舆情预警分级按4.2节的0.6/0.4阈值把情感分映射成红橙黄三级预警这就是从“能算分”到“能用”的跨越。接口里返回的不只是sentiment_score还带上label和预警级别前端页面按级别变色。这块在说明书里对应“舆情预警模块”属于实现简单但展示效果很好的功能每年答辩老师都吃这套。6.3 是否值得从SnowNLP换到BERT我的习惯是先问三个问题标注语料有没有超过5000条、有没有GPU或云端推理服务、项目周期还剩几周。三个答案都是否就用SnowNLP重训版本它能交差且你讲得清楚原理真要换也是先把现有数据链路跑稳再单独替换分析模块——因为采集、清洗、存储、展示四段代码全部复用只有情感打分那一行换掉。我自己做这类项目时最后一定会拿人工标注的语料做一次盲测这比调参更能说服自己“这套代码值得交出去”。希望帮到你。本文还有配套的精品资源点击获取