简介面向高校毕业设计的校园舆情管理系统完整项目基于 PythonDjangoMySQL 实现适合作计算机专业本科毕设或课程设计素材。系统围绕校园言论的采集、分析与管控提供言论分析、言论管理、用户管理等核心模块帮助网络管理部门在保障隐私和言论自由的前提下及时发现本校相关负面舆情。压缩包共 254 个文件约 43.98MB主要包含 Python 源码、pyc 编译文件、HTML/CSS/JS 前端页面、图片与字体资源、SQL 脚本和说明文档目录按 Django 项目常见结构组织也包含 layui 等前端组件便于直接部署和二次开发。已有 668 人浏览学习说明该项目在毕设场景中具有一定参考价值。附带演示视频和说明文档可直观了解系统运行流程源码覆盖舆情分析、关键词管理、用户管理等典型功能适合参考实现也能为毕业设计答辩、项目文档撰写提供对照素材。1. 校园舆情管理系统是什么这份源码包解决的是谁的什么问题如果你正在做 Python 方向的毕业设计大概率刷到过「校园舆情管理系统」这个题目。它本质上不是一个花哨的算法项目而是一条完整的数据流水线从校园论坛、表白墙、教务处公告这些信息源采集文本再经过中文分词、情感判断、主题聚类最后把结果落到后台管理界面和预警记录里。这套系统最反直觉的地方在于核心难点不在爬虫而在文本分析层的参数调校——同样的 食堂涨价 四个字分词切不对、情感词典没覆盖结果就从负面舆情变成中性陈述。这份源码包面向的是两类人一是需要快速跑通并能在答辩时演示完整业务流的毕业生二是想拿真实校园场景练手 Python 全栈的初学者。它能让你少走三个月弯路但也别指望解压即用——环境搭建和编码问题的坑一个都躲不掉。2. 先看骨架再动手为什么这类系统默认是 Flask MySQL jieba 的组合2.1 采集层requests 为主Scrapy 是加分项不是必选项校园舆情的数据源通常分散在校园论坛、公开的学院新闻页、贴吧等地方。这类站点的请求量和结构复杂度都很低用 Scrapy 属于杀鸡用牛刀反而拉高项目理解成本。常见的毕设做法是直接用requests写一个采集器按一定频率抓取页面用BeautifulSoup或正则提取正文。我自己给学生改项目时最常强调的不是抓取效率而是请求的礼貌程度。很多反爬封 IP 的案例都是请求头太裸、频率太凶导致的。下面是一个最小可用的采集核心# collector.py import time import random import logging import requests from bs4 import BeautifulSoup 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 ), Referer: https://example-campus.edu.cn/, } def fetch_page(url: str, session: requests.Session) - str: 抓取单个页面失败时返回空字符串而不是抛异常 try: resp session.get(url, headersHEADERS, timeout10) # 关键用 apparent_encoding 而不是固定 utf-8 resp.encoding resp.apparent_encoding return resp.text except requests.RequestException as e: logging.error(请求失败: %s, %s, url, e) return def run(): session requests.Session() urls load_urls_from_db() # 从任务表读待采集URL for url in urls: html fetch_page(url, session) if html: parse_and_save(html) # 解析正文和发布时间写入 raw_data 表 time.sleep(random.uniform(3, 6)) # 限速防止触发反爬这段代码里有三个值得在答辩时讲清楚的参数。第一个是timeout10它防止某个页面长期挂起拖死整个采集线程。第二个是resp.apparent_encoding很多校园站点用的是 GBK 或 GB2312强制utf-8解码会直接乱码apparent_encoding是 requests 根据页面字节内容自动推断的编码虽然慢一点但对小规模采集完全够用。第三个是random.uniform(3, 6)它让每次请求间隔在 3 到 6 秒之间随机波动而不是固定 4 秒——固定间隔在反爬系统眼里比高频请求更好识别。2.2 分析层jieba 分词 情感词典校园场景不用一上来就上大模型分析层是整个系统的黑匣子也是最容易翻车的地方。很多新手一听到舆情分析就想着上 BERT、ChatGPT但校园舆情这个场景有两个特点一是语料规模不大一天几百条就算多二是话题高度集中翻来覆去就是食堂、宿舍、图书馆、选课、校园网这些事。这种封闭场景里jieba分词加一个定制情感词典准确率已经能到 80% 以上而且每一条结果的逻辑都可解释——答辩时老师问为什么这一条是负面你能直接指给他看命中了哪个情感词。jieba的核心问题是它对校园专属词汇的切分。比如图书馆占座会被切成本来就正确的词但校园网卡顿里的校园网如果不在词典里可能被切成校园网卡。这种错误分词直接污染后续的情感判断和主题聚类。解决办法是准备一个自定义词典文件把这些词按权重写进去# sentiment.py import os import jieba from snownlp import SnowNLP # 注意不要用相对路径 dict/campus_words.txt # 要基于当前文件所在目录拼路径否则换目录运行就加载失败 BASE_DIR os.path.dirname(os.path.abspath(__file__)) DICT_PATH os.path.join(BASE_DIR, dict, campus_words.txt) jieba.load_userdict(DICT_PATH) # 自定义情感词典校园场景特有词汇通用词典覆盖不到 EXTRA_POSITIVE_WORDS [好吃, 方便, 热情, 解决了] EXTRA_NEGATIVE_WORDS [难吃, 涨价, 漏水, 断电, 占座, 网卡] def analyze(text: str) - dict: 返回情感倾向和分值score 越接近 0 越负面越接近 1 越正面 s SnowNLP(text) score s.sentiments if score 0.7: label 正面 elif score 0.3: label 负面 else: label 中性 return {score: round(score, 3), label: label}这里的阈值0.7和0.3是经验值不是标准答案。你拿到源码后应该先跑一批真实数据观察分数分布再决定要不要放宽到0.6 / 0.4。另外我一般会把jieba.load_userdict单独写在模块顶层而不是每次调用时加载因为词典加载有 IO 开销放在分析接口里会导致每条请求都重复读盘。2.3 展示层和预警层ECharts 看趋势规则引擎做闭环数据采了、情感算好了还差一步才能叫管理系统——把结果变成管理者能看懂的东西。展示层常规做法是 Flask 返回 JSON前端用 ECharts 画词云、情感占比饼图和每日舆情趋势折线图。预警层则是把情感分析结果送入一条规则引擎命中规则就写入预警记录表并在后台顶部显示未读提醒。规则引擎的写法比想象中简单本质上就是关键词集合加阈值判断# warning.py RULES [ {keywords: [食堂, 涨价, 难吃], max_score: 0.35, level: 高}, {keywords: [宿舍, 漏水, 断电], max_score: 0.30, level: 高}, {keywords: [就业, 焦虑, 压力], max_score: 0.40, level: 中}, ] def check_warning(text: str, score: float): 命中关键词且情感分低于阈值则触发预警 for rule in RULES: hit any(kw in text for kw in rule[keywords]) if hit and score rule[max_score]: return rule[level] return None注意max_score的含义情感分析里分数越低越负面所以食堂涨价这种负面事件要想触发预警分数得在0.35以下。这个 0.35 不是随便拍的它来自情感得分的分布经验——负面事件的情感分通常集中在 0.2 到 0.4 区间阈值太严会漏报太松又会让预警记录里塞满无关信息。拿到源码后先用历史数据画一张情感分数直方图再定阈值比拍脑袋靠谱得多。3. 在本地跑通整套源码从 zip 解压、Python 环境到后台页面亮起来3.1 Python 环境准备版本选择与依赖安装命令先泼一盆冷水如果你用的是 Python 3.12 及以上直接跑这套源码大概率会报错。原因不是源码写得差而是很多老项目的依赖没有跟进新版解释器。比如scikit-learn的旧版本在 3.12 上装不上lxml要等新版发布。我的建议是装 Python 3.8 到 3.10 之间的版本推荐 3.9兼容性最稳。拿到压缩包后先解压确认里面有requirements.txt或requirements.txt的等价文件然后创建虚拟环境并安装依赖# Windows 下在项目根目录打开终端 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS / Linux # source venv/bin/activate # 安装依赖建议用国内镜像加速 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple安装完不要急着启动先验证两个关键包能不能用python -c import jieba; print(jieba.__version__) python -c import flask; print(flask.__version__)如果jieba导入失败大概率是虚拟环境没激活就直接 pip 了如果flask版本超过 3.0注意源码里的路由写法是否兼容——旧代码里常见的app.route(/)在新版没问题但flask_sqlalchemy的配置方式变了报错就装 2.5.1 这个指定版本。3.2 数据库初始化建库、导表、看说明文档的先后顺序大部分毕设源码的数据库是 MySQL也有小部分用 SQLite 省事。如果是 SQLite跳到 3.3 节就能直接跑如果是 MySQL会多几个步骤。第一次打开源码时不要急着改代码先看说明文档里有没有数据库名和账号密码的约定没有的话常规做法是看config.py里的配置项。# config.py # 数据库连接配置——这是启动前必须改的地方 DB_CONFIG { host: 127.0.0.1, port: 3306, user: root, password: 123456, # 改成你自己 MySQL 的密码 database: campus_opinion, charset: utf8mb4, # 必须是 utf8mb4不是 utf8 }先手动登录 MySQL 创建数据库再导表mysql -u root -p CREATE DATABASE campus_opinion DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; exit; # 导入项目自带的 .sql 文件 mysql -u root -p campus_opinion campus_opinion.sql如果项目没有.sql文件而是用了init_db.py之类的脚本那就直接跑python init_db.py跑完后进 MySQL 确认核心表是否存在USE campus_opinion; SHOW TABLES;正常会看到user、raw_data、sentiment_result、warning_record、topic这几类表。如果SHOW TABLES返回空排查顺序是先确认创建数据库时有没有带上utf8mb4再确认init_db.py里连接的库名和config.py是否一致。表建不出来九成是库名写错或字符集不对不是代码逻辑问题。3.3 修改配置文件并启动三个必改参数和一个验证方法配置改完就能启动了。启动方式一般写在说明文档里通常是直接跑app.pypython app.py看到类似Running on http://127.0.0.1:5000的输出说明服务起来了。这时打开浏览器访问http://127.0.0.1:5000进入登录页用说明文档里提供的管理员账号登录比如admin / admin123。如果登录失败优先看数据库的user表里有没有初始化数据SELECT username, password FROM user;很多毕设项目的密码不是明文而是 MD5 或 SHA256 哈希。如果你想新建一个管理员账号不要在 SQL 里直接写明文用 Python 生成哈希再插入import hashlib def md5_pwd(s: str) - str: return hashlib.md5(s.encode()).hexdigest() print(md5_pwd(admin123))拿到哈希值后手动 UPDATE 进表比改注册接口的代码省事得多。启动过程中最常被误判为源码坏了的问题实际上是三个端口被占用、MySQL 服务没启动、密码强度校验挡住弱口令。端口冲突的排查命令是netstat -ano | findstr 5000Windows或lsof -i:5000macOS/Linux换端口就在app.run(port5001)里改。MySQL 没启动在 Windows 上最容易发生去服务管理器里看一下MySQL80这个服务的状态设成自动启动。密码策略问题只要在my.ini里把validate_password.policy调成LOW或直接关掉就能解决。4. 读源码和改参数的正确顺序从采集到情感分析到预警4.1 采集模块请求头、限速和存储是三个必看位置拿到源码先找采集模块文件名通常叫spider.py、crawler.py或collector.py。打开后按三个顺序看请求头、限速、存储逻辑。请求头的问题在于很多源码里的 User-Agent 是几年前爬来的字段规范但已过时反爬系统会因为它太老而直接拒绝。常见做法是把它替换成自己浏览器里真实存在的 UA从 Chrome 的network面板复制即可不需要额外库。存储逻辑看的是它把解析后的数据写到哪里。正常写法是直接INSERT INTO raw_data(title, content, source, publish_time)但也有人写得偷懒——同一个 URL 反复入库导致后面情感分析要把相同内容算好几遍。如果你发现数据有重复在爬虫的保存函数里加一个查重就够了# collector.py 中的保存函数 def parse_and_save(html: str): items extract_articles(html) # 用 BeautifulSoup 提取标题和正文 for item in items: # 按 URL 去重避免重复入库 exists db.query( SELECT id FROM raw_data WHERE url%s, (item[url],) ) if not exists: db.insert(raw_data, item)去重看着简单但很多情感分析结果偏大或偏小根因就是数据重复导致同一句话被加权了两遍。这一步在答辩时也能讲清楚属于典型的工程细节。4.2 情感分析自定义词典和阈值参数决定分析质量情感分析模块是整套系统里参数最密集的地方。除了上一章讲的jieba自定义词典和0.7 / 0.3阈值还有一个容易被忽略的参数——SnowNLP的模型本身就是基于电商评论训练的对校园场景文本的适配度有限。体现最明显的是校园网又断了这句话在电商语料里可能会判成中性甚至正面因为它没有典型的负面情感词。解决思路是给SnowNLP之外加一个兜底规则命中自定义负面词典里的词直接把分数压到 0.2 以下不管 SnowNLP 给多少# sentiment.py EXTRA_NEGATIVE_WORDS [难吃, 涨价, 漏水, 断电, 占座, 网卡] def analyze(text: str) - dict: s SnowNLP(text) score s.sentiments # 兜底规则命中校园负面词典直接视为负面 for word in EXTRA_NEGATIVE_WORDS: if word in text: score min(score, 0.2) break label 负面 if score 0.3 else (正面 if score 0.7 else 中性) return {score: round(score, 3), label: label}这里用min(score, 0.2)而不是直接赋值0.2是为了保留 SnowNLP 的连续分值——如果原文里同时有好吃和涨价两个词最终分数会比纯负面场景高一点能反映文本内部的矛盾情绪。兜底规则的阈值不要设到0.1以下否则系统里几乎不会出现中性结果所有提及负面词的文本都被一棍子打死预警记录会塞满无关内容。4.3 主题聚类与预警ntopics 和规则优先级怎么配合主题聚类在毕设里通常用 TF-IDF 加 LDA 实现。LDA 里最重要的参数是主题数n_components。校园舆情的主题数目不需要太多5 到 8 个是合理范围——食堂、宿舍、图书馆、选课、校园网、社团、就业、其他。设成 10 以上就会出现主题重叠比如两个主题里的核心词都是宿舍和热水。# topic.py from sklearn.feature_extraction.text import CountVectorizer from sklearn.decomposition import LatentDirichletAllocation count_vect CountVectorizer( tokenizerjieba.lcut, # 用 jieba 分词器 max_features2000, # 只保留词频最高的 2000 个词 ) X count_vect.fit_transform(doc_list) # doc_list 是待聚类的文档列表 lda LatentDirichletAllocation( n_components6, # 主题数校园场景 5~8 个够用 random_state42, # 固定随机种子保证每次运行结果一致 max_iter20, # 迭代次数小语料 20 次足够收敛 ) lda.fit(X)max_features2000是为了去低频噪声像同学今天这类无意义词如果进了特征矩阵会让聚类结果变成今天 食堂 同学这样看不懂的组合。random_state42必须固定否则每次跑出来的主题分类都不一样答辩时前后说法对不上会被追问。预警和主题聚类不是独立的两层而是协作关系。常见做法是先打好主题标签再在主题内部应用规则引擎——比如食堂主题下的规则阈值比社团主题更敏感因为食堂话题直接关系学生生活质量争议大。规则优先级按更具体的词先判断排列一个帖子同时命中食堂和涨价优先按食堂主题的阈值走而不是按涨价的通用阈值走。5. 避坑清单校园舆情系统最容易翻车的 5 个点5.1 现象MySQL 里中文全是问号数据库表里的中文全部变成???页面加载出来也带着一堆问号。原因建库时的字符集不是utf8mb4或者是utf8但表的排序规则不对。MySQL 的utf8是阉割版不支持四字节的 emoji而utf8mb4才是完整的 UTF-8。校园舆情文本里经常出现颜文字和 emoji只要有一条带 emoji 的记录入表整段文本就被截断成问号。解决删掉旧库重建建库语句加上DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci同时在连接配置里带上charsetutf8mb4不要遗漏。5.2 现象jieba 自定义词典加载失败分词结果没有变化明明写了jieba.load_userdict(campus_words.txt)运行也不报错但校园网还是被切成校园和网卡。原因相对路径是相对进程的工作目录写的。用 IDE 启动时工作目录是项目根目录没问题但用命令行在别的目录启动或者打成 exe 之后相对路径就指向另一个地方词典文件自然是加载了不存在的路径——jieba 会静默跳过而不是报错。解决用os.path.dirname(os.path.abspath(__file__))拼出文件所在目录的绝对路径再拼接词典文件路径。这也是我在第 2 章代码里强调过的写法。5.3 现象pip 安装依赖报一堆 red text卡在某个包上现象是pip install -r requirements.txt装到一半报Failed to build或Microsoft Visual C 14.0 is required。原因Python 版本太新scikit-learn、lxml这些带 C 扩展的包没有对应版本的预编译 wheelpip 只能现场编译而 Windows 上编译 C 扩展需要完整版 Visual Studio Build Tools。解决先换 Python 3.9 再试大概率直接有预编译包如果项目对 Python 版本有硬性要求就去下载对应版本的.whl文件手动安装不要现场编译。这个坑在 3.9 上基本遇不到。5.4 现象采集几轮后目标站点返回 403 或验证码一开始抓得好好的几十条数据之后突然被拒绝访问。原因请求频率被反爬系统识别。你用的是固定间隔比如time.sleep(2)反爬系统把这种规律性的间隔当成机器特征另外请求头里的 User-Agent 太老或太大众化也会加速被封。解决间隔改成random.uniform(3, 6)的随机区间并且准备至少 3 个不同的 UA 轮换使用如果目标站点要求登录才能看内容把浏览器的 Cookie 复制到请求头里模拟真实用户。5.5 现象答辩演示时笔记本能打开手机连同一 WiFi 访问不了Flask 启动时输出Running on http://127.0.0.1:5000这个地址是回环地址只有本机能访问。原因app.run()默认绑定127.0.0.1不监听局域网网卡。演示现场想用手机或教室电脑看效果根本连不上。解决启动参数改为app.run(host0.0.0.0, port5000, debugFalse)让服务监听所有网卡。注意debugTrue在局域网访问时存在安全隐患演示时用False更稳。6. 让答辩演示效果上一个台阶三个具体改进和验证方法6.1 写一个一键生成演示数据的脚本很多源码自带的演示数据只有几十条跑出来的词云和趋势图稀稀拉拉答辩观感很差。与其手动造数据不如写个脚本快速生成一个月的模拟舆情。演示前跑一遍后台的图表立刻饱满起来# generate_demo_data.py import random import datetime import pymysql # 模拟 30 天每天 15~30 条数据 start_date datetime.date.today() - datetime.timedelta(days30) sources [校园论坛, 表白墙, 教务处公告, 贴吧] topics [ 食堂三楼新窗口的麻辣香锅味道不错, 图书馆六楼插座坏了没人修, 宿舍热水晚上十点就没了, 校园网又卡了视频课根本看不了, 选课系统今天下午崩了一会, 操场夜跑灯光太暗建议加灯, ] for day in range(30): date start_date datetime.timedelta(daysday) for _ in range(random.randint(15, 30)): content random.choice(topics) source random.choice(sources) # 执行 INSERT写入 raw_data 表 # 之后在情感分析模块里跑一遍 # 预警记录和图表就都有了这里的关键不是批量造数据而是把造好的数据再跑一次情感分析和聚类流程让预警记录、趋势图、饼图全部联动刷新。只塞数据不跑分析页面上除了数字别的都看不到。6.2 给预警模块加一个未读消息数角标预警模块在毕设里通常只体现为一张表格缺一个直观的提醒动作。最省事又出效果的做法是在后台顶栏加一个未读角标——查询预警记录表中status为 0未读的行数显示在导航栏app.route(/unread_count) def unread_count(): 返回未读预警数量前端定时轮询 count db.query( SELECT COUNT(*) FROM warning_record WHERE status0 )[0][0] return {count: count}前端模板里用一段简单的 JS 轮询这个接口每 30 秒刷一次。答辩时你可以现场演示手动插入一条负面舆情角标数字自动加一点击列表后数字归零。这个细节比任何图表都能说明系统有闭环。6.3 用三个问题验证聚类结果是否可信验证 LDA 主题聚类不是看可视化图漂不漂亮而是问三个问题每个主题下前 10 个核心词是否集中在同一类话题上同一主题内的文本和人工判断是否一致情感分数分布是否符合直觉——比如食堂主题的负面占比应该明显高于社团主题。我自己做这类项目到最后一定会留一个把聚类结果 dump 成 CSV 的脚本一列放主题号、一列放原文打印出来逐条看。答辩前通读一遍这个 CSV被老师问这个主题是怎么得出来的时你能指着一行行文本给出真实依据。这个小习惯救过我不少次希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 14:39:29 · 阅读 1.2k Python校园舆情管理系统源码详解：Flask+MySQL+jieba情感分析
简介面向高校毕业设计的校园舆情管理系统完整项目基于 PythonDjangoMySQL 实现适合作计算机专业本科毕设或课程设计素材。系统围绕校园言论的采集、分析与管控提供言论分析、言论管理、用户管理等核心模块帮助网络管理部门在保障隐私和言论自由的前提下及时发现本校相关负面舆情。压缩包共 254 个文件约 43.98MB主要包含 Python 源码、pyc 编译文件、HTML/CSS/JS 前端页面、图片与字体资源、SQL 脚本和说明文档目录按 Django 项目常见结构组织也包含 layui 等前端组件便于直接部署和二次开发。已有 668 人浏览学习说明该项目在毕设场景中具有一定参考价值。附带演示视频和说明文档可直观了解系统运行流程源码覆盖舆情分析、关键词管理、用户管理等典型功能适合参考实现也能为毕业设计答辩、项目文档撰写提供对照素材。1. 校园舆情管理系统是什么这份源码包解决的是谁的什么问题如果你正在做 Python 方向的毕业设计大概率刷到过「校园舆情管理系统」这个题目。它本质上不是一个花哨的算法项目而是一条完整的数据流水线从校园论坛、表白墙、教务处公告这些信息源采集文本再经过中文分词、情感判断、主题聚类最后把结果落到后台管理界面和预警记录里。这套系统最反直觉的地方在于核心难点不在爬虫而在文本分析层的参数调校——同样的 食堂涨价 四个字分词切不对、情感词典没覆盖结果就从负面舆情变成中性陈述。这份源码包面向的是两类人一是需要快速跑通并能在答辩时演示完整业务流的毕业生二是想拿真实校园场景练手 Python 全栈的初学者。它能让你少走三个月弯路但也别指望解压即用——环境搭建和编码问题的坑一个都躲不掉。2. 先看骨架再动手为什么这类系统默认是 Flask MySQL jieba 的组合2.1 采集层requests 为主Scrapy 是加分项不是必选项校园舆情的数据源通常分散在校园论坛、公开的学院新闻页、贴吧等地方。这类站点的请求量和结构复杂度都很低用 Scrapy 属于杀鸡用牛刀反而拉高项目理解成本。常见的毕设做法是直接用requests写一个采集器按一定频率抓取页面用BeautifulSoup或正则提取正文。我自己给学生改项目时最常强调的不是抓取效率而是请求的礼貌程度。很多反爬封 IP 的案例都是请求头太裸、频率太凶导致的。下面是一个最小可用的采集核心# collector.py import time import random import logging import requests from bs4 import BeautifulSoup 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 ), Referer: https://example-campus.edu.cn/, } def fetch_page(url: str, session: requests.Session) - str: 抓取单个页面失败时返回空字符串而不是抛异常 try: resp session.get(url, headersHEADERS, timeout10) # 关键用 apparent_encoding 而不是固定 utf-8 resp.encoding resp.apparent_encoding return resp.text except requests.RequestException as e: logging.error(请求失败: %s, %s, url, e) return def run(): session requests.Session() urls load_urls_from_db() # 从任务表读待采集URL for url in urls: html fetch_page(url, session) if html: parse_and_save(html) # 解析正文和发布时间写入 raw_data 表 time.sleep(random.uniform(3, 6)) # 限速防止触发反爬这段代码里有三个值得在答辩时讲清楚的参数。第一个是timeout10它防止某个页面长期挂起拖死整个采集线程。第二个是resp.apparent_encoding很多校园站点用的是 GBK 或 GB2312强制utf-8解码会直接乱码apparent_encoding是 requests 根据页面字节内容自动推断的编码虽然慢一点但对小规模采集完全够用。第三个是random.uniform(3, 6)它让每次请求间隔在 3 到 6 秒之间随机波动而不是固定 4 秒——固定间隔在反爬系统眼里比高频请求更好识别。2.2 分析层jieba 分词 情感词典校园场景不用一上来就上大模型分析层是整个系统的黑匣子也是最容易翻车的地方。很多新手一听到舆情分析就想着上 BERT、ChatGPT但校园舆情这个场景有两个特点一是语料规模不大一天几百条就算多二是话题高度集中翻来覆去就是食堂、宿舍、图书馆、选课、校园网这些事。这种封闭场景里jieba分词加一个定制情感词典准确率已经能到 80% 以上而且每一条结果的逻辑都可解释——答辩时老师问为什么这一条是负面你能直接指给他看命中了哪个情感词。jieba的核心问题是它对校园专属词汇的切分。比如图书馆占座会被切成本来就正确的词但校园网卡顿里的校园网如果不在词典里可能被切成校园网卡。这种错误分词直接污染后续的情感判断和主题聚类。解决办法是准备一个自定义词典文件把这些词按权重写进去# sentiment.py import os import jieba from snownlp import SnowNLP # 注意不要用相对路径 dict/campus_words.txt # 要基于当前文件所在目录拼路径否则换目录运行就加载失败 BASE_DIR os.path.dirname(os.path.abspath(__file__)) DICT_PATH os.path.join(BASE_DIR, dict, campus_words.txt) jieba.load_userdict(DICT_PATH) # 自定义情感词典校园场景特有词汇通用词典覆盖不到 EXTRA_POSITIVE_WORDS [好吃, 方便, 热情, 解决了] EXTRA_NEGATIVE_WORDS [难吃, 涨价, 漏水, 断电, 占座, 网卡] def analyze(text: str) - dict: 返回情感倾向和分值score 越接近 0 越负面越接近 1 越正面 s SnowNLP(text) score s.sentiments if score 0.7: label 正面 elif score 0.3: label 负面 else: label 中性 return {score: round(score, 3), label: label}这里的阈值0.7和0.3是经验值不是标准答案。你拿到源码后应该先跑一批真实数据观察分数分布再决定要不要放宽到0.6 / 0.4。另外我一般会把jieba.load_userdict单独写在模块顶层而不是每次调用时加载因为词典加载有 IO 开销放在分析接口里会导致每条请求都重复读盘。2.3 展示层和预警层ECharts 看趋势规则引擎做闭环数据采了、情感算好了还差一步才能叫管理系统——把结果变成管理者能看懂的东西。展示层常规做法是 Flask 返回 JSON前端用 ECharts 画词云、情感占比饼图和每日舆情趋势折线图。预警层则是把情感分析结果送入一条规则引擎命中规则就写入预警记录表并在后台顶部显示未读提醒。规则引擎的写法比想象中简单本质上就是关键词集合加阈值判断# warning.py RULES [ {keywords: [食堂, 涨价, 难吃], max_score: 0.35, level: 高}, {keywords: [宿舍, 漏水, 断电], max_score: 0.30, level: 高}, {keywords: [就业, 焦虑, 压力], max_score: 0.40, level: 中}, ] def check_warning(text: str, score: float): 命中关键词且情感分低于阈值则触发预警 for rule in RULES: hit any(kw in text for kw in rule[keywords]) if hit and score rule[max_score]: return rule[level] return None注意max_score的含义情感分析里分数越低越负面所以食堂涨价这种负面事件要想触发预警分数得在0.35以下。这个 0.35 不是随便拍的它来自情感得分的分布经验——负面事件的情感分通常集中在 0.2 到 0.4 区间阈值太严会漏报太松又会让预警记录里塞满无关信息。拿到源码后先用历史数据画一张情感分数直方图再定阈值比拍脑袋靠谱得多。3. 在本地跑通整套源码从 zip 解压、Python 环境到后台页面亮起来3.1 Python 环境准备版本选择与依赖安装命令先泼一盆冷水如果你用的是 Python 3.12 及以上直接跑这套源码大概率会报错。原因不是源码写得差而是很多老项目的依赖没有跟进新版解释器。比如scikit-learn的旧版本在 3.12 上装不上lxml要等新版发布。我的建议是装 Python 3.8 到 3.10 之间的版本推荐 3.9兼容性最稳。拿到压缩包后先解压确认里面有requirements.txt或requirements.txt的等价文件然后创建虚拟环境并安装依赖# Windows 下在项目根目录打开终端 python -m venv venv # 激活虚拟环境Windows venv\Scripts\activate # 激活虚拟环境macOS / Linux # source venv/bin/activate # 安装依赖建议用国内镜像加速 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple安装完不要急着启动先验证两个关键包能不能用python -c import jieba; print(jieba.__version__) python -c import flask; print(flask.__version__)如果jieba导入失败大概率是虚拟环境没激活就直接 pip 了如果flask版本超过 3.0注意源码里的路由写法是否兼容——旧代码里常见的app.route(/)在新版没问题但flask_sqlalchemy的配置方式变了报错就装 2.5.1 这个指定版本。3.2 数据库初始化建库、导表、看说明文档的先后顺序大部分毕设源码的数据库是 MySQL也有小部分用 SQLite 省事。如果是 SQLite跳到 3.3 节就能直接跑如果是 MySQL会多几个步骤。第一次打开源码时不要急着改代码先看说明文档里有没有数据库名和账号密码的约定没有的话常规做法是看config.py里的配置项。# config.py # 数据库连接配置——这是启动前必须改的地方 DB_CONFIG { host: 127.0.0.1, port: 3306, user: root, password: 123456, # 改成你自己 MySQL 的密码 database: campus_opinion, charset: utf8mb4, # 必须是 utf8mb4不是 utf8 }先手动登录 MySQL 创建数据库再导表mysql -u root -p CREATE DATABASE campus_opinion DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; exit; # 导入项目自带的 .sql 文件 mysql -u root -p campus_opinion campus_opinion.sql如果项目没有.sql文件而是用了init_db.py之类的脚本那就直接跑python init_db.py跑完后进 MySQL 确认核心表是否存在USE campus_opinion; SHOW TABLES;正常会看到user、raw_data、sentiment_result、warning_record、topic这几类表。如果SHOW TABLES返回空排查顺序是先确认创建数据库时有没有带上utf8mb4再确认init_db.py里连接的库名和config.py是否一致。表建不出来九成是库名写错或字符集不对不是代码逻辑问题。3.3 修改配置文件并启动三个必改参数和一个验证方法配置改完就能启动了。启动方式一般写在说明文档里通常是直接跑app.pypython app.py看到类似Running on http://127.0.0.1:5000的输出说明服务起来了。这时打开浏览器访问http://127.0.0.1:5000进入登录页用说明文档里提供的管理员账号登录比如admin / admin123。如果登录失败优先看数据库的user表里有没有初始化数据SELECT username, password FROM user;很多毕设项目的密码不是明文而是 MD5 或 SHA256 哈希。如果你想新建一个管理员账号不要在 SQL 里直接写明文用 Python 生成哈希再插入import hashlib def md5_pwd(s: str) - str: return hashlib.md5(s.encode()).hexdigest() print(md5_pwd(admin123))拿到哈希值后手动 UPDATE 进表比改注册接口的代码省事得多。启动过程中最常被误判为源码坏了的问题实际上是三个端口被占用、MySQL 服务没启动、密码强度校验挡住弱口令。端口冲突的排查命令是netstat -ano | findstr 5000Windows或lsof -i:5000macOS/Linux换端口就在app.run(port5001)里改。MySQL 没启动在 Windows 上最容易发生去服务管理器里看一下MySQL80这个服务的状态设成自动启动。密码策略问题只要在my.ini里把validate_password.policy调成LOW或直接关掉就能解决。4. 读源码和改参数的正确顺序从采集到情感分析到预警4.1 采集模块请求头、限速和存储是三个必看位置拿到源码先找采集模块文件名通常叫spider.py、crawler.py或collector.py。打开后按三个顺序看请求头、限速、存储逻辑。请求头的问题在于很多源码里的 User-Agent 是几年前爬来的字段规范但已过时反爬系统会因为它太老而直接拒绝。常见做法是把它替换成自己浏览器里真实存在的 UA从 Chrome 的network面板复制即可不需要额外库。存储逻辑看的是它把解析后的数据写到哪里。正常写法是直接INSERT INTO raw_data(title, content, source, publish_time)但也有人写得偷懒——同一个 URL 反复入库导致后面情感分析要把相同内容算好几遍。如果你发现数据有重复在爬虫的保存函数里加一个查重就够了# collector.py 中的保存函数 def parse_and_save(html: str): items extract_articles(html) # 用 BeautifulSoup 提取标题和正文 for item in items: # 按 URL 去重避免重复入库 exists db.query( SELECT id FROM raw_data WHERE url%s, (item[url],) ) if not exists: db.insert(raw_data, item)去重看着简单但很多情感分析结果偏大或偏小根因就是数据重复导致同一句话被加权了两遍。这一步在答辩时也能讲清楚属于典型的工程细节。4.2 情感分析自定义词典和阈值参数决定分析质量情感分析模块是整套系统里参数最密集的地方。除了上一章讲的jieba自定义词典和0.7 / 0.3阈值还有一个容易被忽略的参数——SnowNLP的模型本身就是基于电商评论训练的对校园场景文本的适配度有限。体现最明显的是校园网又断了这句话在电商语料里可能会判成中性甚至正面因为它没有典型的负面情感词。解决思路是给SnowNLP之外加一个兜底规则命中自定义负面词典里的词直接把分数压到 0.2 以下不管 SnowNLP 给多少# sentiment.py EXTRA_NEGATIVE_WORDS [难吃, 涨价, 漏水, 断电, 占座, 网卡] def analyze(text: str) - dict: s SnowNLP(text) score s.sentiments # 兜底规则命中校园负面词典直接视为负面 for word in EXTRA_NEGATIVE_WORDS: if word in text: score min(score, 0.2) break label 负面 if score 0.3 else (正面 if score 0.7 else 中性) return {score: round(score, 3), label: label}这里用min(score, 0.2)而不是直接赋值0.2是为了保留 SnowNLP 的连续分值——如果原文里同时有好吃和涨价两个词最终分数会比纯负面场景高一点能反映文本内部的矛盾情绪。兜底规则的阈值不要设到0.1以下否则系统里几乎不会出现中性结果所有提及负面词的文本都被一棍子打死预警记录会塞满无关内容。4.3 主题聚类与预警ntopics 和规则优先级怎么配合主题聚类在毕设里通常用 TF-IDF 加 LDA 实现。LDA 里最重要的参数是主题数n_components。校园舆情的主题数目不需要太多5 到 8 个是合理范围——食堂、宿舍、图书馆、选课、校园网、社团、就业、其他。设成 10 以上就会出现主题重叠比如两个主题里的核心词都是宿舍和热水。# topic.py from sklearn.feature_extraction.text import CountVectorizer from sklearn.decomposition import LatentDirichletAllocation count_vect CountVectorizer( tokenizerjieba.lcut, # 用 jieba 分词器 max_features2000, # 只保留词频最高的 2000 个词 ) X count_vect.fit_transform(doc_list) # doc_list 是待聚类的文档列表 lda LatentDirichletAllocation( n_components6, # 主题数校园场景 5~8 个够用 random_state42, # 固定随机种子保证每次运行结果一致 max_iter20, # 迭代次数小语料 20 次足够收敛 ) lda.fit(X)max_features2000是为了去低频噪声像同学今天这类无意义词如果进了特征矩阵会让聚类结果变成今天 食堂 同学这样看不懂的组合。random_state42必须固定否则每次跑出来的主题分类都不一样答辩时前后说法对不上会被追问。预警和主题聚类不是独立的两层而是协作关系。常见做法是先打好主题标签再在主题内部应用规则引擎——比如食堂主题下的规则阈值比社团主题更敏感因为食堂话题直接关系学生生活质量争议大。规则优先级按更具体的词先判断排列一个帖子同时命中食堂和涨价优先按食堂主题的阈值走而不是按涨价的通用阈值走。5. 避坑清单校园舆情系统最容易翻车的 5 个点5.1 现象MySQL 里中文全是问号数据库表里的中文全部变成???页面加载出来也带着一堆问号。原因建库时的字符集不是utf8mb4或者是utf8但表的排序规则不对。MySQL 的utf8是阉割版不支持四字节的 emoji而utf8mb4才是完整的 UTF-8。校园舆情文本里经常出现颜文字和 emoji只要有一条带 emoji 的记录入表整段文本就被截断成问号。解决删掉旧库重建建库语句加上DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci同时在连接配置里带上charsetutf8mb4不要遗漏。5.2 现象jieba 自定义词典加载失败分词结果没有变化明明写了jieba.load_userdict(campus_words.txt)运行也不报错但校园网还是被切成校园和网卡。原因相对路径是相对进程的工作目录写的。用 IDE 启动时工作目录是项目根目录没问题但用命令行在别的目录启动或者打成 exe 之后相对路径就指向另一个地方词典文件自然是加载了不存在的路径——jieba 会静默跳过而不是报错。解决用os.path.dirname(os.path.abspath(__file__))拼出文件所在目录的绝对路径再拼接词典文件路径。这也是我在第 2 章代码里强调过的写法。5.3 现象pip 安装依赖报一堆 red text卡在某个包上现象是pip install -r requirements.txt装到一半报Failed to build或Microsoft Visual C 14.0 is required。原因Python 版本太新scikit-learn、lxml这些带 C 扩展的包没有对应版本的预编译 wheelpip 只能现场编译而 Windows 上编译 C 扩展需要完整版 Visual Studio Build Tools。解决先换 Python 3.9 再试大概率直接有预编译包如果项目对 Python 版本有硬性要求就去下载对应版本的.whl文件手动安装不要现场编译。这个坑在 3.9 上基本遇不到。5.4 现象采集几轮后目标站点返回 403 或验证码一开始抓得好好的几十条数据之后突然被拒绝访问。原因请求频率被反爬系统识别。你用的是固定间隔比如time.sleep(2)反爬系统把这种规律性的间隔当成机器特征另外请求头里的 User-Agent 太老或太大众化也会加速被封。解决间隔改成random.uniform(3, 6)的随机区间并且准备至少 3 个不同的 UA 轮换使用如果目标站点要求登录才能看内容把浏览器的 Cookie 复制到请求头里模拟真实用户。5.5 现象答辩演示时笔记本能打开手机连同一 WiFi 访问不了Flask 启动时输出Running on http://127.0.0.1:5000这个地址是回环地址只有本机能访问。原因app.run()默认绑定127.0.0.1不监听局域网网卡。演示现场想用手机或教室电脑看效果根本连不上。解决启动参数改为app.run(host0.0.0.0, port5000, debugFalse)让服务监听所有网卡。注意debugTrue在局域网访问时存在安全隐患演示时用False更稳。6. 让答辩演示效果上一个台阶三个具体改进和验证方法6.1 写一个一键生成演示数据的脚本很多源码自带的演示数据只有几十条跑出来的词云和趋势图稀稀拉拉答辩观感很差。与其手动造数据不如写个脚本快速生成一个月的模拟舆情。演示前跑一遍后台的图表立刻饱满起来# generate_demo_data.py import random import datetime import pymysql # 模拟 30 天每天 15~30 条数据 start_date datetime.date.today() - datetime.timedelta(days30) sources [校园论坛, 表白墙, 教务处公告, 贴吧] topics [ 食堂三楼新窗口的麻辣香锅味道不错, 图书馆六楼插座坏了没人修, 宿舍热水晚上十点就没了, 校园网又卡了视频课根本看不了, 选课系统今天下午崩了一会, 操场夜跑灯光太暗建议加灯, ] for day in range(30): date start_date datetime.timedelta(daysday) for _ in range(random.randint(15, 30)): content random.choice(topics) source random.choice(sources) # 执行 INSERT写入 raw_data 表 # 之后在情感分析模块里跑一遍 # 预警记录和图表就都有了这里的关键不是批量造数据而是把造好的数据再跑一次情感分析和聚类流程让预警记录、趋势图、饼图全部联动刷新。只塞数据不跑分析页面上除了数字别的都看不到。6.2 给预警模块加一个未读消息数角标预警模块在毕设里通常只体现为一张表格缺一个直观的提醒动作。最省事又出效果的做法是在后台顶栏加一个未读角标——查询预警记录表中status为 0未读的行数显示在导航栏app.route(/unread_count) def unread_count(): 返回未读预警数量前端定时轮询 count db.query( SELECT COUNT(*) FROM warning_record WHERE status0 )[0][0] return {count: count}前端模板里用一段简单的 JS 轮询这个接口每 30 秒刷一次。答辩时你可以现场演示手动插入一条负面舆情角标数字自动加一点击列表后数字归零。这个细节比任何图表都能说明系统有闭环。6.3 用三个问题验证聚类结果是否可信验证 LDA 主题聚类不是看可视化图漂不漂亮而是问三个问题每个主题下前 10 个核心词是否集中在同一类话题上同一主题内的文本和人工判断是否一致情感分数分布是否符合直觉——比如食堂主题的负面占比应该明显高于社团主题。我自己做这类项目到最后一定会留一个把聚类结果 dump 成 CSV 的脚本一列放主题号、一列放原文打印出来逐条看。答辩前通读一遍这个 CSV被老师问这个主题是怎么得出来的时你能指着一行行文本给出真实依据。这个小习惯救过我不少次希望帮到你。本文还有配套的精品资源点击获取