简介面向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 也能顺便体现你对数据库表结构和索引设计有概念。下面是两者对比给你写文档时直接用。对比项Flask MySQLDjango SQLite项目结构蓝图自由拆分按模块组织固定 app 结构适合大型后台数据写入支持并发写入和事务控制并发写入容易锁库演示成本需要单独初始化数据库开箱即用答辩可讲度表结构、索引、SQL 优化都有素材容易停留在“默认配置”层面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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 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 ( fmysqlpymysql://{DB_USER}:{DB_PASSWORD}{DB_HOST}:{DB_PORT}/{DB_NAME} ?charsetutf8mb4 ) SQLALCHEMY_TRACK_MODIFICATIONS False # 爬虫调度参数 CRAWL_INTERVAL_HOURS 2 REQUEST_TIMEOUT 10 RETRY_TIMES 3这里的连接串末尾必须带上 charsetutf8mb4否则即使建库时指定了 utf8mb4ORM 写入时也可能因为连接参数不对而出现中文乱码。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;q0.9, } def fetch_page(url, retriesNone, timeoutNone): 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, headersHEADERS, 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 Nonefetch_page 的逻辑很简单先尝试请求失败后指数退避重试。注意我把 timeout 写成了 (timeout, timeout)这是 requests 库的规范用法分别代表“连接超时”和“读取超时”。如果只传一个值读取阶段挂起时依然会拖死整个定时任务。resp.apparent_encoding虽然比默认编码准但它需要先读取一部分内容做探测在大页面时会有额外耗时好在舆情页面一般不大这个成本可以接受。拿到 HTML 后用 BeautifulSoup 解析列表页提取标题、链接、发布时间。解析时尽量找稳定的容器 class不要拿标签层级硬卡否则学校换一次模板你的解析就崩了。def parse_list_page(html, base_urlhttps://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(stripTrue) 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(stripTrue) 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_urlitem[url]).first() if exists: return False record SentimentInfo( titleitem[title], source_urlitem[url], platformitem.get(platform, unknown), publish_timeparse_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(timezoneAsia/Shanghai) scheduler.add_job( run_crawl_job, triggerIntervalTrigger(hoursapp.config[CRAWL_INTERVAL_HOURS]), idcrawl_job, max_instances1, coalesceTrue, replace_existingTrue, ) scheduler.start() return schedulerrun_crawl_job 是在独立函数里调用各个数据源的采集入口。这里三个参数值得说清楚max_instances1表示上一轮没跑完时即使到了下一个时间点也不开新任务避免数据源扛不住coalesceTrue表示把错过的任务合并成一次补跑不会堆积replace_existingTrue配合固定 id保障重复启动时不会注册两个同名任务。这个配置是血泪经验换来的——开发调试时 debug 模式会触发两次主进程没有这些保护定时任务会重复执行。4. 情感分析与关键词提取SnowNLP 和 jieba 的调参边界4.1 为什么选轻量级算法毕业设计不靠模型刷分靠流程完整情感分析部分我经常被问为什么不用 BERT、为什么不用百度的 ERNIE这类预训练模型确实准确率高但放在毕业设计里会带来三个麻烦需要 GPU 或至少 16G 内存、答辩现场很难跑推理、评委问“你如何调优”时你得能讲出训练细节。校园舆情这个场景数据量不大文本偏短SnowNLP 足够撑起全流程而且它是一个可以读源码的库答辩时能讲清楚情感分数是怎么来的。相比直接用 TextBlobSnowNLP 的好处是中文语境处理更顺手内置了分词、情感、关键词、摘要算法不需要额外组装。它的默认模型是在商品评论语料上训练的所以对校园场景有很大偏差但这个偏差恰好是你在论文里可以写“针对校园语料进行阈值调整与样本迁移”的素材。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, topKtop_k, withWeightFalse) 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;连接串尾部加?charsetutf8mb4导入 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)或者更简单调试时直接关闭debugTrue用app.run(debugFalse, use_reloaderFalse)跑开发服务器。这个坑在答辩前一周出现很可能让你一整晚都在抓靠“玄学”才能解决的问题所以我把它单独拎出来提醒。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 charsetutf-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_k5) item { title: text[:50], url: fdemo://{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.pycheck_env.py 内部按顺序 import pymysql、flask、snownlp、jieba、bs4再尝试连接一次 MySQL 配置库任一环节异常都会打印明确的修复提示。这样做的好处是你不再需要靠flask run的报错来摸索缺了什么包。去年我帮同学打包一套类似的毕设他第一句问我为什么页面空白我让他跑这个脚本三分钟定位到没装 MySQL 服务比反复排查路由快得多。从那以后我每次交付 Python 毕业设计源码都会强制走一遍环境自检、建库、采集、演示这四步宁可提前翻车不在答辩现场翻车。希望帮到你。本文还有配套的精品资源点击获取