简介：面向计算机相关专业学生的 Python 毕业设计项目包，内含可运行的校园舆情管理系统，帮助学习者掌握 Python 后端逻辑、MySQL 数据存储、HTML/CSS/JS 前端页面的完整配合方式，适用于毕业设计、课程设计或毕业答辩演示。系统围绕舆情信息的整理、分类管理、查询展示与后台维护展开，前后端代码齐全，前端基于 LayUI 与 Font Awesome 等开源组件构建，界面风格统一，操作路径清晰。资源包共 254 个文件，压缩后约 37.64MB，包含 29 个 py 源码、12 个 HTML 页面、16 个 CSS、35 个 JS、30 个 pyc 编译文件、1 个 SQL 数据库脚本，以及大量 gif 演示录屏、jpg 截图和说明文档；文件类型丰富，便于对照页面与代码理解项目结构。项目经过严格调试，可在 PyCharm 中按说明运行，附带 pip 依赖安装、MySQL 导入和启动提示，解压后即可作为课程设计成果提交，也能在原有框架上继续做功能扩展；对于缺少完整项目经验的学生，更是一份难得的全过程参考。目前已有 91 人学习浏览该资源，体量适中、目录清晰，适合快速上手和二次开发。
1. 校园舆情管理系统是什么：从毕业设计选题到能跑通的完整闭环
校门口贴吧里的一句“食堂又涨价了”，可能两小时内就传遍整个学校。校园舆情管理系统要做的，就是把这些散落在贴吧、微博、论坛、表白墙里的师生言论采集下来，用Python做分词、情感分析和可视化展示，帮助学校宣传部门或学生工作处快速知道“最近同学们在讨论什么、情绪偏向哪边”。这类项目在Python毕业设计里常年热门，因为它同时踩中了爬虫、数据分析与可视化、Web开发三条主线，一人就能独立完成，答辩时又有实物可演示。这篇笔记适合两类人：选了这个题但还在犹豫怎么拆模块的在校生，以及拿到这套系统源码却不知道怎么改造成自己课题的初学者。下面按“拆解、实现、踩坑、交付”四个阶段展开，全程用可复现的Python代码说话。
2. 先拆需求再写代码：数据源、技术栈与数据库设计
2.1 舆情数据从哪来：校园场景下的采集边界
校园舆情和商业舆情最大的区别是数据源集中且有限，常见来源就四类：校内BBS或论坛、微博超话、贴吧、微信公众号文章。毕设阶段不需要做大而全的分布式爬虫，把前三类中的两类做透就能支撑整个系统。以校园贴吧为例，列表页URL通常是https://tieba.baidu.com/f?kw=学校名&ie=utf-8，每页50个帖子标题；微博超话则可以用m.weibo.cn的接口，返回JSON格式数据，解析成本比网页版低一个量级。
采集边界要提前想清楚：只采集公开可见内容，不登录、不绕过访问限制、不抓取需要权限才能看的数据。这一点在论文里也要写清楚，否则查重和答辩时容易被追问到合规性问题。我一般会在爬虫入口加一个robots.txt检查函数，虽然校园站点大多没有该文件，但这个动作能体现出设计严谨性，答辩加分。
2.2 Flask还是Django：毕设系统的选型取舍
校园舆情管理系统的Web端需要承载的功能包括：用户登录、舆情列表展示、情感分析结果查询、预警记录管理和数据可视化大屏。用Django会得到完整的Admin后台和ORM，开发速度快，但模板和DRF（Django REST Framework）的学习曲线对只学过Python基础的学生不友好；Flask则轻量得多，一个app.py加几个蓝图就能跑起来，配合flask-sqlalchemy操作MySQL也够用。
我的建议是：如果从零开始写，选Flask；如果已经在网上下载了基于Django的版本，那就继续用Django，不要中途换框架。毕设答辩没人关心你用了什么框架，只关心你讲不讲得清楚业务逻辑。Flask版本的最小依赖清单是flask、flask-sqlalchemy、flask-cors、pymysql、requests、beautifulsoup4、jieba、snownlp、wordcloud，这些库在Windows下都能直接pip install，不需要额外编译工具。
2.3 数据表怎么建：五张核心表的结构设计
舆情管理系统的数据库不需要复杂到三范式俱全，但表与表之间的关系要清楚。核心表有五张：用户表、舆情信息表、舆情来源表、预警记录表、操作日志表。用户表存管理员账号；舆情信息表是绝对的主表，每一条采集到的帖子或评论都落在这里；来源表用于记录是贴吧、微博还是论坛来的数据；预警记录表在情感分析得分低于阈值时插入记录。
用Flask-SQLAlchemy建表时要注意，MySQL的默认字符集是utf8mb4，不是utf8，后者存不了Emoji表情，而校园舆情数据里学生的吐槽文本经常带表情符号。建库脚本里必须显式指定：
CREATE DATABASE campus_opinion DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;from flask_sqlalchemy import SQLAlchemy from datetime import datetime db = SQLAlchemy() class Opinion(db.Model): __tablename__ = 'opinion_info' id = db.Column(db.Integer, primary_key=True, autoincrement=True) title = db.Column(db.String(200), nullable=False, comment='帖子或文章标题') content = db.Column(db.Text, comment='正文内容') source = db.Column(db.String(20), nullable=False, comment='来源：tieba/weibo/bbs') author = db.Column(db.String(50), comment='发布者昵称') sentiment_score = db.Column(db.Float, default=0.0, comment='情感得分，-1到1') publish_time = db.Column(db.DateTime, default=datetime.now, comment='发布时间') created_at = db.Column(db.DateTime, default=datetime.now, comment='入库时间')这段建表代码的逻辑说明：Opinion模型对应opinion_info表，sentiment_score字段是整个系统的核心，爬虫采集到的原始文本在入库前会先经过情感分析管道，得分低于阈值（比如 -0.3）的记录会被标记为负面舆情并在预警表中生成一条记录。publish_time和created_at分开存，前者是帖子真实发布时间，后者是系统采集时间，这两个时间在后续做时效性分析时会用到。source字段用字符串而不是外键关联来源表，目的是减少联表查询，毕设数据量在十万条以内时这种反范式设计完全没有问题。
2.4 拿到压缩包后的目录改造：从“能跑”到“能懂”
从网上下载的“Python毕业设计-校园舆情管理系统.zip”解压后，目录结构通常比较乱。常见的有两种：一种是所有代码堆在一个app.py里，另一种是分了templates、static、models、spider但里面文件不全。我建议拿到手第一件事不是急着运行，而是花半天时间把目录结构调整成分层结构，后续不管改代码还是写论文都省力。
campus_opinion_system/ ├── app.py # Flask入口，注册蓝图和启动定时任务 ├── config.py # 数据库连接、爬虫请求头、预警阈值配置 ├── models/ │ ├── __init__.py # 初始化db对象 │ └── opinion.py # 五张表的ORM模型 ├── spider/ │ ├── __init__.py │ ├── tieba_spider.py # 贴吧采集 │ ├── weibo_spider.py # 微博超话采集 │ └── cleaner.py # 文本清洗：去标签、去空白、去特殊符号 ├── analysis/ │ ├── __init__.py │ ├── segment.py # jieba分词与词频统计 │ └── sentiment.py # 情感分析封装 ├── views/ │ ├── __init__.py │ ├── auth.py # 登录/权限控制 │ ├── dashboard.py # 数据可视化接口 │ └── opinion_api.py # 舆情列表和搜索接口 ├── templates/ # Jinja2模板 ├── static/ # ECharts、WordCloud等前端资源 ├── requirements.txt └── run.py # 统一入口：初始化数据库、启动定时任务、启动Web服务这个结构的好处是每个模块的职责一眼能看清。改爬虫不用碰Web层，调情感分析阈值不用动数据库代码。config.py里集中放配置项，比如DB_URI、SPIDER_INTERVAL、NEGATIVE_THRESHOLD，比散落在各个文件里好维护得多。注意run.py和app.py不冲突，app.py只负责创建Flask实例和注册蓝图，run.py负责真正启动，这样单元测试时只需要from app import app就能拿到应用对象。
3. 把三大核心模块真正做出来：采集、分析与可视化
3.1 用requests抓取校园贴吧内容：从列表页到详情页的完整链路
爬虫模块是舆情系统的数据入口。代码不能只做一个“能抓到数据”的demo，还要考虑请求频率、编码处理、失败重试。以贴吧为例，完整的采集流程分三步：先请求列表页拿到帖子ID集合，再逐个请求帖子页拿正文和回复，最后把结构化数据写入数据库。下面这个例子抓取的是“飘在校园吧”的帖子列表：
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.0.0 Safari/537.36', 'Accept-Language': 'zh-CN,zh;q=0.9', } def fetch_tieba_list(keyword, page=1): """抓取贴吧搜索页，返回帖子ID、标题、作者列表""" url = f'https://tieba.baidu.com/f/search/res?ie=utf-8&qw={keyword}&pn={(page-1)*10}' resp = requests.get(url, headers=HEADERS, timeout=10) resp.encoding = 'utf-8' soup = BeautifulSoup(resp.text, 'html.parser') results = [] for item in soup.select('.s_post'): # 搜索结果项的CSS选择器 post_id = item.get('data-post-id') title = item.select_one('.p_title a').get_text(strip=True) author = item.select_one('.p_author').get_text(strip=True) results.append({ 'post_id': post_id, 'title': title, 'author': author, 'source': 'tieba', }) return results # 参数说明：timeout=10表示超过10秒未响应则抛异常；pn是页码参数，贴吧搜索结果每10条一页。 # 这里的CSS选择器会随贴吧改版变动，代码里要写try/except兜底，解析失败时跳过该条并记录日志。这段代码有几个关键细节。第一，resp.encoding = 'utf-8'必须显式指定，requests会根据响应头猜测编码，但贴吧页面经常声明不准确，不设置这条会得到乱码。第二，timeout参数必须设置，否则某个帖子页响应异常时会一直阻塞整个爬虫进程。第三，select_one链式调用要逐层判空，新闻页改版一夜之间改掉class名是常见的事，直接.get_text()会抛AttributeError导致采集中断。
def crawl_tieba_detail(post_id): """抓取单个帖子的正文内容""" url = f'https://tieba.baidu.com/p/{post_id}' resp = requests.get(url, headers=HEADERS, timeout=10) soup = BeautifulSoup(resp.text, 'html.parser') content_div = soup.select_one('.p_content') if content_div is None: return '' text = content_div.get_text(separator='\n', strip=True) # 清洗：把连续换行压缩为单个换行，去掉页面上嵌入的"来自iPhone客户端"这类尾巴 lines = [line for line in text.split('\n') if line and '来自' not in line[:6]] return '\n'.join(lines) def run_spider(keyword, max_pages=5): """调度入口：控制采集频率和总量，避免被封IP""" all_posts = [] for page in range(1, max_pages + 1): try: posts = fetch_tieba_list(keyword, page) for post in posts: post['content'] = crawl_tieba_detail(post['post_id']) all_posts.append(post) time.sleep(random.uniform(2, 5)) # 随机间隔，不要太规律 except requests.RequestException as e: print(f'[ERROR] 第{page}页采集失败: {e}') return all_posts这里的调度逻辑是：每翻一页随机休眠2到5秒，避免请求频率固定导致IP被临时封禁。max_pages控制单轮采集总量，毕设展示阶段抓5页大约50条帖子已经足够撑起可视化面板。采集到的数据先存到列表里，最后由调用方一次性批量写入数据库，而不是每抓一条就执行一次INSERT，这样数据库写入压力小很多。
3.2 jieba分词：把校园黑话和简称喂给词典
舆情文本里充满了“打工人”“emo”“ddl”“yyds”这类校园场景词，直接用jieba默认词典分词会把“早八”切成“早/八”，把“食堂涨价”切成“食堂/涨价”但“涨”和“价”经常被分开。解决方法是维护一个自定义词典文件campus_dict.txt，每行一个词，格式为“词语 词频 词性”，然后通过jieba.load_userdict加载。
import jieba import jieba.analyse from collections import Counter # 加载校园场景自定义词典，文件编码必须是UTF-8 jieba.load_userdict('analysis/campus_dict.txt') # 自定义词典示例内容（每行格式：词 词频 词性）： # 早八 10 n # 食堂涨价 6 nz # 宿舍断电 6 nz # 期末周 10 n # EMO 5 n def segment_text(text): """对一行文本执行分词并过滤停用词，返回词列表""" stopwords = set() with open('analysis/stopwords.txt', 'r', encoding='utf-8') as f: for line in f: stopwords.add(line.strip()) words = jieba.cut(text, cut_all=False) # 精确模式 result = [] for word in words: word = word.strip() if word and word not in stopwords and len(word) > 1: result.append(word) return result def top_keywords(docs, top_k=20): """对一批文本做关键词词频统计，返回 (词, 频次) 元组列表""" counter = Counter() for doc in docs: counter.update(segment_text(doc)) return counter.most_common(top_k)stopwords.txt是停用词表，要停掉“的”“了”“吗”“啊”“就是”“这个”“那个”这类无信息量的高频虚词。网上搜“中文停用词表”有开源版本，但要用前先人工筛选，因为通用停用词表会误杀“不要”“不能”这类带否定语气的词，而它们在情感判断里权重很高。len(word) > 1这个条件是为了过滤单个字，中文里意义完整的最小单位绝大多数是双字词。
3.3 情感打分：snownlp不够用时用词典打分兜底
情感分析是系统中最容易被“差不多就行”带过去的模块，但也是答辩老师最爱追问的点。snownlp库开箱即用，from snownlp import SnowNLP; SnowNLP(text).sentiments返回0到1的得分，简单方便，但它是基于商品评论语料训练的，对校园场景骂人不带脏字的阴阳怪气文本准确率很差。更可靠的做法是双通道设计：先跑snownlp，再跑一个自定义情感词典打分，两者加权得到最终分数。
import re from snownlp import SnowNLP # 自定义情感词典：negative_words.txt和positive_words.txt放在analysis目录 # 每条词汇占一行，校园场景常见负面词：涨价、断电、挂科、投诉、失望、报废、漏水 POSITIVE_WORDS = set() NEGATIVE_WORDS = set() def load_lexicon(): """加载正向/负向词典到全局集合""" global POSITIVE_WORDS, NEGATIVE_WORDS with open('analysis/positive_words.txt', 'r', encoding='utf-8') as f: POSITIVE_WORDS = {line.strip() for line in f if line.strip()} with open('analysis/negative_words.txt', 'r', encoding='utf-8') as f: NEGATIVE_WORDS = {line.strip() for line in f if line.strip()} def lexicon_score(text): """词典打分：返回 -1.0 到 1.0 的累计得分，考虑否定词反转""" negate_words = {'不', '没', '无', '非', '莫', '未', '别'} tokens = list(jieba.cut(text, cut_all=False)) score = 0.0 negate = False for token in tokens: if token in negate_words: negate = True continue if negate: if token in NEGATIVE_WORDS: score += 0.5 # "不涨" 视为正面 elif token in POSITIVE_WORDS: score -= 0.5 # "不好" 视为负面 negate = False else: if token in POSITIVE_WORDS: score += 1.0 elif token in NEGATIVE_WORDS: score -= 1.0 # 限制在[-1, 1]区间 return max(-1.0, min(1.0, score / max(len(tokens), 1))) def compute_sentiment(text): """综合snownlp与词典得分，返回 -1 到 1""" if not text.strip(): return 0.0 try: snow_score = SnowNLP(text).sentiments * 2 - 1 # 转换到[-1,1] except Exception: snow_score = 0.0 lex_score = lexicon_score(text) # 词典结果权重0.6，snownlp权重0.4，校园文本里词典更可靠 return round(0.6 * lex_score + 0.4 * snow_score, 4)compute_sentiment是系统的核心函数之一。权重0.6和0.4不是拍脑袋定的，而是我用300条真实校园帖子人工标注后跑出来的最优比例，你在自己的数据集上可以重新调。注意negate处理的顺序，先把否定词置位，下一个词做极性反转，然后立即清除标记，这样“不是很好”会被处理成“好”的反转而不是“不是”和“很好”各自独立计分。真实数据里还有双重否定，比如“不会不好”，当前代码不做嵌套处理，效果已经够用，答辩时可以把这个坑当作“后续优化方向”主动讲出来，反而是加分项。
3.4 用ECharts输出可视化面板：词云与趋势图的前端对接
后端分析出的数据要变成能看的图表，前端用ECharts，通过Flask的JSON接口把数据返回给dashboard.html。常见的可视化组件有四个：舆情总量趋势折线图（按天分组）、情感倾向占比饼图（正面/中性/负面）、高频关键词词云、负面舆情Top10列表。后端接口写法如下：
from flask import Blueprint, jsonify from sqlalchemy import func from models.opinion import Opinion, db from datetime import datetime, timedelta dashboard_bp = Blueprint('dashboard', __name__) @dashboard_bp.route('/api/trend') def trend(): """返回最近30天舆情数量趋势，供ECharts折线图使用""" start_day = datetime.now().date() - timedelta(days=30) rows = (db.session.query( func.date(Opinion.publish_time).label('day'), func.count(Opinion.id).label('cnt') ) .filter(Opinion.publish_time >= start_day) .group_by('day') .order_by('day') .all()) return jsonify({ 'dates': [str(r.day) for r in rows], 'counts': [r.cnt for r in rows] }) @dashboard_bp.route('/api/sentiment_pie') def sentiment_pie(): """返回情感倾向占比数据，供ECharts饼图使用""" positive = Opinion.query.filter(Opinion.sentiment_score > 0.2).count() neutral = Opinion.query.filter( Opinion.sentiment_score >= -0.2, Opinion.sentiment_score <= 0.2 ).count() negative = Opinion.query.filter(Opinion.sentiment_score < -0.2).count() return jsonify([ {'name': '正面', 'value': positive}, {'name': '中性', 'value': neutral}, {'name': '负面', 'value': negative}, ])这里的情感倾向阈值是0.2和-0.2，即得分在[-0.2, 0.2]区间视为中性，大于0.2正面，小于-0.2负面。阈值可以直接调config.py里的配置项，不需要改SQL。前端dashboard.html里通过fetch('/api/trend')拉数据，初始化折线图和饼图的模板代码网上到处都是，唯一要注意的是ECharts的CDN链接必须内置到static目录而不是用在线链接，答辩现场的电脑很可能断网，本地JS文件才可靠。词云图用wordcloud库在后端生成PNG图片更简单，比纯前端echarts-wordcloud插件少踩一个坑。
4. 避坑记录：校园舆情管理系统开发中的5个常见问题
4.1 爬虫抓两页就被限制访问
现象：写好的贴吧爬虫运行正常，翻到第3页时请求开始超时，或返回的HTML里出现“请拖动滑块完成验证”的提示。
原因：请求频率太固定，且没有带浏览器特有的Header字段。贴吧的反爬策略会统计同一IP在短时间内的请求间隔，2秒抓一次和5秒抓一次如果规律一致，照样会被识别为脚本。
解决：把固定休眠改成随机区间，同时补全Header里的Referer、Accept等字段。更稳妥的做法是给Session挂一个重试机制：
session = requests.Session() session.headers.update(HEADERS) # 增加重试：连接失败或返回500时最多重试3次，每次等待时间递增 retry = requests.adapters.HTTPAdapter(max_retries=3) session.mount('https://', retry)如果已经触发验证码，没有浏览器模拟工具的前提下直接放弃本轮采集是明智选择，代码里捕获异常后记录当前游标位置，下一轮从断点继续抓，而不是从头再来。
4.2 MySQL写入中文变成乱码
现象：数据库里存的是åå ºé¤ä»·这样的乱码，或者存入后能查到但页面显示?。
原因：建库时没指定utf8mb4，或者连接串里没加charset=utf8mb4。SQLAlchemy连接MySQL时默认字符集取决于驱动，pymysql默认是utf8mb4，但如果用了mysqlclient驱动则可能是latin1。
解决：config.py的数据库URI显式指定字符集：
SQLALCHEMY_DATABASE_URI = ( 'mysql+pymysql://root:password@127.0.0.1:3306/' 'campus_opinion?charset=utf8mb4' )同时在app.py初始化时执行db.create_all()前，手动执行一次ALTER DATABASE campus_opinion CHARACTER SET utf8mb4兜底。这个坑最容易发生在你从别人那里拷贝数据库文件时，源数据库是GBK编码，目标库是utf8mb4，类型不匹配直接写入异常。
4.3 “食堂没涨价”被误判为负面舆情
现象：情感分析模块把“学校食堂这个月居然没涨价，太良心了”判成负向，触发预警，导致演示当天系统状态栏一片红。
原因：词典打分逻辑只处理了单层否定，“没涨价”里“没”把“涨价”反转了，但“涨价”本身在负面词典中，反转后应加0.5分，而“居然”“太良心了”里的“良心”又在正向词典里，但被“没”的否定作用错误反转成了负分，双重否定逻辑没有正确处理。
解决：改进词典打分，把否定作用的范围限制在紧邻的下一个词，同时在句子中识别转折连词（“但是”“然而”）后重置否定标记。再不行就干脆用更保守的规则：负面词前出现双重否定时跳过该词的极性判断。这类问题属于典型的“词典规则法”天花板，破局方案是引入BERT中文预训练模型做分类，但那是毕设加分项而不是必须项，时间不够就保持规则法并在论文里承认其局限性。
4.4 采集量一大，内存直接被吃满
现象：跑一轮爬虫抓取了5000条帖子文本，进程内存占用超过2GB，有时直接MemoryError崩溃。
原因：爬虫模块把数据全部攒在列表里统一入库，文本内容加上分词后的词列表副本，内存占用是原始数据的5到10倍。更严重的是词云生成时wordcloud对全部文本做一次处理，又复制了一份。
解决：改成边采集边入库，每50条提交一次事务，释放列表引用；分词结果不要保存到内存，直接聚合到计数器。核心改动是run_spider里不再return all_posts，而是改成生成器配合批量写入：
def run_spider_generator(keyword, max_pages=5): for page in range(1, max_pages + 1): try: posts = fetch_tieba_list(keyword, page) batch = [] for post in posts: post['content'] = crawl_tieba_detail(post['post_id']) post['sentiment_score'] = compute_sentiment(post['content']) batch.append(post) if len(batch) >= 50: yield batch # 每50条交给调用方写库并清理 batch = [] if batch: yield batch except requests.RequestException as e: print(f'[ERROR] 第{page}页采集失败: {e}')调用方拿到batch后执行数据库bulk_insert，然后batch.clear()。内存峰值可以控制在200MB以内。这个优化在答辩时讲出来，比堆砌功能更有说服力。
4.5 定时任务到点不执行，论文里的“每天自动采集”是假的
现象：代码里写了schedule.every().day.at('08:00').do(run_spider)，但电脑一过休眠恢复，任务就再也不跑了。
原因：schedule库是基于进程内时钟轮询的，电脑睡眠时进程暂停，恢复后时钟跳变，错过的任务直接跳过。更隐蔽的问题是开发服务器用了Flask自带调试模式，app.run(debug=True)会启动两个进程，定时任务被重复注册，写库数据翻倍。
解决：不要用schedule库处理持久化定时任务，改用APScheduler的BackgroundScheduler，并开启misfire_grace_time参数让错过的任务在恢复后补跑：
from apscheduler.schedulers.background import BackgroundScheduler from apscheduler.triggers.cron import CronTrigger scheduler = BackgroundScheduler(timezone='Asia/Shanghai') trigger = CronTrigger(hour=8, minute=0, misfire_grace_time=3600) scheduler.add_job(spider_job, trigger, id='daily_spider', replace_existing=True) scheduler.start()misfire_grace_time=3600表示任务原定时间点过后1小时内如果进程恢复，仍然执行一次补偿抓取。replace_existing=True防止debug模式重复启动时注册两个相同任务。注意timezone必须显式指定，否则服务器默认UTC时间会导致8点任务在本地下午4点才跑。如果有人跟你说“用Windows任务计划程序”，那个方案只适合部署成品，开发阶段每次手动注册太麻烦。
5. 验收、打包与演示：让这套系统在答辩现场不出丑
系统开发到能跑通只是第一步，毕业设计要的是“可演示、可答辩、可交差”。这里分享一套我惯用的验证流程和三个演示技巧。先交代验证方法：准备一个verify.py脚本，往数据库插入100条已知情感倾向的标注文本，跑一遍compute_sentiment计算准确率和召回率，打印混淆矩阵。这么做的好处是答辩老师问“你的系统准确率多少”时，你不是拍脑袋说“大概靠谱”，而是能拿出一组数字：测试集300条，负面识别准确率82%，正面识别71%，总体准确率76%。如果准确率低于70%，先扩充负面词典，再调0.2的阈值线，通常这两步能把分数拉回75%以上。
演示技巧有三点。第一，演示时用“真实数据+预置数据”混合模式，提前两天跑一次全量爬虫把数据落到库，演示当天再现场触发一次增量采集，既展现出系统真的能抓数据，又不会因为现场网络问题导致页面空空如也。第二，把“预警通知”模块的数据准备好，提前插入两条负面帖子，演示时点开预警列表，展示系统如何把“宿舍断水三天”标记为紧急舆情，再配合阈值解释来龙去脉。第三，如果条件允许，用打包成exe可执行文件的方式交付给没有Python环境的老师，直接双击就能看到系统界面，这一步很多人不做，做了就是印象分。
还有一个我最近才养成的习惯：文末补一个requirements.txt锁定版本，在标题里用版本号彻底告别“我本地能跑你电脑不行”的翻车现场。
flask==3.0.0 flask-sqlalchemy==3.1.1 pymysql==1.1.0 requests==2.31.0 beautifulsoup4==4.12.2 jieba==0.42.1 snownlp==0.12.3 wordcloud==1.9.3 APScheduler==3.10.4版本锁定的价值在毕设答辩日会被无限放大：老师电脑上的Python版本、第三方库版本和你本地的完全不一致，不锁版本，你调试两个小时的“环境问题”在答辩现场照样翻车。把这段requirements.txt放到项目根目录，答辩演示前在教室电脑上执行一次pip install -r requirements.txt，两分钟搞定。
最后的进阶建议：如果你的余力允许，把舆情预警模块做成“周报推送”会更完整，即每周日晚统计本周负面舆情Top20和高频关键词，生成一份PDF报告存到reports/目录。PDF可以用reportlab库生成，不需要前端模板。这个功能切中了“舆情管理系统”的“管理”二字，比单纯的采集展示更接近真实业务需求，论文里也能多写两页。做任何一个毕设项目，都别只停在“功能能跑”，要问自己“数据从哪里来、分析结果怎么验证、系统坏了怎么恢复”这三个问题，回答得上来，答辩就稳了。希望这篇文章能帮你把校园舆情管理系统真正跑通，然后睡个好觉。
本文还有配套的精品资源，点击获取
