简介这是一份面向本科毕业设计及课程设计的Python校园舆情管理系统完整源码包适合需要快速搭建舆情分析项目的学生参考。系统涵盖用户登录与密码管理、微博数据爬取、舆情信息分析以及负面信息百分比统计与预警功能可基于饼状图与柱状图直观呈现结果并设置阈值自动提示管理干预整体技术栈涉及Python 3.6、MySQL 5.7与PyCharm环境。压缩包共包含256个文件大小约46.54MB主要由Python源码与编译文件py、pyc、前端页面html、css、js、数据库脚本sql及项目说明文档docx、md、pptx等组成并附有大量界面运行截图和演示动图便于对照查看效果。目前已有64人学习下载适合作为毕业设计选题方案、系统二次开发基础或课程项目参考资料。包内资源结构清晰除完整前后端代码外还提供说明文档、LW文稿和数据库文件可直接导入MySQL运行验证帮助使用者节省环境搭建与编码时间快速理解舆情爬取、分析、预警的完整实现流程。1. 校园舆情管理系统源码从登录到舆情预警一条链路能跑多通校园舆情管理系统这种毕业设计题每年都有大量同学在做但真正能把「爬虫、情感分析、预警、可视化」串成闭环的很少。这套资源我拆完之后最大的感受是它没有把时间浪费在花哨的界面上而是把核心精力放在了「能不能爬到数据」和「负面舆情怎么算」这两个真正的痛点。项目基于 Python 3.6.8 MySQL 5.7前端用 layui后端逻辑完整覆盖了用户登录、密码管理、微博爬取、负面信息统计分析和 20% 阈值的预警提醒。如果你的毕业设计选题正好是这个方向或者导师要求做一个带爬虫和数据分析的完整前后端项目这套源码能直接给你省下一个月的开发周期。2. 环境搭建与项目结构锁定版本比功能更重要2.1 为什么必须是 Python 3.6.8 MySQL 5.7拿到源码第一件事不是跑起来而是先看清楚环境说明。开发语言是 Python版本 3.6.8数据库 MySQL 5.7数据库工具 Navicat 11开发软件 PyCharm。这三个版本号不是随手写的背后有非常现实的原因。Python 3.6.8 是我见过国内高校毕业设计里最保守也最稳妥的选择。这个版本兼容性极好pymysql、jieba、pyecharts 这些核心依赖都能装上不像 Python 3.9 以上的环境装 pyecharts 0.5.x 会遇到依赖冲突。如果你电脑上装的是 Python 3.10 以上跑这套代码大概率会在导入环节翻车最常见的报错是ModuleNotFoundError: No module named pymysql或者 pyecharts 的 API 对不上。MySQL 5.7 选型也很讲究。它默认支持 utf8mb4 字符集能存微博正文里的各种生僻字和 emoji 表情而 MySQL 5.6 及以下版本对 utf8mb4 支持不完整容易报Incorrect string value的错误。和 Navicat 11 配合也最稳定——Navicat 连 MySQL 8.0 时经常遇到 caching_sha2_password 认证插件问题而 5.7 用的 mysql_native_password 老认证方式Navicat 11 默认就能连上省掉一堆配置。提示如果你本机已经装了 MySQL 8.0不建议卸载重装直接用 Docker 拉一个 MySQL 5.7 的容器最省事。2.2 建库建表SQL 脚本与字段设计压缩包里应该带了 .sql 格式的数据库导出文件用 Navicat 新建一个名为campus_weibo_opinion的数据库字符集选 utf8mb4然后右键运行 SQL 文件导入。如果没有现成的 SQL 文件参考下面的建表结构来建CREATE TABLE t_user ( id INT(11) NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL COMMENT 用户名, password VARCHAR(128) NOT NULL COMMENT 密码存的是MD5加密值, real_name VARCHAR(50) DEFAULT NULL COMMENT 真实姓名, role INT(1) DEFAULT 1 COMMENT 权限1为管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE t_weibo ( id INT(11) NOT NULL AUTO_INCREMENT, weibo_id VARCHAR(32) NOT NULL COMMENT 微博原始ID用于去重, keyword VARCHAR(100) NOT NULL COMMENT 爬取关键词如学校名称, content TEXT COMMENT 微博正文内容, author VARCHAR(100) DEFAULT NULL COMMENT 博主昵称, create_time DATETIME DEFAULT NULL COMMENT 微博发布时间, crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 抓取入库时间, PRIMARY KEY (id), UNIQUE KEY uk_weibo_id (weibo_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT微博抓取表; CREATE TABLE t_sentiment ( id INT(11) NOT NULL AUTO_INCREMENT, weibo_id INT(11) DEFAULT NULL, negative_count INT(5) DEFAULT 0 COMMENT 命中的负面词数量, total_words INT(5) DEFAULT 0 COMMENT 分词后总词数, negative_ratio DECIMAL(5,2) DEFAULT 0.00 COMMENT 负面词占比百分比, is_warning TINYINT(1) DEFAULT 0 COMMENT 是否触发预警1为是, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT情感分析结果表;t_user表是登录模块的地基password 字段存的是 MD5 加密后的值字段长度留 128 是因为有些实现会加盐再加密。t_weibo表的核心是weibo_id字段爬虫每次入库前先查这个字段是否已存在避免重复数据把饼图和柱状图的统计结果拉偏。t_sentiment表记录每条微博的负面词数量、总词数和负面占比is_warning字段就是预警模块的触发器。2.3 项目目录结构与后端框架判断从项目正文的 CSS 文件列表能看出来前端使用的是 layui 框架layui.css、admin.css、font-awesome.min.css这些都是 layui 后台模板的标配。完整的项目目录结构大概是这样的campus_weibo/ ├── app.py # 后端主入口Flask或Tornado框架 ├── config.py # 数据库连接配置 ├── spider/ │ ├── weibo_spider.py # 微博爬虫核心逻辑 │ └── header.py # 请求头配置User-Agent池 ├── analysis/ │ ├── sentiment.py # 情感词典与分词分析 │ └── negative_words.txt # 负面情感词典 ├── static/ │ ├── layui/ │ │ ├── css/ │ │ │ ├── layui.css │ │ │ ├── admin.css │ │ │ └── font-awesome.min.css │ │ └── js/ │ └── echarts/ # 图表库 ├── templates/ # HTML模板 │ ├── login.html │ ├── index.html │ └── warning.html └── database/ └── campus_weibo.sql # 数据库脚本config.py 里是数据库连接关键配置需要改成你自己的账号密码# config.py DB_HOST localhost DB_PORT 3306 DB_USER root DB_PASSWORD 123456 # 改成你自己的MySQL密码 DB_NAME campus_weibo_opinion DB_CHARSET utf8mb4 SECRET_KEY campus_weibo_secret # Flask session加密用的密钥这段配置核心就四个参数host 一般保持 localhost 不动port 是 MySQL 默认的 3306user 和 password 必须改成你本机的真实账号。charset 必须写 utf8mb4 而不是 utf8原因前文已经说过——要兼容微博正文里的特殊字符。SECRET_KEY 只要是任意英文字符串即可但注意不要用默认值上生产环境。3. 登录与用户管理layui 前端 Flask 后端如何闭合3.1 登录页面layui 表单的渲染与提交逻辑登录页用的 layui 的 form 组件整体交互逻辑是用户输入用户名和密码点击登录按钮后前端用 layui 内置的 jQuery 发起 Ajax 请求把表单数据 POST 给后端接口。这里有个细节前端不要做复杂的二次校验因为毕业设计答辩时老师第一件事就是看非法输入能不能被拦住前端校验只是体验后端才是真正的安全边界。前端登录提交的核心代码// templates/login.html 中的提交逻辑 script layui.use([form, layer], function(){ var form layui.form; var layer layui.layer; form.on(submit(loginBtn), function(data){ var username data.field.username; var password data.field.password; if(username || password ){ layer.msg(用户名和密码不能为空); return false; } // 提交登录请求 $.ajax({ url: /user/login, type: POST, data: { username: username, password: password }, dataType: json, success: function(res){ if(res.code SUCCESS){ layer.msg(登录成功正在跳转); setTimeout(function(){ window.location.href /index; }, 500); } else { layer.msg(res.msg); } } }); return false; }); }); /script这段代码里form.on(submit(loginBtn))是 layui 表单的监听写法data.field可以拿到表单里所有带 name 属性的输入框值。校验空字符串这一步是必要的因为空的用户名密码请求会被后端直接拒绝与其等后端返回错误再弹窗不如前端先拦一道。3.2 后端登录接口密码校验与 Session 会话维持后端的登录处理逻辑是标准的 Flask 写法。先接收表单参数从数据库查询用户表比对加密后的密码匹配成功后把用户信息写入 Session跳转到后台首页。密码校验这一块很多毕业设计用的是明文比对代码里如果你看到cursor.execute(select * from t_user where username%s and password%s)这种写法说明数据库里存的是明文密码答辩时如果老师问「密码安全怎么做的」这是最容易被追问的一个点。# app.py 中登录接口的简化实现 import hashlib from flask import Flask, request, session, jsonify, redirect app Flask(__name__) app.config.from_object(config) app.secret_key config.SECRET_KEY app.route(/user/login, methods[POST]) def login(): username request.form.get(username, ).strip() password request.form.get(password, ) # 参数非空校验 if not username or not password: return jsonify({code: FAIL, msg: 用户名和密码不能为空}) # MD5加密后查询数据库 password_md5 hashlib.md5(password.encode(utf-8)).hexdigest() sql SELECT * FROM t_user WHERE username%s AND password%s params (username, password_md5) user db_fetch_one(sql, params) if user: session[user_id] user[id] session[username] user[username] return jsonify({code: SUCCESS, msg: 登录成功}) else: return jsonify({code: FAIL, msg: 用户名或密码错误}) app.route(/index) def index(): # 未登录直接跳回登录页 if user_id not in session: return redirect(/login) return render_template(index.html)这段代码有两个实战中的关键点。第一个是 MD5 加密hashlib.md5(password.encode(utf-8)).hexdigest()这一步将明文密码加密后再和数据库比对这样即使数据库泄露也不会直接暴露明文密码。注意编码必须是utf-8否则中文密码会报错。第二个是 Session 判断user_id not in session用来拦截未登录访问所有后台页面都要有这一层判断否则就会出现「直接在地址栏输入 /index 就能绕过登录」这种答辩致命伤。建议把 Session 校验抽成装饰器统一使用不要在每个路由函数里重复写。3.3 密码管理与登录拦截的坑位这套资源里用户管理部分通常包含「修改密码」功能逻辑也不复杂用户输入旧密码、新密码后端先校验旧密码是否匹配再更新为新密码的 MD5 值。常见的翻车场景是更新语句写错了条件把WHERE username%s写成了WHERE id%s然后前端传的参数名又不统一最后导致所有用户密码都被批量重置。登录拦截这一块Flask 里最推荐的做法是写一个登录校验装饰器统一给所有需要登录的路由加上# 登录校验装饰器 from functools import wraps def login_required(func): wraps(func) def wrapper(*args, **kwargs): if user_id not in session: return redirect(/login) return func(*args, **kwargs) return wrapper # 使用方式在路由上直接加装饰器 app.route(/index) login_required def index(): return render_template(index.html)装饰器方案的好处是以后新增后台页面时一行login_required就搞定了不用复制粘贴大段判断代码。注意装饰器必须定义在路由函数之前且functools.wraps一定要带上否则 Flask 路由框架会把原始函数名搞丢导致 URL 映射错乱。4. 微博爬虫模块URL 构造、反爬应对与数据入库4.1 爬虫目标与接口选型摘要里写的需求是「爬取大学生微博喀什大学微博或者其他大学生微博主要看是否能爬」这说明爬虫是这个项目里不确定性最高的部分也是最容易被答辩老师追问的部分。爬微博有两个常用入口一个是移动端接口m.weibo.cn另一个是桌面端weibo.cn。我拆过的绝大部分毕业设计爬虫最后能稳定跑通的都是基于移动端接口因为它的返回体是干净的 JSON不需要解析复杂的 HTML 标签。爬虫目标不是漫无目的地爬全站而是按关键词搜索。比如把「喀什大学」「大学生」作为关键词调用微博搜索接口拿到包含这些关键词的实时微博列表。接口的核心参数是containerid100103type1q关键词和分页用的page参数。# spider/weibo_spider.py 爬虫核心请求逻辑 import requests import json import time import pymysql def build_url(keyword, page): # 关键词需要URL编码 kw quote(keyword) containerid 100103type1q kw url https://m.weibo.cn/api/container/getIndex params { containerid: containerid, page: page } return url, params def fetch_weibo_list(keyword, page1): url, params build_url(keyword, page) headers { User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1, Referer: https://m.weibo.cn/search?containerid100103type%3D1%26q%3D quote(keyword), X-Requested-With: XMLHttpRequest, } resp requests.get(url, paramsparams, headersheaders, timeout10) json_data resp.json() cards json_data.get(data, {}).get(cards, []) result [] for card in cards: if card.get(card_type) ! 9: continue mblog card.get(mblog, {}) item { weibo_id: mblog.get(idstr, ), content: mblog.get(text, ), author: mblog.get(user, {}).get(screen_name, ), created_at: mblog.get(created_at, ), } result.append(item) return result这段代码里有几个关键参数要说明。containerid是微博移动端搜索接口的固定标识符100103type1表示搜索全部类型微博q是搜索关键词。card_type 9是微博正文卡片类型其他类型的卡片是广告位或推荐位必须通过这个判断过滤掉。mblog.get(text)返回的微博正文是 HTML 格式的后续入库前需要做清洗把a标签、br等去掉。4.2 反爬与请求频率控制节奏比换 IP 更重要微博的反爬策略这几年只强不弱但毕业设计场景下不需要上什么高级手段把基础的三件事做好就能稳定跑第一是 User-Agent 和 Referer 要配齐Referer 缺失是 m.weibo.cn 最容易被拒绝的原因第二是请求频率每次请求之间至少间隔 2-3 秒第三是 Cookie搜索接口有时需要登录后的 Cookie 才能返回完整数据。# 爬虫调度与入库逻辑 conn get_db_connection() # 读取config.py配置建立MySQL连接 cursor conn.cursor() keywords [喀什大学, 大学生校园] for keyword in keywords: for page in range(1, 4): # 每个关键词爬取前3页约60条微博 weibo_list fetch_weibo_list(keyword, page) for weibo in weibo_list: # 清洗正文中的HTML标签 clean_content re.sub(r[^], , weibo[content]) clean_content clean_content.replace(nbsp;, ).strip() # 入库前先去重 check_sql SELECT id FROM t_weibo WHERE weibo_id%s if cursor.execute(check_sql, (weibo[weibo_id],)): continue insert_sql INSERT INTO t_weibo (weibo_id, keyword, content, author, create_time) VALUES (%s, %s, %s, %s, %s) cursor.execute(insert_sql, ( weibo[weibo_id], keyword, clean_content, weibo[author], weibo[created_at] )) conn.commit() time.sleep(3) # 每翻一页sleep 3秒控制频率 cursor.close() conn.close()这里time.sleep(3)的位置值得说一下它放在每页爬完之后而不是每条微博之间。因为一次请求会返回一页的微博列表翻页才是频率瓶颈点单页内部不需要 sleep。如果爬取频率太高会触发微博的风控机制返回的 JSON 里直接没有 data 字段此时要学会看响应状态。一般 200 响应但 data 为空就是被限流了直接 403 则是 IP 被封。真遇到 403别折腾代理先停半小时再说。4.3 数据清洗与入库细节微博正文text字段是 HTML 格式里面经常混着a href/n/管理员这种用户链接、span classurl-icon表情图标和br/换行符。正则[^]是标准清洗方式把所有尖括号标签全部剥掉。清洗完的文本要 strip 掉首尾空格否则入库后查询会出现诡异的LIKE匹配问题。注意created_at字段是微博平台的时间格式形如2分钟前、今天 12:30这种相对时间不是标准的YYYY-MM-DD HH:MM:SS。入库前最好转换一下否则情感分析模块如果要按时间维度做统计会发现排序完全乱掉。简单粗暴的做法是把相对时间转成当前时间代码里可以用一个固定时间加上偏移量来计算更稳的做法是直接存原始字符串分析模块不依赖这个字段。5. 负面情感分析与预警统计词典法实现负面占比5.1 情感分析的技术路线为什么选词典法校园舆情系统的情感分析不需要上深度学习模型毕业设计的体量和答辩时间都不允许。项目选择的是基于情感词典的规则匹配方法这也是当前这类系统中常见的做法准备一个负面词典对微博正文分词后统计命中了多少个负面词再用负面词数量除以总词数得到负面占比。关键词是「百分比」和「预警」这说明系统不是把微博简单分两类正面/负面而是计算一个连续的负面占比指标再和阈值对比。词典法的好处是结果可解释——老师说「这条微博为什么算负面」你能指着词典告诉他是哪个词命中了比神经网络的「黑匣子」好讲得多。坏处是词典质量直接决定分析效果如果negative_words.txt里只有「垃圾」「愤怒」这种词遇到「不咋地」「太坑了」这种口语化表达会漏判。# analysis/sentiment.py 基于词典的情感分析实现 import jieba def load_negative_dict(pathnegative_words.txt): word_set set() with open(path, r, encodingutf-8) as f: for line in f: word line.strip() if word and not word.startswith(#): word_set.add(word) return word_set def analyze_sentiment(content, negative_dict): # 1. 分词 words jieba.lcut(content) total_words len(words) if total_words 0: return 0.0, 0, 0 # 2. 统计负面词命中数 negative_count sum(1 for w in words if w in negative_dict) # 3. 计算负面占比百分比 negative_ratio round(negative_count * 100.0 / total_words, 2) return negative_ratio, negative_count, total_words这里三个关键点要讲清楚。第一是jieba.lcut返回的是词列表比jieba.cut返回迭代器更适合做统计计算因为后面要同时遍历多次。第二是sum(1 for w in words if w in negative_dict)这个写法统计的是负面向量中所有命中词的数量用的是生成器表达式不会额外占用内存。第三是负面占比的公式negative_count * 100.0 / total_words乘以 100.0 是为了转成百分比浮点数注意这里必须用浮点数除以整数否则 Python 2 风格下会直接向下取整成 0。5.2 预警阈值计算与预警记录入库摘要明确写了「百分比如20%以上负面信息就要提示了」所以预警逻辑就是把这个阈值比较落地。分析完每一条微博后判断负面占比是否大于等于 20%如果触发就把这条记录连同分析结果写入预警表后台首页的预警提示就是查这张表出来的。# 预警判断与入库逻辑 WARNING_THRESHOLD 20.0 # 预警阈值百分比 def check_and_warn(weibo_id, negative_ratio): is_warning 1 if negative_ratio WARNING_THRESHOLD else 0 if is_warning: insert_sql INSERT INTO t_sentiment (weibo_id, negative_count, total_words, negative_ratio, is_warning) VALUES (%s, %s, %s, %s, %s) cursor.execute(insert_sql, ( weibo_id, negative_count, total_words, negative_ratio, is_warning )) conn.commit() return True return False预警阈值的设置很有讲究。20% 意味着一条 50 个字的微博里只要命中 10 个负面词就报警。实际的负面词典通常包含几百个词而这个命中率其实已经偏高了答辩时如果导师问「为什么是 20%」你可以说这个值是可配置的20% 是基于校园微博场景的经验值把WARNING_THRESHOLD改成 30 就能降低敏感度。这样回答比「系统里写死的」要好得多。5.3 饼图与柱状图可视化pyecharts 的版本陷阱摘要里明确要求用饼状图和柱状图对负面信息进行百分比分析项目用的是 pyecharts 0.5.x 版本。这里要特别提醒pyecharts 1.x 和 0.5.x 的 API 完全不兼容0.5 是用Pie()实例化然后add()1.x 是用Pie().add()链式调用参数也从列表套列表变成了字典。# 0.5.x 版本的饼图生成方式 from pyecharts import Pie, Bar def render_pie(negative_ratio, positive_ratio): pie Pie(校园微博负面舆情占比) pie.add( 舆情分布, [负面, 非负面], [negative_ratio, positive_ratio], is_label_showTrue, label_formatter{b}: {d}% ) return pie def render_bar(keyword_stats): bar Bar(各关键词负面微博条数) bar.add( 负面数量, list(keyword_stats.keys()), list(keyword_stats.values()), is_stackTrue ) return bar注意label_formatter{b}: {d}%{b}是名称{d}是百分比占比这行配置让饼图上的数据标签直接显示「负面: 23.5%」答辩展示的时候比只看颜色直观得多。如果你的环境装的是 pyecharts 1.x代码需要改成pie Pie().add(, [list(z) for z in zip(labels, values)])的新式写法。建议直接参照项目里原有的写法pip 安装对应版本pip install pyecharts0.5.6。图表生成后是独立的 HTML 文件Flask 后端把它嵌入后台首页的 iframe 里展示。核心点是图表文件要生成在templates/目录下否则 Flask 渲染时会找不到模板而报错。6. 避坑与验收五个真坑和一份自检清单6.1 环境与依赖的五个踩坑记录第一个坑是数据库导入乱码。现象是导入 .sql 文件后登录页面正常但查出来的中文全是问号。原因是建库时字符集选了 utf8 而不是 utf8mb4或者 .sql 文件本身的编码就是 GBK。解决方法是删库重建用 Navicat 建库时手动把字符集选成 utf8mb4导入前再检查文件的编码格式VSCode 右下角能看到文件编码。第二个坑是 pyecharts 图表空白页。现象是饼图能生成 HTML 文件但浏览器打开是一片空白。原因是 0.5.6 版本默认引用的是 CDN 上的 echarts.min.js答辩现场的电脑如果没联网JS 加载失败自然白屏。解决方法是去 echarts 官网下载 echarts.min.js 放到 static 目录然后把 pyecharts 的jshost改成本地路径。第三个坑是 Flask 返回的 Excel 下载乱码。现象是导出的 CSV 文件用 Office 打开中文乱码。原因是 Python 默认写入的编码是 utf-8而 Windows 的 Excel 要求 GBK 编码才能正确显示中文。解决方法是写入时加\ufeffBOM 头或者用encodinggbk后者要注意部分字符 GBK 编码不支持会直接报编码错误。第四个坑是 MySQL 连接超时。现象是系统刚部署完能正常访问放了一晚上第二天就会报TimeoutError或者MySQL server has gone away。原因是连接池里的长连接空闲超过了 MySQL 的wait_timeout默认值 8 小时。解决方法是每次操作数据库前判断连接是否存活失效就重连不要一个连接用到底。第五个坑是爬虫 URL 编码问题。现象是关键词带中文时返回 414 Request-URI Too Long。原因是build_url函数里关键词做 URL 编码后仍然拼接在 URL 路径里把超长参数塞进了请求行。解决方法是改成 params 传参方式让 requests 库自己处理编码。6.2 验收自检清单与收尾系统跑通后做一次完整的验收照着下面这份清单走一遍能帮你提前发现答辩时可能被当场戳穿的隐藏问题。登录模块输入错误密码能返回提示未登录直接访问/index会被重定向回登录页修改密码后旧密码失效。爬虫模块换个从来没爬过的关键词能正常返回数据连续翻 5 页不触发微博风控重复爬取同一关键词不会产生重复数据。分析模块一条明显负面的「学校食堂太垃圾了」和一条正面微博分析结果有明显区分。预警模块把阈值改到 1% 能立刻触发预警改回 20% 后正常微博不会误报。可视化模块断网状态下饼图和柱状图依然能正常渲染图表上的百分比和数据库t_sentiment表里的数值能对得上。这套资源我拆完最大的感受是爬虫和分析两个模块做得够扎实关键词爬取和词典分析的设计确实能跑。但毕业设计最怕的不是功能少而是跑不起来。从那以后我接手任何源码目录第一件事永远是先看 requirement.txt 和 SQL 脚本再动手配环境这个顺序能帮你在拆包时少走一半弯路。希望这篇拆解对你有帮助。本文还有配套的精品资源点击获取 校园舆情管理系统源码拆解：爬虫、情感分析与预警全流程
简介这是一份面向本科毕业设计及课程设计的Python校园舆情管理系统完整源码包适合需要快速搭建舆情分析项目的学生参考。系统涵盖用户登录与密码管理、微博数据爬取、舆情信息分析以及负面信息百分比统计与预警功能可基于饼状图与柱状图直观呈现结果并设置阈值自动提示管理干预整体技术栈涉及Python 3.6、MySQL 5.7与PyCharm环境。压缩包共包含256个文件大小约46.54MB主要由Python源码与编译文件py、pyc、前端页面html、css、js、数据库脚本sql及项目说明文档docx、md、pptx等组成并附有大量界面运行截图和演示动图便于对照查看效果。目前已有64人学习下载适合作为毕业设计选题方案、系统二次开发基础或课程项目参考资料。包内资源结构清晰除完整前后端代码外还提供说明文档、LW文稿和数据库文件可直接导入MySQL运行验证帮助使用者节省环境搭建与编码时间快速理解舆情爬取、分析、预警的完整实现流程。1. 校园舆情管理系统源码从登录到舆情预警一条链路能跑多通校园舆情管理系统这种毕业设计题每年都有大量同学在做但真正能把「爬虫、情感分析、预警、可视化」串成闭环的很少。这套资源我拆完之后最大的感受是它没有把时间浪费在花哨的界面上而是把核心精力放在了「能不能爬到数据」和「负面舆情怎么算」这两个真正的痛点。项目基于 Python 3.6.8 MySQL 5.7前端用 layui后端逻辑完整覆盖了用户登录、密码管理、微博爬取、负面信息统计分析和 20% 阈值的预警提醒。如果你的毕业设计选题正好是这个方向或者导师要求做一个带爬虫和数据分析的完整前后端项目这套源码能直接给你省下一个月的开发周期。2. 环境搭建与项目结构锁定版本比功能更重要2.1 为什么必须是 Python 3.6.8 MySQL 5.7拿到源码第一件事不是跑起来而是先看清楚环境说明。开发语言是 Python版本 3.6.8数据库 MySQL 5.7数据库工具 Navicat 11开发软件 PyCharm。这三个版本号不是随手写的背后有非常现实的原因。Python 3.6.8 是我见过国内高校毕业设计里最保守也最稳妥的选择。这个版本兼容性极好pymysql、jieba、pyecharts 这些核心依赖都能装上不像 Python 3.9 以上的环境装 pyecharts 0.5.x 会遇到依赖冲突。如果你电脑上装的是 Python 3.10 以上跑这套代码大概率会在导入环节翻车最常见的报错是ModuleNotFoundError: No module named pymysql或者 pyecharts 的 API 对不上。MySQL 5.7 选型也很讲究。它默认支持 utf8mb4 字符集能存微博正文里的各种生僻字和 emoji 表情而 MySQL 5.6 及以下版本对 utf8mb4 支持不完整容易报Incorrect string value的错误。和 Navicat 11 配合也最稳定——Navicat 连 MySQL 8.0 时经常遇到 caching_sha2_password 认证插件问题而 5.7 用的 mysql_native_password 老认证方式Navicat 11 默认就能连上省掉一堆配置。提示如果你本机已经装了 MySQL 8.0不建议卸载重装直接用 Docker 拉一个 MySQL 5.7 的容器最省事。2.2 建库建表SQL 脚本与字段设计压缩包里应该带了 .sql 格式的数据库导出文件用 Navicat 新建一个名为campus_weibo_opinion的数据库字符集选 utf8mb4然后右键运行 SQL 文件导入。如果没有现成的 SQL 文件参考下面的建表结构来建CREATE TABLE t_user ( id INT(11) NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL COMMENT 用户名, password VARCHAR(128) NOT NULL COMMENT 密码存的是MD5加密值, real_name VARCHAR(50) DEFAULT NULL COMMENT 真实姓名, role INT(1) DEFAULT 1 COMMENT 权限1为管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE t_weibo ( id INT(11) NOT NULL AUTO_INCREMENT, weibo_id VARCHAR(32) NOT NULL COMMENT 微博原始ID用于去重, keyword VARCHAR(100) NOT NULL COMMENT 爬取关键词如学校名称, content TEXT COMMENT 微博正文内容, author VARCHAR(100) DEFAULT NULL COMMENT 博主昵称, create_time DATETIME DEFAULT NULL COMMENT 微博发布时间, crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 抓取入库时间, PRIMARY KEY (id), UNIQUE KEY uk_weibo_id (weibo_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT微博抓取表; CREATE TABLE t_sentiment ( id INT(11) NOT NULL AUTO_INCREMENT, weibo_id INT(11) DEFAULT NULL, negative_count INT(5) DEFAULT 0 COMMENT 命中的负面词数量, total_words INT(5) DEFAULT 0 COMMENT 分词后总词数, negative_ratio DECIMAL(5,2) DEFAULT 0.00 COMMENT 负面词占比百分比, is_warning TINYINT(1) DEFAULT 0 COMMENT 是否触发预警1为是, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT情感分析结果表;t_user表是登录模块的地基password 字段存的是 MD5 加密后的值字段长度留 128 是因为有些实现会加盐再加密。t_weibo表的核心是weibo_id字段爬虫每次入库前先查这个字段是否已存在避免重复数据把饼图和柱状图的统计结果拉偏。t_sentiment表记录每条微博的负面词数量、总词数和负面占比is_warning字段就是预警模块的触发器。2.3 项目目录结构与后端框架判断从项目正文的 CSS 文件列表能看出来前端使用的是 layui 框架layui.css、admin.css、font-awesome.min.css这些都是 layui 后台模板的标配。完整的项目目录结构大概是这样的campus_weibo/ ├── app.py # 后端主入口Flask或Tornado框架 ├── config.py # 数据库连接配置 ├── spider/ │ ├── weibo_spider.py # 微博爬虫核心逻辑 │ └── header.py # 请求头配置User-Agent池 ├── analysis/ │ ├── sentiment.py # 情感词典与分词分析 │ └── negative_words.txt # 负面情感词典 ├── static/ │ ├── layui/ │ │ ├── css/ │ │ │ ├── layui.css │ │ │ ├── admin.css │ │ │ └── font-awesome.min.css │ │ └── js/ │ └── echarts/ # 图表库 ├── templates/ # HTML模板 │ ├── login.html │ ├── index.html │ └── warning.html └── database/ └── campus_weibo.sql # 数据库脚本config.py 里是数据库连接关键配置需要改成你自己的账号密码# config.py DB_HOST localhost DB_PORT 3306 DB_USER root DB_PASSWORD 123456 # 改成你自己的MySQL密码 DB_NAME campus_weibo_opinion DB_CHARSET utf8mb4 SECRET_KEY campus_weibo_secret # Flask session加密用的密钥这段配置核心就四个参数host 一般保持 localhost 不动port 是 MySQL 默认的 3306user 和 password 必须改成你本机的真实账号。charset 必须写 utf8mb4 而不是 utf8原因前文已经说过——要兼容微博正文里的特殊字符。SECRET_KEY 只要是任意英文字符串即可但注意不要用默认值上生产环境。3. 登录与用户管理layui 前端 Flask 后端如何闭合3.1 登录页面layui 表单的渲染与提交逻辑登录页用的 layui 的 form 组件整体交互逻辑是用户输入用户名和密码点击登录按钮后前端用 layui 内置的 jQuery 发起 Ajax 请求把表单数据 POST 给后端接口。这里有个细节前端不要做复杂的二次校验因为毕业设计答辩时老师第一件事就是看非法输入能不能被拦住前端校验只是体验后端才是真正的安全边界。前端登录提交的核心代码// templates/login.html 中的提交逻辑 script layui.use([form, layer], function(){ var form layui.form; var layer layui.layer; form.on(submit(loginBtn), function(data){ var username data.field.username; var password data.field.password; if(username || password ){ layer.msg(用户名和密码不能为空); return false; } // 提交登录请求 $.ajax({ url: /user/login, type: POST, data: { username: username, password: password }, dataType: json, success: function(res){ if(res.code SUCCESS){ layer.msg(登录成功正在跳转); setTimeout(function(){ window.location.href /index; }, 500); } else { layer.msg(res.msg); } } }); return false; }); }); /script这段代码里form.on(submit(loginBtn))是 layui 表单的监听写法data.field可以拿到表单里所有带 name 属性的输入框值。校验空字符串这一步是必要的因为空的用户名密码请求会被后端直接拒绝与其等后端返回错误再弹窗不如前端先拦一道。3.2 后端登录接口密码校验与 Session 会话维持后端的登录处理逻辑是标准的 Flask 写法。先接收表单参数从数据库查询用户表比对加密后的密码匹配成功后把用户信息写入 Session跳转到后台首页。密码校验这一块很多毕业设计用的是明文比对代码里如果你看到cursor.execute(select * from t_user where username%s and password%s)这种写法说明数据库里存的是明文密码答辩时如果老师问「密码安全怎么做的」这是最容易被追问的一个点。# app.py 中登录接口的简化实现 import hashlib from flask import Flask, request, session, jsonify, redirect app Flask(__name__) app.config.from_object(config) app.secret_key config.SECRET_KEY app.route(/user/login, methods[POST]) def login(): username request.form.get(username, ).strip() password request.form.get(password, ) # 参数非空校验 if not username or not password: return jsonify({code: FAIL, msg: 用户名和密码不能为空}) # MD5加密后查询数据库 password_md5 hashlib.md5(password.encode(utf-8)).hexdigest() sql SELECT * FROM t_user WHERE username%s AND password%s params (username, password_md5) user db_fetch_one(sql, params) if user: session[user_id] user[id] session[username] user[username] return jsonify({code: SUCCESS, msg: 登录成功}) else: return jsonify({code: FAIL, msg: 用户名或密码错误}) app.route(/index) def index(): # 未登录直接跳回登录页 if user_id not in session: return redirect(/login) return render_template(index.html)这段代码有两个实战中的关键点。第一个是 MD5 加密hashlib.md5(password.encode(utf-8)).hexdigest()这一步将明文密码加密后再和数据库比对这样即使数据库泄露也不会直接暴露明文密码。注意编码必须是utf-8否则中文密码会报错。第二个是 Session 判断user_id not in session用来拦截未登录访问所有后台页面都要有这一层判断否则就会出现「直接在地址栏输入 /index 就能绕过登录」这种答辩致命伤。建议把 Session 校验抽成装饰器统一使用不要在每个路由函数里重复写。3.3 密码管理与登录拦截的坑位这套资源里用户管理部分通常包含「修改密码」功能逻辑也不复杂用户输入旧密码、新密码后端先校验旧密码是否匹配再更新为新密码的 MD5 值。常见的翻车场景是更新语句写错了条件把WHERE username%s写成了WHERE id%s然后前端传的参数名又不统一最后导致所有用户密码都被批量重置。登录拦截这一块Flask 里最推荐的做法是写一个登录校验装饰器统一给所有需要登录的路由加上# 登录校验装饰器 from functools import wraps def login_required(func): wraps(func) def wrapper(*args, **kwargs): if user_id not in session: return redirect(/login) return func(*args, **kwargs) return wrapper # 使用方式在路由上直接加装饰器 app.route(/index) login_required def index(): return render_template(index.html)装饰器方案的好处是以后新增后台页面时一行login_required就搞定了不用复制粘贴大段判断代码。注意装饰器必须定义在路由函数之前且functools.wraps一定要带上否则 Flask 路由框架会把原始函数名搞丢导致 URL 映射错乱。4. 微博爬虫模块URL 构造、反爬应对与数据入库4.1 爬虫目标与接口选型摘要里写的需求是「爬取大学生微博喀什大学微博或者其他大学生微博主要看是否能爬」这说明爬虫是这个项目里不确定性最高的部分也是最容易被答辩老师追问的部分。爬微博有两个常用入口一个是移动端接口m.weibo.cn另一个是桌面端weibo.cn。我拆过的绝大部分毕业设计爬虫最后能稳定跑通的都是基于移动端接口因为它的返回体是干净的 JSON不需要解析复杂的 HTML 标签。爬虫目标不是漫无目的地爬全站而是按关键词搜索。比如把「喀什大学」「大学生」作为关键词调用微博搜索接口拿到包含这些关键词的实时微博列表。接口的核心参数是containerid100103type1q关键词和分页用的page参数。# spider/weibo_spider.py 爬虫核心请求逻辑 import requests import json import time import pymysql def build_url(keyword, page): # 关键词需要URL编码 kw quote(keyword) containerid 100103type1q kw url https://m.weibo.cn/api/container/getIndex params { containerid: containerid, page: page } return url, params def fetch_weibo_list(keyword, page1): url, params build_url(keyword, page) headers { User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1, Referer: https://m.weibo.cn/search?containerid100103type%3D1%26q%3D quote(keyword), X-Requested-With: XMLHttpRequest, } resp requests.get(url, paramsparams, headersheaders, timeout10) json_data resp.json() cards json_data.get(data, {}).get(cards, []) result [] for card in cards: if card.get(card_type) ! 9: continue mblog card.get(mblog, {}) item { weibo_id: mblog.get(idstr, ), content: mblog.get(text, ), author: mblog.get(user, {}).get(screen_name, ), created_at: mblog.get(created_at, ), } result.append(item) return result这段代码里有几个关键参数要说明。containerid是微博移动端搜索接口的固定标识符100103type1表示搜索全部类型微博q是搜索关键词。card_type 9是微博正文卡片类型其他类型的卡片是广告位或推荐位必须通过这个判断过滤掉。mblog.get(text)返回的微博正文是 HTML 格式的后续入库前需要做清洗把a标签、br等去掉。4.2 反爬与请求频率控制节奏比换 IP 更重要微博的反爬策略这几年只强不弱但毕业设计场景下不需要上什么高级手段把基础的三件事做好就能稳定跑第一是 User-Agent 和 Referer 要配齐Referer 缺失是 m.weibo.cn 最容易被拒绝的原因第二是请求频率每次请求之间至少间隔 2-3 秒第三是 Cookie搜索接口有时需要登录后的 Cookie 才能返回完整数据。# 爬虫调度与入库逻辑 conn get_db_connection() # 读取config.py配置建立MySQL连接 cursor conn.cursor() keywords [喀什大学, 大学生校园] for keyword in keywords: for page in range(1, 4): # 每个关键词爬取前3页约60条微博 weibo_list fetch_weibo_list(keyword, page) for weibo in weibo_list: # 清洗正文中的HTML标签 clean_content re.sub(r[^], , weibo[content]) clean_content clean_content.replace(nbsp;, ).strip() # 入库前先去重 check_sql SELECT id FROM t_weibo WHERE weibo_id%s if cursor.execute(check_sql, (weibo[weibo_id],)): continue insert_sql INSERT INTO t_weibo (weibo_id, keyword, content, author, create_time) VALUES (%s, %s, %s, %s, %s) cursor.execute(insert_sql, ( weibo[weibo_id], keyword, clean_content, weibo[author], weibo[created_at] )) conn.commit() time.sleep(3) # 每翻一页sleep 3秒控制频率 cursor.close() conn.close()这里time.sleep(3)的位置值得说一下它放在每页爬完之后而不是每条微博之间。因为一次请求会返回一页的微博列表翻页才是频率瓶颈点单页内部不需要 sleep。如果爬取频率太高会触发微博的风控机制返回的 JSON 里直接没有 data 字段此时要学会看响应状态。一般 200 响应但 data 为空就是被限流了直接 403 则是 IP 被封。真遇到 403别折腾代理先停半小时再说。4.3 数据清洗与入库细节微博正文text字段是 HTML 格式里面经常混着a href/n/管理员这种用户链接、span classurl-icon表情图标和br/换行符。正则[^]是标准清洗方式把所有尖括号标签全部剥掉。清洗完的文本要 strip 掉首尾空格否则入库后查询会出现诡异的LIKE匹配问题。注意created_at字段是微博平台的时间格式形如2分钟前、今天 12:30这种相对时间不是标准的YYYY-MM-DD HH:MM:SS。入库前最好转换一下否则情感分析模块如果要按时间维度做统计会发现排序完全乱掉。简单粗暴的做法是把相对时间转成当前时间代码里可以用一个固定时间加上偏移量来计算更稳的做法是直接存原始字符串分析模块不依赖这个字段。5. 负面情感分析与预警统计词典法实现负面占比5.1 情感分析的技术路线为什么选词典法校园舆情系统的情感分析不需要上深度学习模型毕业设计的体量和答辩时间都不允许。项目选择的是基于情感词典的规则匹配方法这也是当前这类系统中常见的做法准备一个负面词典对微博正文分词后统计命中了多少个负面词再用负面词数量除以总词数得到负面占比。关键词是「百分比」和「预警」这说明系统不是把微博简单分两类正面/负面而是计算一个连续的负面占比指标再和阈值对比。词典法的好处是结果可解释——老师说「这条微博为什么算负面」你能指着词典告诉他是哪个词命中了比神经网络的「黑匣子」好讲得多。坏处是词典质量直接决定分析效果如果negative_words.txt里只有「垃圾」「愤怒」这种词遇到「不咋地」「太坑了」这种口语化表达会漏判。# analysis/sentiment.py 基于词典的情感分析实现 import jieba def load_negative_dict(pathnegative_words.txt): word_set set() with open(path, r, encodingutf-8) as f: for line in f: word line.strip() if word and not word.startswith(#): word_set.add(word) return word_set def analyze_sentiment(content, negative_dict): # 1. 分词 words jieba.lcut(content) total_words len(words) if total_words 0: return 0.0, 0, 0 # 2. 统计负面词命中数 negative_count sum(1 for w in words if w in negative_dict) # 3. 计算负面占比百分比 negative_ratio round(negative_count * 100.0 / total_words, 2) return negative_ratio, negative_count, total_words这里三个关键点要讲清楚。第一是jieba.lcut返回的是词列表比jieba.cut返回迭代器更适合做统计计算因为后面要同时遍历多次。第二是sum(1 for w in words if w in negative_dict)这个写法统计的是负面向量中所有命中词的数量用的是生成器表达式不会额外占用内存。第三是负面占比的公式negative_count * 100.0 / total_words乘以 100.0 是为了转成百分比浮点数注意这里必须用浮点数除以整数否则 Python 2 风格下会直接向下取整成 0。5.2 预警阈值计算与预警记录入库摘要明确写了「百分比如20%以上负面信息就要提示了」所以预警逻辑就是把这个阈值比较落地。分析完每一条微博后判断负面占比是否大于等于 20%如果触发就把这条记录连同分析结果写入预警表后台首页的预警提示就是查这张表出来的。# 预警判断与入库逻辑 WARNING_THRESHOLD 20.0 # 预警阈值百分比 def check_and_warn(weibo_id, negative_ratio): is_warning 1 if negative_ratio WARNING_THRESHOLD else 0 if is_warning: insert_sql INSERT INTO t_sentiment (weibo_id, negative_count, total_words, negative_ratio, is_warning) VALUES (%s, %s, %s, %s, %s) cursor.execute(insert_sql, ( weibo_id, negative_count, total_words, negative_ratio, is_warning )) conn.commit() return True return False预警阈值的设置很有讲究。20% 意味着一条 50 个字的微博里只要命中 10 个负面词就报警。实际的负面词典通常包含几百个词而这个命中率其实已经偏高了答辩时如果导师问「为什么是 20%」你可以说这个值是可配置的20% 是基于校园微博场景的经验值把WARNING_THRESHOLD改成 30 就能降低敏感度。这样回答比「系统里写死的」要好得多。5.3 饼图与柱状图可视化pyecharts 的版本陷阱摘要里明确要求用饼状图和柱状图对负面信息进行百分比分析项目用的是 pyecharts 0.5.x 版本。这里要特别提醒pyecharts 1.x 和 0.5.x 的 API 完全不兼容0.5 是用Pie()实例化然后add()1.x 是用Pie().add()链式调用参数也从列表套列表变成了字典。# 0.5.x 版本的饼图生成方式 from pyecharts import Pie, Bar def render_pie(negative_ratio, positive_ratio): pie Pie(校园微博负面舆情占比) pie.add( 舆情分布, [负面, 非负面], [negative_ratio, positive_ratio], is_label_showTrue, label_formatter{b}: {d}% ) return pie def render_bar(keyword_stats): bar Bar(各关键词负面微博条数) bar.add( 负面数量, list(keyword_stats.keys()), list(keyword_stats.values()), is_stackTrue ) return bar注意label_formatter{b}: {d}%{b}是名称{d}是百分比占比这行配置让饼图上的数据标签直接显示「负面: 23.5%」答辩展示的时候比只看颜色直观得多。如果你的环境装的是 pyecharts 1.x代码需要改成pie Pie().add(, [list(z) for z in zip(labels, values)])的新式写法。建议直接参照项目里原有的写法pip 安装对应版本pip install pyecharts0.5.6。图表生成后是独立的 HTML 文件Flask 后端把它嵌入后台首页的 iframe 里展示。核心点是图表文件要生成在templates/目录下否则 Flask 渲染时会找不到模板而报错。6. 避坑与验收五个真坑和一份自检清单6.1 环境与依赖的五个踩坑记录第一个坑是数据库导入乱码。现象是导入 .sql 文件后登录页面正常但查出来的中文全是问号。原因是建库时字符集选了 utf8 而不是 utf8mb4或者 .sql 文件本身的编码就是 GBK。解决方法是删库重建用 Navicat 建库时手动把字符集选成 utf8mb4导入前再检查文件的编码格式VSCode 右下角能看到文件编码。第二个坑是 pyecharts 图表空白页。现象是饼图能生成 HTML 文件但浏览器打开是一片空白。原因是 0.5.6 版本默认引用的是 CDN 上的 echarts.min.js答辩现场的电脑如果没联网JS 加载失败自然白屏。解决方法是去 echarts 官网下载 echarts.min.js 放到 static 目录然后把 pyecharts 的jshost改成本地路径。第三个坑是 Flask 返回的 Excel 下载乱码。现象是导出的 CSV 文件用 Office 打开中文乱码。原因是 Python 默认写入的编码是 utf-8而 Windows 的 Excel 要求 GBK 编码才能正确显示中文。解决方法是写入时加\ufeffBOM 头或者用encodinggbk后者要注意部分字符 GBK 编码不支持会直接报编码错误。第四个坑是 MySQL 连接超时。现象是系统刚部署完能正常访问放了一晚上第二天就会报TimeoutError或者MySQL server has gone away。原因是连接池里的长连接空闲超过了 MySQL 的wait_timeout默认值 8 小时。解决方法是每次操作数据库前判断连接是否存活失效就重连不要一个连接用到底。第五个坑是爬虫 URL 编码问题。现象是关键词带中文时返回 414 Request-URI Too Long。原因是build_url函数里关键词做 URL 编码后仍然拼接在 URL 路径里把超长参数塞进了请求行。解决方法是改成 params 传参方式让 requests 库自己处理编码。6.2 验收自检清单与收尾系统跑通后做一次完整的验收照着下面这份清单走一遍能帮你提前发现答辩时可能被当场戳穿的隐藏问题。登录模块输入错误密码能返回提示未登录直接访问/index会被重定向回登录页修改密码后旧密码失效。爬虫模块换个从来没爬过的关键词能正常返回数据连续翻 5 页不触发微博风控重复爬取同一关键词不会产生重复数据。分析模块一条明显负面的「学校食堂太垃圾了」和一条正面微博分析结果有明显区分。预警模块把阈值改到 1% 能立刻触发预警改回 20% 后正常微博不会误报。可视化模块断网状态下饼图和柱状图依然能正常渲染图表上的百分比和数据库t_sentiment表里的数值能对得上。这套资源我拆完最大的感受是爬虫和分析两个模块做得够扎实关键词爬取和词典分析的设计确实能跑。但毕业设计最怕的不是功能少而是跑不起来。从那以后我接手任何源码目录第一件事永远是先看 requirement.txt 和 SQL 脚本再动手配环境这个顺序能帮你在拆包时少走一半弯路。希望这篇拆解对你有帮助。本文还有配套的精品资源点击获取