Python毕业设计实战：校园舆情管理系统开发指南

简介：面向Python毕业设计与课程设计的《校园舆情管理系统》完整项目包，适合准备毕设或课设选题、想直接运行一个Web系统的在校生。项目基于Python 3.7开发，前端使用HTML与layui组件，后台逻辑完整，数据库采用MySQL，可通过Navicat可视化操作。功能模块贴合校园舆情管理场景，界面简洁统一，适合答辩演示和继续扩展。压缩包共254个文件，大小约37.64MB。主要包含Python源码与pyc编译文件、html/css/js前端页面、jpg/png/gif界面素材、sql数据库脚本、txt及md说明文档，以及woff/ttf等字体图标资源。前后端代码齐全，目录结构清楚；sql脚本可快速建表，配合PyCharm打开项目并用pip安装依赖后即可运行，项目调试已通过验证。目前已有91人浏览学习。对需要完成Python毕业设计或课程设计的读者而言，整套项目能提供从数据库到后台、再到前端展示的完整参考，减少从零搭建的时间；无论是功能模块设计还是开发环境配置，都有直接借鉴和复用的价值。

1. 校园舆情管理系统：Python 毕业设计里最容易被低估的实战题

又是一个选毕业设计的季节。我在工作室接过不少改毕设的单子，发现很多人第一反应是学生管理系统、购物车、图书借阅系统，结果答辩时一开口就是“增删改查”。相比之下，校园舆情管理系统这个题目被低估得很厉害——它把爬虫、文本分析、后端 API、可视化大屏串在了一条业务线上，一套代码能覆盖你本科阶段大部分技能点。它要解决的问题很具体：以学校为单位，采集校园论坛、贴吧、表白墙等公开页面的言论，判断每条内容是正面、负面还是中性，抽取高频关键词，最后用图表展示舆论走势和热点话题。无论你是做 Python 课程设计，还是要把项目扩展成毕业设计，这套 Python 源码的骨架都足够清晰，而且每一层都能单独拿出来讲深。

2. 技术选型与数据模型：Flask + MySQL 怎么搭才不翻车

2.1 选型逻辑：为什么是 Flask 而不是 Django

做舆情管理系统，技术选型的第一原则不是“哪个框架时髦”，而是“哪条技术栈你能在答辩时讲清楚”。Django 自带 admin 后台，确实能省不少事，但舆情系统的核心不在后台管理，而在数据采集和分析接口；Django 的模型、中间件、信号机制套进来，很多同学连目录结构都解释不明白。Flask 轻量、灵活，路由和蓝图的结构清晰，适合把采集中间件、情感分析、关键词提取都封装成独立模块。

数据库方面，我建议直接上 MySQL 而不是 SQLite。SQLite 零配置，单机跑起来很舒服，但舆情数据要反复写入、查询、按时间聚合，SQLite 的并发写入表现偏弱；毕业设计评审核查时，MySQL 也能顺便体现你对数据库表结构和索引设计有概念。下面是两者对比，给你写文档时直接用。

2.2 核心表结构：一张舆情表撑起整条业务链

数据模型是整个系统的地基。我在设计和改造这类项目时，习惯只保留五张核心表，避免过度设计：用户表、舆情信息表、敏感词表、采集日志表、关键词统计表。其中舆情信息表是最核心的，采集的标题、作者、发布时间、正文摘要、数据来源、情感标签、情感分数、关键词都在这一表里。

建表脚本我按 MySQL 8.0 的语法写，直接在命令行 source 导入即可。字符集必须用 utf8mb4，否则中文表情包和生僻字入库后会变成问号。

CREATE DATABASE IF NOT EXISTS campus_sentiment DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE campus_sentiment; CREATE TABLE IF NOT EXISTS t_user ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, role TINYINT NOT NULL DEFAULT 1 COMMENT '1:admin 2:viewer', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE IF NOT EXISTS t_sentiment_info ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, title VARCHAR(200) NOT NULL, author VARCHAR(50) DEFAULT '', platform VARCHAR(20) NOT NULL COMMENT 'website/forum/weibo', source_url VARCHAR(500) NOT NULL, content_summary TEXT, publish_time DATETIME DEFAULT NULL, crawl_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, sentiment_type TINYINT NOT NULL DEFAULT 1 COMMENT '0:neg 1:neu 2:pos', sentiment_score FLOAT NOT NULL DEFAULT 0.5, keyword VARCHAR(50) DEFAULT '', is_deleted TINYINT NOT NULL DEFAULT 0, UNIQUE KEY uk_source_url (source_url), KEY idx_publish_time (publish_time), KEY idx_sentiment_type (sentiment_type) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段 SQL 里有两个容易被忽略的参数：source_url 上的唯一索引，能直接挡住重复采集；sentiment_score 用 FLOAT 保存，是 SnowNLP 输出的 0 到 1 之间的概率值。publish_time 加普通索引，后面做时间趋势图时查询会快很多。

2.3 初始化数据库：命令行脚本与配置文件的连接

建完库之后，要把配置文件单独拆出来，方便换机器部署时只改一个文件。常见做法是维护一个 config.py，把数据库连接参数、爬虫请求间隔、阈值都放进去，而不是散落在各个模块。

# config.py import os class BaseConfig: SECRET_KEY = os.environ.get("SECRET_KEY", "dev-secret-key") # MySQL 连接参数 DB_HOST = os.environ.get("DB_HOST", "127.0.0.1") DB_PORT = int(os.environ.get("DB_PORT", 3306)) DB_USER = os.environ.get("DB_USER", "root") DB_PASSWORD = os.environ.get("DB_PASSWORD", "123456") DB_NAME = os.environ.get("DB_NAME", "campus_sentiment") # 数据库连接串 SQLALCHEMY_DATABASE_URI = ( f"mysql+pymysql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}" "?charset=utf8mb4" ) SQLALCHEMY_TRACK_MODIFICATIONS = False # 爬虫调度参数 CRAWL_INTERVAL_HOURS = 2 REQUEST_TIMEOUT = 10 RETRY_TIMES = 3

这里的连接串末尾必须带上 charset=utf8mb4，否则即使建库时指定了 utf8mb4，ORM 写入时也可能因为连接参数不对而出现中文乱码。DB_USER、DB_PASSWORD 不要写死成你自己的密码，答辩时环境变量取不到就提示使用者去改，不要嫌麻烦。

初始化数据库的流程我一般做成三步命令，这样换新机器时不会漏掉某一步：

mysql -u root -p < schema.sql python -c "from app import db; db.create_all()" python init_admin.py

第一行导入表结构，第二行让 SQLAlchemy 检查补充缺失的表，第三行初始化管理员账号。需要说明的是，第一行和第二行其实是重叠的；如果你已经通过 schema.sql 建了全部表，第二行可以跳过，但保留它能在你后来加表时自动创建，属于“后悔药”式的保险动作。

3. 舆情数据采集：Requests + 定时任务，别被验证码拦在半路

3.1 数据源优先级：找没有登录墙的公开页面

采集模块最容易翻车的地方不是代码，而是数据源选错。很多同学一上来就想抓微博热搜，结果登录墙、滑块验证码、封 IP 三座大山直接把项目压垮。校园舆情系统的目标不是抓全网，而是抓“关于这所学校”的内容，所以优先级应该是：学校新闻网、学校贴吧、校内论坛、表白墙公众号接口、微博按关键词搜索。前三个是公开页面，反爬弱；微博搜索需要 cookie，适合作为加分项，不建议作为主数据源。

我习惯把数据源配置也放进 config.py，每条源对应一个 pause 参数，表示两次请求之间的随机延时范围。下面是数据源优先级参考表。

3.2 抓取模块：Requests 请求 + BeautifulSoup 解析

采集层抽成一个 fetch_page 函数，不要直接写在视图函数里。请求要用合适的 User-Agent，超时和重试逻辑必须有；我见过太多人只用裸 requests.get，在校园网环境里一超时就抛异常，整个任务中断。下面的代码是项目里常用的请求模板，你可以直接抄进 crawl/loader.py。

# crawl/loader.py import random import time import requests from bs4 import BeautifulSoup from config import BaseConfig 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_page(url, retries=None, timeout=None): retries = retries or BaseConfig.RETRY_TIMES timeout = timeout or BaseConfig.REQUEST_TIMEOUT for attempt in range(1, retries + 1): try: # timeout 拆成连接和读取两个值，避免慢接口卡死 resp = requests.get(url, headers=HEADERS, timeout=(timeout, timeout)) if resp.status_code != 200: print(f"[crawl] HTTP {resp.status_code} on {url}") # 403 大多是反爬，重试意义不大，直接返回 if resp.status_code == 403: return None continue # 优先用页面自编码，避免 UTF-8 页面被误判 resp.encoding = resp.apparent_encoding return resp.text except requests.RequestException as exc: wait_time = 1 + (attempt - 1) * 2 print(f"[crawl] attempt {attempt} failed: {exc}, wait {wait_time}s") time.sleep(wait_time) return None

fetch_page 的逻辑很简单：先尝试请求，失败后指数退避重试。注意我把 timeout 写成了 (timeout, timeout)，这是 requests 库的规范用法，分别代表“连接超时”和“读取超时”。如果只传一个值，读取阶段挂起时依然会拖死整个定时任务。resp.apparent_encoding虽然比默认编码准，但它需要先读取一部分内容做探测，在大页面时会有额外耗时；好在舆情页面一般不大，这个成本可以接受。

拿到 HTML 后，用 BeautifulSoup 解析列表页，提取标题、链接、发布时间。解析时尽量找稳定的容器 class，不要拿标签层级硬卡，否则学校换一次模板，你的解析就崩了。

def parse_list_page(html, base_url="https://news.example.edu.cn"): soup = BeautifulSoup(html, "html.parser") items = [] for li in soup.select("ul.news_list li"): link = li.find("a") title = link.get_text(strip=True) if link else "" href = link.get("href", "") if link else "" full_url = urljoin(base_url, href) date_tag = li.find("span", class_="date") pub_date = date_tag.get_text(strip=True) if date_tag else None if title and full_url: items.append({ "title": title, "url": full_url, "publish_time": pub_date, "platform": "school_news" }) return items

解析函数重点关注两点：urljoin拼链接时能识别相对路径和绝对路径，避免手动拼字符串踩坑；publish_time先保留字符串格式，入库前再统一转成 datetime。列表里的每一项都要能被唯一 URL 去重，这个去重由第 2 章的 source_url 唯一索引兜底，但你在代码里也应该先查一次。

3.3 入库与去重：先查后插，别靠异常兜底

很多初学代码喜欢直接session.add，碰到重复就抛 DuplicateEntry 异常，然后 except 吞掉。这个做法虽然能跑，但会把正常任务和异常混在一起。更干净的写法是先查一次，命中则跳过，否则再插入。

# crawl/storage.py from models import db, SentimentInfo def save_if_not_exist(item: dict) -> bool: exists = SentimentInfo.query.filter_by(source_url=item["url"]).first() if exists: return False record = SentimentInfo( title=item["title"], source_url=item["url"], platform=item.get("platform", "unknown"), publish_time=parse_datetime(item.get("publish_time")), ) db.session.add(record) db.session.commit() return True

这段代码里的parse_datetime是工具函数，专门处理“2025-03-14 10:30”“2025/03/14”这类格式；解析失败时返回 None，不要抛异常中断整个采集流程。返回值 is_new 可以统计本轮新增数量，写进采集日志表。

3.4 定时调度：APScheduler 让采集自动转起来

如果只在启动时抓一次，系统演示完就成死数据了。毕业设计里最好加一个定时调度器，每隔几小时自动采一轮。APScheduler 是 Flask 生态里整合度比较高的方案，没必要自己造 while True 循环。

# scheduler.py from apscheduler.schedulers.background import BackgroundScheduler from apscheduler.triggers.interval import IntervalTrigger def start_scheduler(app): scheduler = BackgroundScheduler(timezone="Asia/Shanghai") scheduler.add_job( run_crawl_job, trigger=IntervalTrigger(hours=app.config["CRAWL_INTERVAL_HOURS"]), id="crawl_job", max_instances=1, coalesce=True, replace_existing=True, ) scheduler.start() return scheduler

run_crawl_job 是在独立函数里调用各个数据源的采集入口。这里三个参数值得说清楚：max_instances=1表示上一轮没跑完时，即使到了下一个时间点也不开新任务，避免数据源扛不住；coalesce=True表示把错过的任务合并成一次补跑，不会堆积；replace_existing=True配合固定 id，保障重复启动时不会注册两个同名任务。这个配置是血泪经验换来的——开发调试时 debug 模式会触发两次主进程，没有这些保护，定时任务会重复执行。

4. 情感分析与关键词提取：SnowNLP 和 jieba 的调参边界

4.1 为什么选轻量级算法：毕业设计不靠模型刷分，靠流程完整

情感分析部分，我经常被问：为什么不用 BERT、为什么不用百度的 ERNIE？这类预训练模型确实准确率高，但放在毕业设计里会带来三个麻烦：需要 GPU 或至少 16G 内存、答辩现场很难跑推理、评委问“你如何调优”时你得能讲出训练细节。校园舆情这个场景，数据量不大，文本偏短，SnowNLP 足够撑起全流程，而且它是一个可以读源码的库，答辩时能讲清楚情感分数是怎么来的。

相比直接用 TextBlob，SnowNLP 的好处是中文语境处理更顺手，内置了分词、情感、关键词、摘要算法，不需要额外组装。它的默认模型是在商品评论语料上训练的，所以对校园场景有很大偏差，但这个偏差恰好是你在论文里可以写“针对校园语料进行阈值调整与样本迁移”的素材。

4.2 情感分析：SnowNLP 的阈值不是 0.5 一锤子买卖

默认情况下，SnowNLP 的sentiments属性返回 0 到 1 的值，越接近 1 表示越积极。很多教程直接拿 0.5 当分界线，实际会翻车。我用真实校园语料测试过，“食堂涨价了很难受”得 0.2 问题不大，但“学校新增自习区”这种偏中性表述经常被压到 0.5 以下。所以不能只拿 score 和 0.5 比，要引入“中性带”处理。

# analysis/sentiment.py from snownlp import SnowNLP def analyze_sentiment(text: str): if not text or len(text.strip()) < 2: return 1, 0.5 # 空文本直接判中性 try: score = SnowNLP(text).sentiments except Exception as exc: print(f"[sentiment] error: {exc}") return 1, 0.5 if score >= 0.7: return 2, score # 积极 if score <= 0.3: return 0, score # 消极 return 1, score # 中性

这里把积极和消极的阈值都上调/下压到 0.7 和 0.3，中间 0.3-0.7 全部算中性。这样做损失了一些判断精度，但解决了最尴尬的“把中性文本硬分成正面或负面”的问题。实际项目里阈值不是一个绝对数，你需要先跑一批数据，把 score 分布打印出来，再决定上下限。打印分布的方式不复杂：采集 200 条文本，把 score 逐一记录，观察 0.4-0.6 区间占多少。如果这个区间特别大，说明当前语料大多需要标中性，阈值区间也应该放宽。

4.3 关键词提取：jieba TF-IDF 的 topK 怎么选

关键词提取用 jieba 自带的 TF-IDF 算法就够了，不需要额外装 sklearn。TF-IDF 能削弱“学校”“同学”这类高频却无意义的词，比单纯词频统计合理得多。

# analysis/keyword.py import jieba.analyse def extract_keywords(text: str, top_k: int = 10): if not text: return [] # 加载自定义词典，里面是你从网站名和学校名提取的词表 jieba.analyse.set_stop_words("data/stopwords.txt") tags = jieba.analyse.extract_tags(text, topK=top_k, withWeight=False) return tags

参数 topK 选多少取决于展示场景。做词云时 20 个词会太杂，10 个左右更清晰；做热点列表时 8 个就够了。withWeight 如果设为 True 会返回 (word, weight) 元组，但权重绝对值意义不大，我更建议只拿词，权重用于以后做时间轴热度曲线。需要注意，jieba.analyse 的 stopwords 文件是每行一个词，必须用 UTF-8 编码保存；网上很多 stopwords 合集是 GBK 编码，读进来直接乱码，这是踩过的坑。

4.4 数据闭环：把误判样本变成自定义词典

情感分析不是一次性代码，它对特定学校的语料需要持续微调。我在做这套系统时会加一个后台报表，专门展示“低置信度”样本：score 在 0.35-0.65 之间、但被当前规则判了中性的文本。管理员每周看一次，把明显消极的句子挑选出来，加入敏感词表或自定义训练集。这个功能实现起来不复杂，就是在情感分析的记录表里多存一个 sentiment_score，然后后台 SQL 按分数范围筛选即可。把这个闭环写进论文，比单纯贴代码更有说服力。

5. 避坑指南：校园舆情项目最常见的五个翻车点

5.1 现象：MySQL 里中文全部变成问号

第一次入库后，打开数据表看到????????，直接慌了一半。原因是三层因素叠加：建库没指定 utf8mb4、连接串没有 charset、终端导入时客户端字符集不对。解决方法是按第 2.2 和 2.3 节的配置重来一遍：CREATE DATABASE ... CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，连接串尾部加?charset=utf8mb4，导入 SQL 前在 mysql 命令行执行SET NAMES utf8mb4;。注意，即使前两步做了，第三步漏掉，命令行 source 导入的注释和数据段也可能按系统默认 latin1 解析，照样乱码。

5.2 现象：爬虫连续抓取几页后开始 403，偶尔被重定向去登录页

这是反爬手段，不是代码 bug。校园网站虽然反爬弱，但固定 IP 高频请求同样会被临时封禁。原因通常是请求头太少、两次请求间隔固定且太短。解决：设置一个完整的 User-Agent，带上 Accept-Language、Accept、Connection，模拟浏览器；每次请求之间用random.uniform(1, 3)随机延时。更重要的一点是，定时任务里不要所有数据源同时开跑，错开半小时，避免同一 IP 在同一时间段内出现并发访问。我在第 3.4 节给每个数据源加了独立的 delay 参数，就是这个考虑。

5.3 现象：SnowNLP 把“全校师生接种疫苗”判成消极

第一眼看到这个结果，你可能觉得模型坏了。实际上 SnowNLP 的默认模型是在购物评论上训练的，“接种”可能被关联到了负面体验。解决思路分两层：短期调阈值，把 score 高于 0.4 但低于 0.5 的文本先归为中性，这样误判不至于直接进负面列表；长期做自定义训练，用 SnowNLP 的 train 接口导入 500 条标注好的校园语料。毕业设计时间紧，一般做到短期调阈值即可，但你要在论文里写明模型偏差的来源，不能只写“调参”。

5.4 现象：Flask debug 模式下 APScheduler 任务执行两次

这个翻车点是魔鬼级别的。每次重启 Flask 项目，发现采集日志里同一条 URL 被插了两遍。原因不是你的调度器代码有问题，而是 Flask 的 debug 模式会启动 reloader，主进程和 reloader 子进程各自运行了一次 scheduler 注册。解决：启动调度器前加环境判断，只在非 reloader 进程里启动。

# app.py 启动入口片段 import os if not os.environ.get("WERKZEUG_RUN_MAIN"): pass # reloader 主进程，什么都不做 else: scheduler = start_scheduler(app)

或者更简单：调试时直接关闭debug=True，用app.run(debug=False, use_reloader=False)跑开发服务器。这个坑在答辩前一周出现，很可能让你一整晚都在抓靠“玄学”才能解决的问题，所以我把它单独拎出来提醒。

5.5 现象：ECharts 图表 X 轴显示的日期不对，中文标签变成方块

时间轴偏移通常不是前端问题，而是 Flask 侧把 datetime 转成字符串时没指定Asia/Shanghai。默认情况下，服务器如果跑在 UTC 或系统时区不对，传给前端的时间就少 8 小时。解决：入库前统一用datetime.now(timezone("Asia/Shanghai"))开头转换，接口输出日期时统一format_time = record.publish_time.strftime("%Y-%m-%d %H:%M:%S")。中文方块则是因为 HTML 模板头部缺少<meta charset="utf-8">，或者 ECharts 引入的字体在 Linux 服务器上不存在，顺手装fonts-noto-cjk就行。

6. 部署与验收：用 Gunicorn 跑起来，教你怎么写演示脚本

6.1 生产模式启动：Gunicorn 参数别乱用

开发环境的app.run()不适合答辩演示，浏览器一多就容易卡住。用 Gunicorn 启动时，worker 数不要超过服务器 CPU 核数，否则上下文切换开销反而更大。

pip install gunicorn gunicorn -w 2 -b 127.0.0.1:8000 manage:app

-w 2 表示两个 worker，适合单机演示；如果服务器有 4 核以上，可以适当调到 3-4。这里绑定的 127.0.0.1 表示只接受本机访问，如果你要放在云服务器上演示，需要改成0.0.0.0:8000，同时注意防火墙只放行演示端口。

6.2 验收演示脚本：不用等爬虫结果也能跑通全链路

答辩时最尴尬的情况是现场网络波动，实时爬虫抓不到数据。我习惯准备一个 demo 脚本，直接写入几条预设的校园留言，调用情感分析和关键词提取，然后打开可视化页面就能看到效果。

# demo.py from analysis.sentiment import analyze_sentiment from analysis.keyword import extract_keywords from crawl.storage import save_if_not_exist def run_demo(): samples = [ "食堂今天排队排了半小时，饭菜还是凉的，体验很差", "恭喜学校在挑战杯省赛拿了一等奖", "图书馆新增了二十四小时自习区，环境不错", ] for text in samples: label, score = analyze_sentiment(text) keywords = extract_keywords(text, top_k=5) item = { "title": text[:50], "url": f"demo://{hash(text)}", "platform": "demo", "publish_time": None, } save_if_not_exist(item) print(f"{text[:20]} -> label={label}, score={score:.2f}, keywords={keywords}")

这个脚本的作用是让评审老师看到完整体验：输入文本、情感分类、关键词、入库、前端图表，全程不需要依赖外部网站。save_if_not_exist 里的 url 用 hash 加前缀生成，确保不会和真实 URL 冲突。

6.3 环境自检脚本：新机器上先跑通依赖

拿到压缩包之后，最怕的是在一台没有配置 Python 环境的机器上从零折腾。我会在项目根目录放一个环境自检脚本，一次性输出 Python 版本、关键依赖是否可用、MySQL 连接是否通畅。

python -m pip install -r requirements.txt python check_env.py

check_env.py 内部按顺序 import pymysql、flask、snownlp、jieba、bs4，再尝试连接一次 MySQL 配置库，任一环节异常都会打印明确的修复提示。这样做的好处是，你不再需要靠flask run的报错来摸索缺了什么包。去年我帮同学打包一套类似的毕设，他第一句问我为什么页面空白，我让他跑这个脚本，三分钟定位到没装 MySQL 服务，比反复排查路由快得多。

从那以后，我每次交付 Python 毕业设计源码，都会强制走一遍环境自检、建库、采集、演示这四步，宁可提前翻车，不在答辩现场翻车。希望帮到你。

本文还有配套的精品资源，点击获取