简介这份基于Python的网络舆情分析系统以完整前后端与MySQL数据库呈现面向舆情监控管理人员以及毕业设计、课程设计开发者。系统支持多用户并行使用管理员可管理用户与言论数据通过对各类网络平台言论的情感分析以饼状统计图等方式直观展示舆论分布同时提供密码和个人信息维护功能。压缩包共二百八十九个文件包含四十二个Python源码文件、三十四个JavaScript脚本、十五个CSS样式表以及HTML页面、SQL数据库脚本、说明文档和演示动图等整体大小八十三点三九MB文件类型覆盖系统实现与部署所需的全部环节便于按目录模块对照学习。项目还附带环境配置、数据库搭建、前后端部署等详细文档并给出LW说明文档有助于快速复现系统逻辑与运行流程为二次开发或课设答辩提供扎实参考。已有一百人学习下载适合需要完整项目范例的中高级学习者。1. 基于Python的网络舆情分析系统源码包前后端MySQL的课设项目能直接跑通吗“网络舆情分析系统”听起来是个很庞大的课题但我拆完这套源码之后的第一感受是它的架构非常克制正好卡在毕业设计和课程设计最需要的那个复杂度上。后端Python接收言论数据、做基础的情感倾向判断和数据统计MySQL存用户与言论数据前端基于layui的admin模板做展示登录、注册、言论管理、饼状统计图一条线串下来功能完整但不过度设计。适合三类人正在做Python毕设或课设的学生想在公司内网搭一套简易舆情监测原型的产品或运维人员以及想搞明白前后端分离项目里MySQL数据怎么流动的初学者。从解压目录看你可能会被一堆CSS文件名劝退——layui.css、admin.css、layer.css、laydate.css、login.css。这些其实都是layui后台模板的静态资源真正要琢磨的是它们对应的页面和后端接口。系统限定了多用户共用、但管理员只有一人的结构普通用户负责提交言论、查看统计图表和维护个人密码管理员额外拥有用户增删改权限。这就是我们拆权限表和接口时的主线也是复现这套系统的钥匙。2. 系统拆解舆情数据从采集到饼状图展示的核心链路2.1 访问一条言论前后端到底是怎么分工的这套源码是典型的前后端分离结构。前端页面部署在静态目录下浏览器加载HTML和JS用户操作触发Ajax请求后端Python框架负责接收HTTP请求、处理业务逻辑、读写MySQL最后把JSON数据返回给前端渲染。我习惯先从前端的网络请求反向看后端因为源码里CSS文件太显眼容易让人忽略真正的逻辑都在后端接口里。以发表言论为例用户在页面上输入一段文字前端把内容通过POST请求送到后端接口。后端校验用户身份后把这条言论连同当前用户ID、时间戳写入MySQL的言论表与此同时后端还会调用一个简单的分词与情感判断函数给这条言论打上一个“正面/负面/中性”的标签。这个标签就是后面饼状统计图的数据来源。这里有一个容易被忽略的点舆情分析系统的核心不是页面多好看而是“用户提交的实时言论能不能快速落库并且打上可统计的标签”。LayUI只是把这一过程包装成了表格和图表真正决定系统可用的是接口设计得够不够清晰。常见做法是后端每个接口返回统一的JSON结构比如{code: 0, msg: success, data: {...}}前端拿到这个结构再做渲染前后端各改各的互不干扰。2.2 MySQL表结构与权限模型多用户舆情系统的底层设计这个系统能实现“多用户使用、但只有一个管理员”本质上是数据库表结构在设计上做了角色字段。我从源码包里的SQL文件能推断出三类核心表用户表、言论表、统计相关表。用户表是主表言论表是业务表统计表或视图服务于饼状图。用户表一般长这样id主键自增username唯一索引password存MD5加密值role字段用整数区分管理员和普通用户create_time记录创建时间。管理员只有一个的限制通常通过两种方式实现一种是在初始化SQL里只插入一条管理员数据另一种是注册接口判断当前用户表里管理员数量超过一就拒绝创建。我在实际跑这套源码时观察到的是前者简单直接符合课设项目的定位。言论表的设计则更体现舆情分析的特性。每条言论至少要有「内容、发布人、情感标签、发布时间」四个字段。情感标签字段很关键因为饼状图统计的本质是GROUP BY sentiment如果没有这个字段前端图表就拿不到分组数据。有些版本的源码还会加一个来源字段比如“微博、论坛、评论区”用来做多来源对比但核心表结构不会变。这里我要提醒一个细节很多毕设项目的MySQL表名和字段名是英文注释也是英文或拼音但源码包里的SQL文件往往直接带中文注释。导入数据库时如果字符集不对这些注释全都会变成乱码连带导致运行时查询异常。这个问题我会在后面避坑章节单独展开但你现在就得知道MySQL 5.7下建库时选对字符集比选对字段类型更容易被忽略。2.3 前端LayUI组件与后端JSON接口的对应关系从前端静态文件能看出这套源码用的是LayUI的后台管理模板。admin.css对应后台整体框架login.css对应登录页laydate.css是日期选择器。前端页面和后端接口的对应关系我建议你按照“页面 → 接口 → 功能”三个维度去做一张映射表比逐个文件翻要高效得多。我整理这套源码时是这样对应起来的登录页面调/api/login做身份校验主页的舆情总览调/api/dashboard拿用户数和言论总量言论管理列表调/api/comment/list分页拉取数据饼状统计图调/api/statistics获取各情感标签的数量分布。用户管理模块则调/api/user/list、/api/user/add、/api/user/delete对应增删改查。接口路径请求方式前端对应页面主要功能/api/loginPOSTlogin.html用户登录与角色识别/api/registerPOSTregister.html注册普通用户/api/comment/listGET/POST舆情言论页分页展示言论列表/api/comment/addPOST发布言论入口录入新言论并触发情感分析/api/statisticsGET饼状统计图页汇总情感标签分布/api/user/managePOST用户管理页管理员增删改用户3. 部署跑通指南Python 3.6.8与MySQL 5.7下把系统拉起来3.1 环境准备为什么源码包锁死这个版本组合源码包的说明文档里写得很明确Python 3.6.8、MySQL 5.7、Navicat 11、PyCharm。这套组合看起来老旧但它踩过了那个年代所有能踩的坑反而是最容易在本地复现的配置。Python 3.6.8是3.6系列的稳定版很多经典第三方库在这版下兼容性最好MySQL 5.7则是性能与安装便利性的平衡点比5.5多了更好的JSON支持和utf8mb4默认排序规则又比8.0省去了认证插件变更带来的驱动兼容问题。我考虑到很多读者用的是Windows就按Windows环境来写。安装Python时记得在安装向导第一页勾选“Add Python 3.6 to PATH”这一步如果漏掉后面命令行里敲python会提示找不到命令这个属于新手最常见翻车点。MySQL 5.7建议选自定义安装端口保持默认的3306字符集在配置向导里选utf8mb4这能省掉后面一大半的乱码问题。Navicat 11在这里的角色是纯粹的图形化客户端负责把源码包里的SQL文件导入MySQL。如果你手头只有新版本的Navicat导入操作完全兼容不必刻意找旧版本。PyCharm则只负责打开项目文件、运行后端入口你不需要安装任何额外插件项目自带依赖通常在requirements.txt里。3.2 数据库导入Navicat建库、导入SQL与连接参数配置数据库是整套系统复现的第一步因为后端启动时第一件事就是连接数据库连不上就直接白屏或者报错。我用Navicat导入这套源码的流程是新建连接填127.0.0.1:3306用户名root密码填安装MySQL时设置的那个然后新建数据库库名随意但最好和源码配置文件保持一致最后在新建的库上右键“运行SQL文件”选择源码包中的SQL文件等待执行完成。-- 核心表初始化语句示例源码包SQL文件中的典型结构 CREATE DATABASE IF NOT EXISTS yuqing_db DEFAULT CHARACTER SET utf8mb4; USE yuqing_db; CREATE TABLE sys_user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL COMMENT 登录账号, password VARCHAR(64) NOT NULL COMMENT MD5加密后的密码, role INT DEFAULT 1 COMMENT 角色0管理员1普通用户, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB COMMENT用户表; CREATE TABLE comment_info ( id INT NOT NULL AUTO_INCREMENT COMMENT 言论ID, user_id INT NOT NULL COMMENT 发布用户ID, content TEXT COMMENT 言论内容, sentiment VARCHAR(10) DEFAULT neutral COMMENT 情感标签, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_sentiment (sentiment) ) ENGINEInnoDB COMMENT言论表;这段建表语句里的关键参数值得多说两句。DEFAULT CHARACTER SET utf8mb4决定整个库的字符集utf8mb4理论上兼容所有中文和emoji我的建议是建库时必须保留。role字段用0和1区分管理员和普通用户业务代码里做权限判断时只认数字不认字符串。idx_sentiment这个索引是为饼状图的GROUP BY sentiment查询准备的没有这个索引数据量一大就会慢课设阶段虽然感知不明显但它是这个表设计里体现工程素养的地方。导入完成后打开源码包里的数据库配置文件常见命名有config.py、db.py、settings.py确认连接参数和你的本地环境一致# config.py - 数据库连接配置改为你自己的本地参数 DB_HOST 127.0.0.1 # 本机数据库地址不要改成localhost部分版本会走IPv6解析 DB_PORT 3306 # MySQL 5.7默认端口 DB_USER root DB_PASSWORD 123456 # 安装MySQL时设置的密码必改 DB_NAME yuqing_db # 与Navicat里新建的库名保持一致 DB_CHARSET utf8mb4 # 连接字符集乱码问题百分之八十出在这里3.3 后端启动虚拟环境、依赖安装与入口文件后端项目拿到手第一步永远是装依赖而不是直接运行。源码包如果在设计时规范就会带一个requirements.txt里面列出了Flask/Django、PyMySQL、jieba等第三方库。建议在项目根目录先创建虚拟环境把依赖隔离在项目内部避免和你机器上其他Python项目互相污染。# Windows命令行cd到项目根目录后执行 python -m venv venv venv\Scripts\activate python -m pip install --upgrade pip -i https://pypi.tuna.tsinghua.edu.cn/simple pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple python app.py这段命令每行都有讲究。python -m venv venv创建虚拟环境第一个venv是模块名第二个是文件夹名你可以改成别的但别用中文。激活后命令行前面会出现(venv)前缀说明现在装的包都进虚拟环境了。-i参数指定清华镜像源如果在国内不指定这个装jieba这种包也可能卡很久。最后的python app.py是启动后端看到类似Running on http://127.0.0.1:5000的输出就说明成功了如果报错提示缺module回到上一步把依赖重新装一遍注意看是哪个包没装上。3.4 功能验证从注册到舆情统计的完整路径系统跑起来之后我建议不要直接点饼状图而是走一条最完整的业务路径来验证它真的正常工作。先注册一个新用户观察注册接口是否把数据写进sys_user表用新用户登录在页面上发布几条言论然后回言论列表看能否查询到最后看统计页饼状图是否产生分组数据。这条路径里的每一步都对应前面说的接口注册对应/api/register登录对应/api/login发布言论对应/api/comment/add饼图对应/api/statistics。如果某个环节空白优先去后端的运行日志里找错误而不是猜前端代码。日志里最常见的报错是数据库连接失败、SQL语法错误、JSON序列化出错这三类每类都对应明确的位置。4. 舆情分析核心代码走读情感判断与饼状统计图的实现思路4.1 言论入库接口前端传一句话后端接住并落库舆情系统最基础的动作是把用户言论收集起来。前端拿到用户输入的文本打包成JSON发到后端后端的接口函数接住JSON完成入库。我拆的这套源码里核心接口的写法是这样# app.py - 言论发布与自动分析接口 from flask import Flask, request, jsonify import pymysql, datetime, jieba app Flask(__name__) def get_db(): # 每次请求独立连接用完即关避免长连接被MySQL踢掉 conn pymysql.connect(host127.0.0.1, port3306, userroot, password123456, databaseyuqing_db, charsetutf8mb4) return conn app.route(/api/comment/add, methods[POST]) def add_comment(): user_id request.json.get(user_id) content request.json.get(content, ).strip() if not content: return jsonify({code: 1, msg: 言论内容不能为空}) sentiment analyze_sentiment(content) # 调用情感分析函数 conn get_db() cur conn.cursor() sql INSERT INTO comment_info (user_id, content, sentiment, create_time) VALUES (%s, %s, %s, %s) cur.execute(sql, (user_id, content, sentiment, datetime.datetime.now())) conn.commit() cur.close() conn.close() return jsonify({code: 0, msg: 发布成功, data: {sentiment: sentiment}})这个接口值得一看的是pymysql.connect的写法。charsetutf8mb4同时出现在建表和连接两层缺掉任何一层都可能出现写入正常、读出乱码的诡异现象。SQL用%s占位符而不是字符串拼接是为了防SQL注入这也是我建议你在二次开发时沿用这个习惯的原因。analyze_sentiment函数被埋在执行SQL之前也就是说每条言论入库前就已经被打好了情感标签这个设计让统计接口不需要在查询时现算。4.2 情感倾向判断比想象中简单的分词加词典方案舆情分析在课设项目里不可能上BERT或者深度学习合理做法是结巴分词加情感词典。源码包如果在目录里带了dict/positive.txt和dict/negative.txt就说明用的是这个路线。原理不复杂先对文本分词把分词结果分别跟正面词表、负面词表做匹配命中的词语数量之差决定方向没有命中就是中性。# sentiment.py - 基于词典的情感倾向判断 import jieba def load_words(path): # 读取情感词典每行一个词忽略空行 with open(path, encodingutf-8) as f: return {line.strip() for line in f if line.strip()} POS load_words(dict/positive.txt) # 正面词典 NEG load_words(dict/negative.txt) # 负面词典 def analyze_sentiment(text): words [w for w in jieba.lcut(text) if len(w.strip()) 1] pos_count sum(1 for w in words if w in POS) neg_count sum(1 for w in words if w in NEG) if pos_count neg_count: return positive elif neg_count pos_count: return negative return neutral这个函数的核心参数有两个。一个是词典文件的编码这里强制用utf-8读取如果词典文件本身是GBK编码这里会直接抛异常你需要改成encodinggbk或者用转换工具把词典改成UTF-8格式。另一个是len(w.strip()) 1这个过滤条件它把单个字过滤掉因为单个字比如“好”“坏”没有足够的语境信息容易误判但代价是“厉害”这类双字褒义词会进入判断。对课设系统来说这个精度损失可以接受。4.3 饼状图数据聚合一个接口、一条SQL、一次分组饼状统计图的本质是数据汇总。前端要画饼图时后端给出的数据应该是一个数组每个元素是一个情感类型和它对应的数量。这个接口的实现是整个系统里最简洁的部分因为它完全切中了MySQL的分组统计能力。app.route(/api/statistics, methods[GET]) def get_statistics(): conn get_db() cur conn.cursor() sql SELECT sentiment, COUNT(*) AS cnt FROM comment_info GROUP BY sentiment cur.execute(sql) rows cur.fetchall() data [{name: r[0], value: r[1]} for r in rows] cur.close() conn.close() return jsonify({code: 0, data: data})这里有一个很多新手会忽略的技术点GROUP BY sentiment返回的行如果某类情感在言论表里一条都没有那它不会出现在结果里。这意味着你刚部署完系统言论表为空时/api/statistics返回的数组长度是0前端饼图表现为空白。这不是Bug是数据还没喂进去。验证这个接口最直接的办法是用Navicat往comment_info表里手动插入几条不同sentiment的数据再刷新统计页饼图应该立刻变化。前端拿到这个数组后用ECharts或者LayUI自带的图表模块渲染饼图。图表部分在源码里通常是一个独立的JS文件里面调用了上面这个接口把返回数据映射到ECharts的series.data字段。这里要留意前后端字段名的一致性后端返回的是name和value前端图表组件默认认识的也是这两个字段名如果后端改成label和num前端不修改映射逻辑就画不出来。5. 避坑指南这套源码部署与二次开发中的五个典型问题5.1 现象Python 3.6装依赖时大量报错pymysql安装失败原因新版pymysql在较新的PyPI源里可能要求Python 3.7以上直接pip install会触发版本校验失败。这类问题在Python 3.6.8上特别典型因为很多库的较新版本已经开始放弃对3.6的支持。解决不要盲目升级库版本。最稳的路径是以源码包自带的requirements.txt为准安装时指定版本号比如pip install pymysql0.9.3。如果源码包没给版本号就选一个发布时间和Python 3.6.8接近的旧版本。PyPI源的-i参数用清华镜像能避免部分源服务器对旧版包的CDN支持不完整带来的下载失败。5.2 现象数据库导入成功但页面上的中文全是乱码原因MySQL 5.7的建库语句没有指定utf8mb4或者Navicat导入SQL文件时选择的编码格式与文件实际编码不一致。Windows下国产编辑器默认可能把SQL文件存成GBK而数据库用的是UTF-8导入时Navicat按UTF-8解读GBK文件乱码就产生了。解决用Navicat连接数据库后右键连接属性把数据库连接编码改为UTF-8导入SQL前先观察SQL文件的编码用记事本打开看中文注释是否正常如果不正常就用VS Code等工具转换为UTF-8再导入。建库语句里必须保留DEFAULT CHARACTER SET utf8mb4这是四层编码里最底层的一层。5.3 现象后端启动正常但页面CSS和JS全部加载不出来浏览器控制台报404原因LayUI模板的静态资源是用相对路径引用的比如./layui/css/layui.css。如果前端页面文件和静态资源目录的相对层级被调整过或者后端Flask没有正确挂载static目录请求路径对不上就会出现HTML渲染正常、样式全部丢失的白板页面。解决打开后端代码里静态文件注册的配置确认Flask把static文件夹挂在了根路径下并且前端HTML里引用的路径和后端实际暴露的路径一致。我常用的排查方式是直接复制浏览器控制台里报404的完整URL在后端项目目录里找这个路径对应的真实文件如果找不到就是路径错位改前端引用路径比改后端挂载更省事。5.4 现象系统跑一段时间后突然报数据库连接错误重启后端又恢复正常原因MySQL 5.7默认的wait_timeout是8小时数据库长时间没有请求时会把空闲连接断掉。源码如果用的是每次请求新建连接的方式影响还不大但很多版本为了效率用了连接池池里的旧连接没被检测出来下一次请求拿去用就抛异常。解决如果源码用的是短连接模式报连接错误时检查是不是有人手动在MySQL里执行过FLUSH PRIVILEGES或改了密码权限。如果是长连接模式建议在后端框架的ORM层开启连接池的预检机制或者在每次请求前测试连接可用性。我在本地跑这套源码时直接把wait_timeout调成了86400顺手解决了但生产环境不建议这么干。5.5 现象管理员修改用户信息后前端列表不刷新必须手动重新登录原因用户管理接口更新成功但前端列表没有重新加载本质上是前端没有在后端操作成功后调用列表查询接口。很多毕设源码的增删改操作是独立接口页面上操作完了没有自动刷新列表数据的逻辑。解决打开用户管理页对应的JS文件找到删除或修改成功的回调函数在回调里加上一行重新请求列表接口的代码。这也是一个通用的二次开发习惯后端接口只管写库前端Controller负责数据同步更新这两者的同步机制如果没想清楚几乎所有管理页面都会出现“操作成功但界面不变”的错觉。6. 二次开发进阶把课设舆情系统改成能用的内部监测工具如果只是为了交毕设系统跑通就可以收工了。但如果你要把它改造成一个公司内部能用的简易舆情监测工具有一个改造我认为优先级最高把“用户手动输入言论”改成“批量导入外部评论”。课设版本的数据完全是用户自己登进去打的真实业务里舆情数据来自公开平台的大量评论文本这个差异直接决定系统能不能用。批量导入的思路是加一个Excel或CSV导入接口文件里每一行是一条评论后端逐行执行跟手动发布一样的入库流程。关键参数有两个一是表头校验比如CSV必须包含content列否则直接拒绝导入二是重复数据去重可以用评论内容哈希值建一个唯一索引避免同一个文件被重复导入后饼状图数据翻倍。验证方法也比想象中简单。准备一百条带标准情感标签的测试评论导入后用代码把系统打标结果和标准标签对比统计一致的比例。词典方案做到60%到70%的准确率是正常的如果低于这个水平优先检查分词后是否过滤了单字词以及情感词典里是否缺少你测试数据所在领域的常见词。提升准确率的投入产出比最高的动作就是往词典里加领域词而不是换更复杂的模型。这套源码的边界我也提醒一句它对言论的处理是实时的、轻量的没有定时采集任务没有外部平台数据接入也没有时间序列趋势图。如果你所在的场景确实需要这些能力你还要继续在此基础上加定时调度和爬虫模块那已经是另一个量级的活了。但作为毕业设计、课设复现或者作为理解舆情系统如何用PythonMySQL落地的样本这个项目在“能跑、能拆、能改”上都做到了。我那次拿到手的第一天踩了字符集的坑后来强制给自己定了个习惯不管哪套源码解压后第一件事就是查配置文件的编码和数据库连接字符集这两项确认没问题再启动。从那以后部署这套系统的速度至少快了一倍希望帮到你。本文还有配套的精品资源点击获取