尧图网页设计 
简介一份面向Python毕业设计与课程设计的校园舆情管理系统完整项目前后端代码齐全适合需要快速搭建Web应用或完成毕设的学生参考。项目采用Python编写后台配合HTML、CSS、JavaScript构建前端界面使用MySQL存储数据整体结构规范、界面简洁经过严格调试确保可直接运行。压缩包共254个文件约37.64MB。其中包含29个Python源码文件、35个JavaScript交互脚本、16个CSS样式、12个HTML页面以及大量GIF演示图和JPG截图便于查看系统各功能模块的运行效果另附SQL数据库脚本可一键导入数据表结构。文件类型覆盖前后端、资源与文档目录清晰。目前已有91人浏览学习。借助这份资料读者可获得完整项目源码、数据库脚本、依赖工具说明及部署指引既能直接运行体验也能参照代码理解校园舆情管理中的信息采集、分类展示、后台管理等模块的实现思路对课程设计、毕业设计或PythonWeb开发入门都具有较高参考价值。1. 从选题到落地Python校园舆情管理系统到底解决什么问题毕业设计选“Python校园舆情管理系统”的同学大多是被 “管理系统” 三个字带偏了以为就是一个增删改查后台套个 Django 模板就交差。真正做起来你才会发现舆情系统的核心工作量在“数据是否来得干净、分析结果是否可信”界面反而是最不费时间的部分。这个标题解决的是“散落在微博、贴吧、校园论坛里的公开讨论如何自动汇总、判断正负面并可视化预警”的完整链路适合想往数据采集与数据分析与可视化方向走的计算机相关专业学生也适合用 Python 爬虫和 ECharts 做作品集的项目。全文我会从架构、建表、采集、情感分析到避坑按一套能跑通的最小方案讲明白。2. 先搭骨架Django MySQL Redis 的舆情数据模型设计拿到一份带 zip 的毕设项目先别急着runserver。你需要先回答三个问题后端用哪个框架、数据存在哪、定时任务怎么调度。这三个决定后面所有代码能不能长在一个稳定的骨架上。2.1 选型思路为什么毕业设计里 Django 比 Flask 更省事舆情管理系统需要的不是一个 API 转发服务而是后台管理、权限、ORM 建模、定时任务、页面渲染这些“重度功能”的组合。对比下来Django 自带 admin、auth、ORM一个命令就能把后台管理界面生成出来这对答辩演示非常有利。Flask 灵活但用户登录、分页、表单校验都要自己装第三方扩展做到一半很容易失控。推荐组合是 Django 4.x MySQL Redis Celery。Redis 在这里扮演两个角色一是 Celery 的消息代理二是后面爬虫去重、热点统计的缓存层。Python 版本建议 3.10原因在第五章会展开。一个典型的requirements.txt长这样注意把容易冲突的包锁到已知能协同工作的版本Django4.2,5.0 mysqlclient2.2 celery5.3,6.0 redis5.0 requests2.31 beautifulsoup44.12 jieba0.42.1 snownlp0.12.3 django-celery-beat2.5逻辑说明Django 主体保证 4.2 以上但不上 5.0避免新版本对mysqlclient的兼容问题Celery 限制在 5.x 是因为 6.x 在 Windows 下的事件循环踩坑更多django-celery-beat用来在后台动态增删定时任务比写死crontab更适合答辩时现场演示。安装时建议建独立虚拟环境不要全局安装。参数说明这里没写具体补丁版本号是因为毕业设计不是生产系统大版本锁住、小版本保持系统默认即可。执行pip install -r requirements.txt后用python -c import django; print(django.get_version())验证安装结果。2.2 数据库表设计舆情主表、关键词表和预警表怎么建舆情系统的业务很集中核心表就三张舆情主表、关键词表、预警表。如果项目源码里给了更多表也是在为这三个实体服务。设计时一定要想清楚一条舆情数据的生命周期从采集到清洗从判断正负面到触发预警最后被人工归档。舆情主表是所有爬虫数据的最终归宿字段设计直接影响去重和查询速度CREATE TABLE opinion_post ( id INT NOT NULL AUTO_INCREMENT, source VARCHAR(20) NOT NULL DEFAULT bbs COMMENT 来源: bbs/weibo/zhihu/others, platform_id VARCHAR(64) NOT NULL COMMENT 平台原始ID, 用于去重, title VARCHAR(255) DEFAULT COMMENT 标题, content LONGTEXT COMMENT 正文内容, author VARCHAR(64) DEFAULT COMMENT 作者, publish_time DATETIME NOT NULL COMMENT 发布时间(清洗后), crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 抓取时间, sentiment TINYINT DEFAULT 0 COMMENT -1负面, 0中性, 1正面, sentiment_score FLOAT DEFAULT 0 COMMENT 情感置信度0~1, keyword_id INT DEFAULT 0 COMMENT 命中的关键词ID, status TINYINT DEFAULT 0 COMMENT 0未处理, 1已归档, PRIMARY KEY (id), UNIQUE KEY uk_source_platform (source, platform_id), KEY idx_publish_time (publish_time), KEY idx_sentiment (sentiment) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT舆情主表;逻辑说明platform_id存的是微博帖子的 mid、贴吧帖子 tid 这类平台原有编号它加source组成唯一索引去重时直接INSERT ... ON DUPLICATE KEY UPDATE或者用 Django 的get_or_create不需要先查再插性能和幂等都解决。publish_time走索引是因为所有趋势统计都按时间范围查询不加索引后期图表接口必然慢。sentiment索引用于负面预警的秒级统计。参数说明utf8mb4不是可选项帖子内容里频繁出现 emojiutf8存不下会直接写入报错。publish_time建DATETIME而不是VARCHAR否则第五章会讲到的“刚刚、3小时前”这类相对时间就没法直接参与查询。预警表单独拆出来的原因预警记录是“事件快照”它记录触发时刻的环境而舆情主表是持续更新的流。两者混在一张表里后面做历史回溯会非常痛苦CREATE TABLE opinion_alert ( id INT NOT NULL AUTO_INCREMENT, level TINYINT DEFAULT 2 COMMENT 1提示, 2警告, 3严重, content VARCHAR(500) NOT NULL COMMENT 预警内容, related_count INT DEFAULT 0 COMMENT 触发时负面条数, keyword_id INT DEFAULT 0 COMMENT 关联关键词, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT舆情预警记录表;逻辑说明related_count记录触发当时的负面数量是为了事后复盘“这个预警是为什么触发的”。很多半路做的项目会漏掉这个字段上线后面对一条预警完全想不起来当时的舆情规模这就是典型的返工点。2.3 目录结构与 settings 配置拿到 zip 包后第一步看什么毕设项目的目录通常比生产项目随意但一个能顺利跑起来的系统结构应该有明显分层。下面的布局是这类系统最常用的“标准答案”campus_opinion/ ├── manage.py ├── requirements.txt ├── config/ # 项目配置: settings/urls/celery │ ├── settings.py │ ├── urls.py │ └── celery.py ├── apps/ │ ├── opinions/ # 舆情业务: models/tasks/crawler │ └── alerts/ # 预警业务 ├── scripts/ │ ├── crawl/ # 爬虫入口 │ ├── analysis/ # 分词/情感/词云脚本 │ └── train_sentiment.py # 情感模型训练脚本 ├── static/ ├── templates/ ├── data/ # 停用词表/自定义词典/标注语料 │ ├── stopwords.txt │ └── campus_words.txt └── logs/ # 采集日志和任务日志拿到 zip 后的第一件事不是建虚拟环境而是看requirements.txt和settings.py里的数据库配置。settings.py里至少要有下面这几个配置块否则即使代码没问题也跑不通# config/settings.py INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, # ... 其他内置模块 apps.opinions, apps.alerts, django_celery_beat, ] DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: campus_opinion, USER: root, PASSWORD: 123456, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, } } CELERY_BROKER_URL redis://127.0.0.1:6379/1 CELERY_RESULT_BACKEND redis://127.0.0.1:6379/2 CELERY_BEAT_SCHEDULER django_celery_beat.schedulers:DatabaseScheduler逻辑说明INSTALLED_APPS里挂上django_celery_beat是为了能在 Django admin 后台里动态配置采集周期。OPTIONS里的charset必须写否则即使数据库建库时指定了utf8mb4Django 连接时也可能按utf8走热门帖子里带 emoji 的文本会直接抛Incorrect string value。Redis 用 db1 和 db2 分开业务缓存与结果存储避免 key 互相干扰。参数说明数据库账号密码占位123456只是示例实际部署时改成自己的。检查配置最快要领是在项目根目录执行python manage.py check它会直接报出实例化错误和配置缺失比盲跑runserver有效率。3. 舆情采集与清洗把微博、贴吧、校园论坛的讨论转成结构化数据很多人以为舆情系统的难点是爬虫其实难点是把“长得完全不像表格”的网页文本变成能入库的干净字段。采集和清洗是一对搭档采集层负责拿原始数据清洗层负责把原始数据变成可分析的素材。这一章我会给出一套 Celery 定时采集 三层清洗的最小实现。3.1 采集任务用 Celery 定时把关键词搜索结果写入 MySQL采集任务在毕业设计里最常见的落法是在后台维护关键词由 Celery Beat 定时触发任务去各平台检索数据入库后再走情感分析。# apps/opinions/tasks.py from celery import shared_task from apps.opinions.crawler import fetch_keyword_page from apps.opinions.models import OpinionPost shared_task(nameopinions.crawl_keyword) def crawl_keyword(keyword: str, keyword_id: int): 定时采集任务抓取关键词页面并去重入库 rows fetch_keyword_page(keyword, max_pages3) for row in rows: defaults { title: row.get(title, ), content: row.get(content, ), author: row.get(author, ), publish_time: row.get(publish_time), keyword_id: keyword_id, } OpinionPost.objects.get_or_create( sourcerow[source], platform_idrow[platform_id], defaultsdefaults, )逻辑说明get_or_create依据前面建的唯一索引(source, platform_id)做幂等插入同一帖子重复抓取不会变成两条记录。fetch_keyword_page返回的是已经过基础处理的列表每个元素至少带source、platform_id、content、publish_time四个字段。参数说明max_pages3是控制单次任务请求量的核心参数毕设演示时 3 页足够展示趋势不需要追求全量调大会拉长任务时间并显著增加触发反爬的概率。任务名nameopinions.crawl_keyword是给 Celery Beat 定时配置使用的标识不要随意改动。采集函数本身不必写得非常复杂但要留好频率控制和失败退避# apps/opinions/crawler.py import time import requests from bs4 import BeautifulSoup def fetch_keyword_page(keyword: str, max_pages: int): 抓取目标站点的搜索结果页, 仅用于教学演示 session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) }) results [] for page in range(1, max_pages 1): try: params {q: keyword, page: page} resp session.get( https://example-campus.edu/search, paramsparams, timeout5 ) if resp.status_code ! 200: time.sleep(5) continue soup BeautifulSoup(resp.text, html.parser) for item in soup.select(.search-result-item): results.append(parse_item(item, keyword)) # 均匀间隔, 避免瞬时压力 time.sleep(1.5 page * 0.3) except requests.RequestException as exc: print(f[crawler] keyword{keyword} page{page} error: {exc}) time.sleep(3) return results逻辑说明这里用requests.Session而不是全局requests.get是为了让 Cookie 在同一次任务的多个翻页请求之间保持连续很多站点翻页后回跳登录页就是因为没有复用 Session。select(.search-result-item)是按目标站点结构调整的选择器示例实际部署时按抓取对象的 HTML 结构修正。异常分支里至少打印日志并 sleep 3 秒避免某个关键词出错导致整条任务链中断。参数说明timeout5是单次请求最长的等待秒数超过即抛异常防止某个慢接口把 Celery worker 占住。time.sleep(1.5 page * 0.3)是“随页码递增的间隔”翻到越深越慢这是对连续翻页最友好的节奏比固定 2 秒更容易避开频率检测。提示毕业设计中的爬虫应使用公开页面、测试账号并在合规范围内控制频率不要绕过登录鉴权不要抓取非公开数据。3.2 文本清洗去噪、去重、分词和“刚刚 / 3小时前”这类时间怎么处理抓下来的原始文本不能直接用里面掺杂着话题标签、提醒、转发标记、链接和营销号模板。若不清理情感分析会把“转发微博”这种词也当成有效内容。# scripts/analysis/clean.py import re import jieba def clean_text(raw: str) - str: if not raw: return text re.sub(r#.*?#, , raw) # 去掉 #话题# text re.sub(r[\w-], , raw) # 去掉 用户名 text re.sub(rhttps?://\S, , text) # 去掉链接 text re.sub(r\s, , text) # 合并空白 return text.strip() STOPWORDS set(open(data/stopwords.txt, encodingutf-8).read().split()) def tokenize(text: str): words jieba.lcut(clean_text(text)) return [w for w in words if w not in STOPWORDS and len(w) 1]逻辑说明四个正则分别对应校园舆情里最常出现的噪声。话题标签一般直接删但也可以改成记录标签文本作为分类输入毕业设计阶段先删掉最简单。len(w) 1是为了筛掉单字校园讨论里“菜”“贵”这种单字在统计词云时没有合并价值保留反而让图变得稀疏。参数说明data/stopwords.txt是自己维护的停用词表常见平台词“觉得”“就是”“一个”以及网络噪音“哈哈哈哈”“转发”都放进去。停用词表不用追求大而全按自己采集到的数据反馈持续补充才是正常心态几十条也很够用。时间字段是最容易踩坑的地方检索结果里的发布时间有“刚刚”“3 分钟前”“昨天 22:10”、绝对时间2024-05-20 08:30三种形态全部存成字符串会让趋势查询无法按时间聚合。这里写一个最小兼容函数# scripts/analysis/time_parse.py from datetime import datetime, timedelta def parse_relative_time(text: str) - datetime: 把相对时间字符串转换为标准 datetime, 解析失败时给过去时间 now datetime.now() text text.strip() if 刚刚 in text: return now if 分钟前 in text: minutes int(text.split(分钟前)[0]) return now - timedelta(minutesminutes) if 小时前 in text: hours int(text.split(小时前)[0]) return now - timedelta(hourshours) if 昨天 in text: hour_str text.replace(昨天 , ) hour datetime.strptime(hour_str, %H:%M) return now - timedelta(days1, hoursnow.hour - hour.hour, minutesnow.minute - hour.minute) try: return datetime.strptime(text, %Y-%m-%d %H:%M) except ValueError: return now - timedelta(days3)逻辑说明now - timedelta(days1, hoursnow.hour - hour.hour, ...)这段是把“昨天 22:10”换算成昨天的真实时刻不这样处理所有昨天帖子的publish_time都会集中在今天零点趋势曲线会出现每天 0 点过山车式的假象。最后的except ValueError把无法识别的时间兜底成三天前保证入库不会因为脏时间崩溃但兜底数据不会污染统计主区间。参数说明这个函数的输出精度到分钟因为舆情趋势分析不需要秒级精度。实际毕设里可以把调用包一个try/except再包一层因为个别平台会返回“2024-05-20”这种没有时分的数据。3.3 关键参数请求间隔、重试退避和数据量上限的取舍采集层的参数直接影响两个结果数据能不能抓全、账号能不能活到答辩那天。这里有一张我常用的参数基准表适合校园舆情这种中小规模数据量参数建议值说明请求间隔1.5s ~ 3s 随机固定间隔反而更容易被识别单关键词最大页数3 页足够展示趋势避免捞历史数据单任务超时5s防止慢接口占住 worker重试次数3 次超过后跳过该页不阻塞任务退避策略2s 指数增长连续失败时自动拉长间隔每轮任务间隔30~60 分钟校园舆情不必实时太频繁会封参数说明间隔不要写成固定sleep(2)而是在 1.5 到 3 秒之间取随机值曲线更接近人工操作。重试超过三次就放弃当前页毕设场景里数据完整性优先级低于任务稳定性一页失败不应该拖垮整个关键词任务。任务间隔 30 分钟是平衡点演示时也能接受在几分钟内看到新数据被采进来。限制数据量上限在毕设里特别容易被忽略。爬虫跑一天可能抓回几万条无意义转发入库前在任务入口按max_items_per_run200截断def fetch_keyword_page(keyword: str, max_pages3, max_items200): ... if len(results) max_items: break return results[:max_items]逻辑说明这个截断不是数据完整性上的最佳选择但毕设阶段能防止本地 MySQL 被几 GB 的“自动转发”文本撑爆也能保证舆情统计在可控的数据范围内。参数max_items放在函数签名里而不是写死是为了测试时可以传入更小值快速跑通链路。4. 情感分析与趋势可视化从“有数据”到“看得懂数据”数据落库只是系统完成了一半另一半是把数据翻译成“最近校园里的负面声音在变多还是变少”。情感分析决定舆情是否触发预警可视化决定答辩时能否三分钟讲清楚结论。4.1 情感模型SnowNLP 还是自定义词典校园语料的识别策略情感分析在毕设项目里有两种常见路线直接用现成的 SnowNLP或者引入 BERT 一类的深度学习模型。前者开箱即用但默认模型是在电商评论语料上训练的对“食堂又涨价了”“宿舍热水总是坏”这类校园口语判断经常失灵后者效果更好但配置 CUDA、加载预训练权重这一套下来很多毕设时间就耗进去了。折中方案是不换库只换模型用自己标注的校园语料重训一个 SnowNLP 情感分类器准确率能提升一截还保留了轻量部署的优势。# scripts/train_sentiment.py from snownlp import sentiment # neg.txt 和 pos.txt 每行一条人工标注的校园舆情文本 sentiment.train(data/train_neg.txt, data/train_pos.txt) sentiment.save(models/campus_sentiment.marshal)逻辑说明train的两个文件分别存放负面和正面语料行数建议各 2000 条以上。语料可以从之前采集的数据里抽样再人工标记也可以自己随手写校园场景句子补足。训练完成后save到自定义路径预测时就不再用默认的电商模型。# apps/opinions/sentiment.py from snownlp.sentiment import Sentiment classifier Sentiment() classifier.load(models/campus_sentiment.marshal) def predict_sentiment(text: str) - int: if not text: return 0 score classifier.predict(text) if score 0.6: return 1 if score 0.4: return -1 return 0逻辑说明classifier.predict返回 0 到 1 之间的正情感概率。阈值设成 0.6 和 0.4 是留出 0.4~0.6 的中间地带避免“其实还行”这类模糊文本被强行切成正或负。实际标注数据时你会发现校园舆情里中性内容占比很高强切反而让统计失真。参数说明阈值可以按实际预测结果微调。如果负面召回太少就把下阈值升到 0.5如果正面误报多就把上阈值升到 0.65。这类修改要记在项目说明里答辩时老师问“阈值为什么取 0.6”你有据可答。网络用语是另一个重灾区“排雷”“避雷”“懂的都懂”在默认词典里完全没有。解决方法是给 jieba 加校园词典再接一层关键词兜底# apps/opinions/sentiment.py 追加 import jieba jieba.load_userdict(data/campus_words.txt) STRONG_NEGATIVE_WORDS [乱收费, 吃出虫子, 半夜断电, 宿舍漏水, 挂科率] def predict_sentiment(text: str) - int: if any(word in text for word in STRONG_NEGATIVE_WORDS): return -1 base_score 0 # 先走自定义模型, 逻辑与前面相同 ...逻辑说明自定义词典文件里每一行是“词汇 词频 词性”例如乱收费 20 n。它是让 jieba 正确切分新词的基础。强负面词列表是“规则兜底”当文本里出现明确负面实义词时直接判负不依赖概率模型。毕业设计里这种规则与模型叠加的做法比单纯追求算法复杂度更好落地也更容易向答辩老师解释。4.2 预警规则负面舆情 1 小时超过阈值自动推送预警是舆情系统区别于普通信息管理系统的关键功能。它的规则不复杂难在阈值怎么取、怎么避免“狼来了”效应。# apps/alerts/checker.py from datetime import timedelta from django.utils import timezone from apps.opinions.models import OpinionPost from apps.alerts.models import OpinionAlert CHECK_WINDOW_MINUTES 60 WARN_THRESHOLD 5 def check_alerts_for_keyword(keyword_id: int): start timezone.now() - timedelta(minutesCHECK_WINDOW_MINUTES) recent_negatives OpinionPost.objects.filter( keyword_idkeyword_id, sentiment-1, publish_time__gtestart, ).count() if recent_negatives WARN_THRESHOLD: OpinionAlert.objects.create( level2, contentf关键词 {keyword_id} 近1小时内负面舆情 {recent_negatives} 条, related_countrecent_negatives, keyword_idkeyword_id, )逻辑说明预警的本质是“滑动窗口计数”。1 小时内负面数量达到 5 条就产生一条预警记录窗口信息存在related_count里。这个实现里没做幂等同一小时重复执行会重复建预警实际使用时可以在预警表加唯一约束或者用get_or_create按(keyword_id, created_at)去重毕设阶段可以先不处理。参数说明CHECK_WINDOW_MINUTES60和WARN_THRESHOLD5是两个可调参数。阈值 5 对校园场景偏敏感适合演示时快速看到预警效果真实部署建议改成 20 条/小时。想更精细可以做“负面占比预警”即 1 小时内负面数除以总舆情数超过 30% 才触发这个公式对突发“一条大热点转发几百条”的场景更准确也更好讲。4.3 可视化面板用 ECharts 显示趋势、词云和热点排行可视化是答辩的加分项也是很多人翻车的地方。ECharts 比 Matplotlib 更适合网页端展示因为可以直接在 Django 模板里渲染不用先生成图片文件。趋势图是必选项它直接展示系统“从数据到结论”的能力!-- templates/opinions/trend.html -- div idsentiment-trend styleheight:400px;/div script src/static/js/echarts.min.js/script script fetch(/api/opinions/trend?days30) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(sentiment-trend)); chart.setOption({ tooltip: { trigger: axis }, legend: { data: [负面, 正面] }, xAxis: { type: category, data: data.days }, yAxis: { type: value }, series: [ { name: 负面, type: bar, data: data.neg }, { name: 正面, type: line, data: data.pos } ] }); }); /script对应的数据接口用 Django 的JsonResponse返回注意一个关键参数# apps/opinions/views.py from django.http import JsonResponse from django.db.models import Count from django.utils import timezone from datetime import timedelta def trend_api(request): days int(request.GET.get(days, 30)) start timezone.now() - timedelta(daysdays) rows OpinionPost.objects.filter(publish_time__gtestart) \ .extra(select{day: DATE_FORMAT(publish_time, %%Y-%%m-%%d)}) \ .values(day, sentiment) \ .annotate(countCount(id)) result {days: [], neg: [], pos: []} day_map {} for row in rows: day_map.setdefault(row[day], {1: 0, -1: 0, 0: 0}) day_map[row[day]][row[sentiment]] row[count] for day, counts in sorted(day_map.items()): result[days].append(day) result[neg].append(counts.get(-1, 0)) result[pos].append(counts.get(1, 0)) return JsonResponse(result, json_dumps_params{ensure_ascii: False})逻辑说明核心在extra里的DATE_FORMAT它把publish_time按天截断让查询结果以天为粒度聚合返回给前端的数据结构直接对齐 ECharts 的xAxis.data和series.data。sorted(day_map.items())保证日期按字符串升序排列因为YYYY-MM-DD的字符串排序与时间顺序一致这里不需要额外转时间对象。参数说明json_dumps_params{ensure_ascii: False}这个参数很重要。Django 默认的JsonResponse会把中文转成\uXXXX转义前端显示正常但浏览器调试时满屏反斜杠影响排查设置成False让接口直接返回可读中文。词云可以走后端生成wordcloud图片再渲染到模板也可以前端用 echarts-wordcloud 插件实现毕设里后端生成图片更省资源接口返回图片 URL 即可。5. 避坑指南校园舆情系统跑不起来时先查这 5 个地方这部分是血泪经验汇总。以下 5 个问题把毕业设计同学卡住的比例最高按发生频率从高到低排列每一条都按“现象 → 原因 → 解决”来写。5.1 Python 3.12 装不上依赖用 py -3.10 建虚拟环境现象pip install mysqlclient或pip install jieba时终端报Microsoft Visual C 14.0 is required或者snownlp装完导入报ImportError。原因新装的 Python 3.12 里部分第三方包没有预编译的 wheel会即时尝试本地编译而 Windows 开发环境通常缺 C 构建工具。即使装上了某些老包对 3.12 的 ABI 也不兼容。解决用 Python 3.10 建虚拟环境多数包都有现成的 wheelpy -3.10 -m venv venv venv\Scripts\activate python --version pip install -r requirements.txt逻辑说明py -3.10是 Windows 上 Python Launcher 的调用方式系统里装了 3.10 的解释器就能直接用。创建独立venv而不是全局安装一是避免污染系统 Python二是requirements.txt的版本依赖只在虚拟环境里生效测试完可以直接删掉重建。装完依赖后用pip freeze看版本是否与requirements.txt一致防止 pip 自动升级了子依赖。5.2 Celery 任务不执行Windows 下必须加 --poolsolo现象celery beat启动了定时任务也在日志里出现但采集任务迟迟不跑worker 终端毫无输出。原因Windows 上 Celery 5.x 默认的prefork进程池与 Windows 的进程启动机制不兼容 worker 起不来但进程没退出导致任务一直积压在队列里不消费。解决手动启动 worker 时限制用 solo 线程池并和包版本一并确认celery -A config worker --loglevelinfo --poolsolo celery -A config beat --loglevelinfo逻辑说明--poolsolo让 Celery 在单进程内顺序执行任务避免 Windows 下多进程事件循环的兼容问题。缺点是并发能力下降但毕业设计的数据量完全够用。beat 是调度器它只管把任务按计划发到 Redis真正执行靠 worker两个终端都要开只开 beat 不 worker 是排行榜第一的错误姿势。5.3 MySQL 中文乱码建库没加 utf8mb4现象后台页面上所有中文内容显示成????或者Django RuntimeError: Incorrect string value。原因建数据库时没有指定字符集MySQL 默认latin1存不了中文。解决建库时一次性指定而不是建完再改CREATE DATABASE campus_opinion DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;如果库已经建好可以用一条命令补救ALTER DATABASE campus_opinion CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;逻辑说明建表时DEFAULT CHARSETutf8mb4也写了但表依赖的库字符集不对时表依然可能继承错误的默认值。ALTER DATABASE只改库的默认字符集已经存在的表还需要逐表ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4毕设阶段刚建完库直接改库再同步表结构即可。5.4 爬虫半小时就封频率、 Cookie 和功能开关现象采集任务开始后十几分钟请求状态码从 200 变成 403之后所有采集结果为空。原因请求间隔固定且太短站点按 IP 和 User-Agent 的组合判断为脚本行为。另一个常见原因是登录态过期没有 Cookie 的 Request 被重定向到登录页。解决控制频率是第一次修复把单次抓取间隔调到 2 秒以上并加上随机抖动。同时在settings.py里做一个开关方便演示时快速切断采集任务# config/settings.py CRAWLER_ENABLED True # apps/opinions/tasks.py 中增加 from django.conf import settings if not settings.CRAWLER_ENABLED: return {skip: crawler disabled}逻辑说明这个开关的价值在于答辩现场如果网络状态不稳定你可以直接说明“采集服务当前关闭演示用静态数据”而不是现场重试十几分钟。Cookie 的问题更隐蔽登录后的 Cookie 过期时间可能只有一天建议把 Cookie 导出到配置文件里并在失败日志里提示“请更新 Cookie”而不是默默重试。5.5 情感分析全是中性词典没更新、训练语料不够现象可视化面板里正负面几乎没有波动折线图贴近零轴除了内容全是中性的线上系统。原因SnowNLP 默认模型是电商语料校园场景的“涨价”“熄灯”“挂科率”等词汇在它的词典里是低频词另外标注语料太少模型没有学到校园讨论的语言习惯。解决分两步走先用 4.1 节的自定义词典让 jieba 正确切词再扩充训练集。如果在演示前只有一个晚上的时间优先做“规则兜底”把明确负面的词汇加进STRONG_NEGATIVE_WORDS。效果立竿见影而且逻辑可以被答辩评委理解。# data/campus_words.txt 内容示例 食堂 20 n 宿管 15 n 乱收费 30 n 停水 20 v逻辑说明词典格式是“词 频次 词性”频次是 jieba 切词时的优先级词性要按真实词性写n是名词v是动词。训练语料则是另一个坑标注 100 条和标注 1000 条的结果天壤之别建议从采集库里抽取最热门的 500 条人工标一遍加上规则词就能让输出分布明显分化。6. 用它完成答辩验证脚本、演示流程与可选的进阶方向这章说怎么把系统“变成”你真正能做主的东西。毕设答辩的评价标准不是功能有多新而是你在现场能复现和解释所以完整演示链路比花哨功能更值钱。验收前先写三个最小测试用例只测最核心的业务逻辑作为“代码能跑”的证据# apps/opinions/tests.py from django.test import TestCase from apps.opinions.sentiment import predict_sentiment from scripts.analysis.clean import clean_text class OpinionTests(TestCase): def test_url_removed(self): self.assertEqual( clean_text(食堂涨价了 https://t.cn/abc), 食堂涨价了 ) def test_negative_sentiment(self): self.assertEqual(predict_sentiment(半夜断电还不管), -1) def test_alert_record_created(self): # 构造数据并触发预警, 断言 OpinionAlert 数量1 ...逻辑说明第一个用例验证清洗函数能去掉 URL第二个用例验证强规则词能触发负面判断第三个用例验证预警记录能被创建。三个用例覆盖从文本处理到业务动作的最小闭环跑通python manage.py test就能证明系统核心逻辑成立答辩时现场跑一遍比任何 PPT 截图都有说服力。演示流程上我建议按“造数据—看趋势—看预警”三步走启动 Redis、worker、beat、runserver后在后台添加一个演示关键词手动触发一次采集任务刷新趋势接口看到曲线变化再插入几条负面文本触发阈值让预警记录出现在后台列表里。全程控制在 5 分钟左右一气呵成不要在答辩现场踩长命令。想继续加深度的话有三个方向性价比最高第一个是给预警加时序去重同一关键词在一小时内只创建一条预警这个改动小且能体现设计思考第二个是引入 TF-IDF 加 DBSCAN 的简单事件聚类把零散帖子按主题合并让“食堂涨价”和“超市打折”分开第三个是接企业微信机器人 webhook让预警直接推到手机这是最直观的展示亮点也就几行代码。我每次拿到一套爬虫类毕设源码第一件事永远是确认 Python 版本与依赖关系这在校园舆情系统里比任何算法调优都先决定生死。先跑通最小闭环再谈优化这套系统的价值就一定能讲清楚。希望帮到你。本文还有配套的精品资源点击获取 Python校园舆情管理系统：爬虫、情感分析与可视化实战
简介一份面向Python毕业设计与课程设计的校园舆情管理系统完整项目前后端代码齐全适合需要快速搭建Web应用或完成毕设的学生参考。项目采用Python编写后台配合HTML、CSS、JavaScript构建前端界面使用MySQL存储数据整体结构规范、界面简洁经过严格调试确保可直接运行。压缩包共254个文件约37.64MB。其中包含29个Python源码文件、35个JavaScript交互脚本、16个CSS样式、12个HTML页面以及大量GIF演示图和JPG截图便于查看系统各功能模块的运行效果另附SQL数据库脚本可一键导入数据表结构。文件类型覆盖前后端、资源与文档目录清晰。目前已有91人浏览学习。借助这份资料读者可获得完整项目源码、数据库脚本、依赖工具说明及部署指引既能直接运行体验也能参照代码理解校园舆情管理中的信息采集、分类展示、后台管理等模块的实现思路对课程设计、毕业设计或PythonWeb开发入门都具有较高参考价值。1. 从选题到落地Python校园舆情管理系统到底解决什么问题毕业设计选“Python校园舆情管理系统”的同学大多是被 “管理系统” 三个字带偏了以为就是一个增删改查后台套个 Django 模板就交差。真正做起来你才会发现舆情系统的核心工作量在“数据是否来得干净、分析结果是否可信”界面反而是最不费时间的部分。这个标题解决的是“散落在微博、贴吧、校园论坛里的公开讨论如何自动汇总、判断正负面并可视化预警”的完整链路适合想往数据采集与数据分析与可视化方向走的计算机相关专业学生也适合用 Python 爬虫和 ECharts 做作品集的项目。全文我会从架构、建表、采集、情感分析到避坑按一套能跑通的最小方案讲明白。2. 先搭骨架Django MySQL Redis 的舆情数据模型设计拿到一份带 zip 的毕设项目先别急着runserver。你需要先回答三个问题后端用哪个框架、数据存在哪、定时任务怎么调度。这三个决定后面所有代码能不能长在一个稳定的骨架上。2.1 选型思路为什么毕业设计里 Django 比 Flask 更省事舆情管理系统需要的不是一个 API 转发服务而是后台管理、权限、ORM 建模、定时任务、页面渲染这些“重度功能”的组合。对比下来Django 自带 admin、auth、ORM一个命令就能把后台管理界面生成出来这对答辩演示非常有利。Flask 灵活但用户登录、分页、表单校验都要自己装第三方扩展做到一半很容易失控。推荐组合是 Django 4.x MySQL Redis Celery。Redis 在这里扮演两个角色一是 Celery 的消息代理二是后面爬虫去重、热点统计的缓存层。Python 版本建议 3.10原因在第五章会展开。一个典型的requirements.txt长这样注意把容易冲突的包锁到已知能协同工作的版本Django4.2,5.0 mysqlclient2.2 celery5.3,6.0 redis5.0 requests2.31 beautifulsoup44.12 jieba0.42.1 snownlp0.12.3 django-celery-beat2.5逻辑说明Django 主体保证 4.2 以上但不上 5.0避免新版本对mysqlclient的兼容问题Celery 限制在 5.x 是因为 6.x 在 Windows 下的事件循环踩坑更多django-celery-beat用来在后台动态增删定时任务比写死crontab更适合答辩时现场演示。安装时建议建独立虚拟环境不要全局安装。参数说明这里没写具体补丁版本号是因为毕业设计不是生产系统大版本锁住、小版本保持系统默认即可。执行pip install -r requirements.txt后用python -c import django; print(django.get_version())验证安装结果。2.2 数据库表设计舆情主表、关键词表和预警表怎么建舆情系统的业务很集中核心表就三张舆情主表、关键词表、预警表。如果项目源码里给了更多表也是在为这三个实体服务。设计时一定要想清楚一条舆情数据的生命周期从采集到清洗从判断正负面到触发预警最后被人工归档。舆情主表是所有爬虫数据的最终归宿字段设计直接影响去重和查询速度CREATE TABLE opinion_post ( id INT NOT NULL AUTO_INCREMENT, source VARCHAR(20) NOT NULL DEFAULT bbs COMMENT 来源: bbs/weibo/zhihu/others, platform_id VARCHAR(64) NOT NULL COMMENT 平台原始ID, 用于去重, title VARCHAR(255) DEFAULT COMMENT 标题, content LONGTEXT COMMENT 正文内容, author VARCHAR(64) DEFAULT COMMENT 作者, publish_time DATETIME NOT NULL COMMENT 发布时间(清洗后), crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 抓取时间, sentiment TINYINT DEFAULT 0 COMMENT -1负面, 0中性, 1正面, sentiment_score FLOAT DEFAULT 0 COMMENT 情感置信度0~1, keyword_id INT DEFAULT 0 COMMENT 命中的关键词ID, status TINYINT DEFAULT 0 COMMENT 0未处理, 1已归档, PRIMARY KEY (id), UNIQUE KEY uk_source_platform (source, platform_id), KEY idx_publish_time (publish_time), KEY idx_sentiment (sentiment) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT舆情主表;逻辑说明platform_id存的是微博帖子的 mid、贴吧帖子 tid 这类平台原有编号它加source组成唯一索引去重时直接INSERT ... ON DUPLICATE KEY UPDATE或者用 Django 的get_or_create不需要先查再插性能和幂等都解决。publish_time走索引是因为所有趋势统计都按时间范围查询不加索引后期图表接口必然慢。sentiment索引用于负面预警的秒级统计。参数说明utf8mb4不是可选项帖子内容里频繁出现 emojiutf8存不下会直接写入报错。publish_time建DATETIME而不是VARCHAR否则第五章会讲到的“刚刚、3小时前”这类相对时间就没法直接参与查询。预警表单独拆出来的原因预警记录是“事件快照”它记录触发时刻的环境而舆情主表是持续更新的流。两者混在一张表里后面做历史回溯会非常痛苦CREATE TABLE opinion_alert ( id INT NOT NULL AUTO_INCREMENT, level TINYINT DEFAULT 2 COMMENT 1提示, 2警告, 3严重, content VARCHAR(500) NOT NULL COMMENT 预警内容, related_count INT DEFAULT 0 COMMENT 触发时负面条数, keyword_id INT DEFAULT 0 COMMENT 关联关键词, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT舆情预警记录表;逻辑说明related_count记录触发当时的负面数量是为了事后复盘“这个预警是为什么触发的”。很多半路做的项目会漏掉这个字段上线后面对一条预警完全想不起来当时的舆情规模这就是典型的返工点。2.3 目录结构与 settings 配置拿到 zip 包后第一步看什么毕设项目的目录通常比生产项目随意但一个能顺利跑起来的系统结构应该有明显分层。下面的布局是这类系统最常用的“标准答案”campus_opinion/ ├── manage.py ├── requirements.txt ├── config/ # 项目配置: settings/urls/celery │ ├── settings.py │ ├── urls.py │ └── celery.py ├── apps/ │ ├── opinions/ # 舆情业务: models/tasks/crawler │ └── alerts/ # 预警业务 ├── scripts/ │ ├── crawl/ # 爬虫入口 │ ├── analysis/ # 分词/情感/词云脚本 │ └── train_sentiment.py # 情感模型训练脚本 ├── static/ ├── templates/ ├── data/ # 停用词表/自定义词典/标注语料 │ ├── stopwords.txt │ └── campus_words.txt └── logs/ # 采集日志和任务日志拿到 zip 后的第一件事不是建虚拟环境而是看requirements.txt和settings.py里的数据库配置。settings.py里至少要有下面这几个配置块否则即使代码没问题也跑不通# config/settings.py INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, # ... 其他内置模块 apps.opinions, apps.alerts, django_celery_beat, ] DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: campus_opinion, USER: root, PASSWORD: 123456, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, } } CELERY_BROKER_URL redis://127.0.0.1:6379/1 CELERY_RESULT_BACKEND redis://127.0.0.1:6379/2 CELERY_BEAT_SCHEDULER django_celery_beat.schedulers:DatabaseScheduler逻辑说明INSTALLED_APPS里挂上django_celery_beat是为了能在 Django admin 后台里动态配置采集周期。OPTIONS里的charset必须写否则即使数据库建库时指定了utf8mb4Django 连接时也可能按utf8走热门帖子里带 emoji 的文本会直接抛Incorrect string value。Redis 用 db1 和 db2 分开业务缓存与结果存储避免 key 互相干扰。参数说明数据库账号密码占位123456只是示例实际部署时改成自己的。检查配置最快要领是在项目根目录执行python manage.py check它会直接报出实例化错误和配置缺失比盲跑runserver有效率。3. 舆情采集与清洗把微博、贴吧、校园论坛的讨论转成结构化数据很多人以为舆情系统的难点是爬虫其实难点是把“长得完全不像表格”的网页文本变成能入库的干净字段。采集和清洗是一对搭档采集层负责拿原始数据清洗层负责把原始数据变成可分析的素材。这一章我会给出一套 Celery 定时采集 三层清洗的最小实现。3.1 采集任务用 Celery 定时把关键词搜索结果写入 MySQL采集任务在毕业设计里最常见的落法是在后台维护关键词由 Celery Beat 定时触发任务去各平台检索数据入库后再走情感分析。# apps/opinions/tasks.py from celery import shared_task from apps.opinions.crawler import fetch_keyword_page from apps.opinions.models import OpinionPost shared_task(nameopinions.crawl_keyword) def crawl_keyword(keyword: str, keyword_id: int): 定时采集任务抓取关键词页面并去重入库 rows fetch_keyword_page(keyword, max_pages3) for row in rows: defaults { title: row.get(title, ), content: row.get(content, ), author: row.get(author, ), publish_time: row.get(publish_time), keyword_id: keyword_id, } OpinionPost.objects.get_or_create( sourcerow[source], platform_idrow[platform_id], defaultsdefaults, )逻辑说明get_or_create依据前面建的唯一索引(source, platform_id)做幂等插入同一帖子重复抓取不会变成两条记录。fetch_keyword_page返回的是已经过基础处理的列表每个元素至少带source、platform_id、content、publish_time四个字段。参数说明max_pages3是控制单次任务请求量的核心参数毕设演示时 3 页足够展示趋势不需要追求全量调大会拉长任务时间并显著增加触发反爬的概率。任务名nameopinions.crawl_keyword是给 Celery Beat 定时配置使用的标识不要随意改动。采集函数本身不必写得非常复杂但要留好频率控制和失败退避# apps/opinions/crawler.py import time import requests from bs4 import BeautifulSoup def fetch_keyword_page(keyword: str, max_pages: int): 抓取目标站点的搜索结果页, 仅用于教学演示 session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) }) results [] for page in range(1, max_pages 1): try: params {q: keyword, page: page} resp session.get( https://example-campus.edu/search, paramsparams, timeout5 ) if resp.status_code ! 200: time.sleep(5) continue soup BeautifulSoup(resp.text, html.parser) for item in soup.select(.search-result-item): results.append(parse_item(item, keyword)) # 均匀间隔, 避免瞬时压力 time.sleep(1.5 page * 0.3) except requests.RequestException as exc: print(f[crawler] keyword{keyword} page{page} error: {exc}) time.sleep(3) return results逻辑说明这里用requests.Session而不是全局requests.get是为了让 Cookie 在同一次任务的多个翻页请求之间保持连续很多站点翻页后回跳登录页就是因为没有复用 Session。select(.search-result-item)是按目标站点结构调整的选择器示例实际部署时按抓取对象的 HTML 结构修正。异常分支里至少打印日志并 sleep 3 秒避免某个关键词出错导致整条任务链中断。参数说明timeout5是单次请求最长的等待秒数超过即抛异常防止某个慢接口把 Celery worker 占住。time.sleep(1.5 page * 0.3)是“随页码递增的间隔”翻到越深越慢这是对连续翻页最友好的节奏比固定 2 秒更容易避开频率检测。提示毕业设计中的爬虫应使用公开页面、测试账号并在合规范围内控制频率不要绕过登录鉴权不要抓取非公开数据。3.2 文本清洗去噪、去重、分词和“刚刚 / 3小时前”这类时间怎么处理抓下来的原始文本不能直接用里面掺杂着话题标签、提醒、转发标记、链接和营销号模板。若不清理情感分析会把“转发微博”这种词也当成有效内容。# scripts/analysis/clean.py import re import jieba def clean_text(raw: str) - str: if not raw: return text re.sub(r#.*?#, , raw) # 去掉 #话题# text re.sub(r[\w-], , raw) # 去掉 用户名 text re.sub(rhttps?://\S, , text) # 去掉链接 text re.sub(r\s, , text) # 合并空白 return text.strip() STOPWORDS set(open(data/stopwords.txt, encodingutf-8).read().split()) def tokenize(text: str): words jieba.lcut(clean_text(text)) return [w for w in words if w not in STOPWORDS and len(w) 1]逻辑说明四个正则分别对应校园舆情里最常出现的噪声。话题标签一般直接删但也可以改成记录标签文本作为分类输入毕业设计阶段先删掉最简单。len(w) 1是为了筛掉单字校园讨论里“菜”“贵”这种单字在统计词云时没有合并价值保留反而让图变得稀疏。参数说明data/stopwords.txt是自己维护的停用词表常见平台词“觉得”“就是”“一个”以及网络噪音“哈哈哈哈”“转发”都放进去。停用词表不用追求大而全按自己采集到的数据反馈持续补充才是正常心态几十条也很够用。时间字段是最容易踩坑的地方检索结果里的发布时间有“刚刚”“3 分钟前”“昨天 22:10”、绝对时间2024-05-20 08:30三种形态全部存成字符串会让趋势查询无法按时间聚合。这里写一个最小兼容函数# scripts/analysis/time_parse.py from datetime import datetime, timedelta def parse_relative_time(text: str) - datetime: 把相对时间字符串转换为标准 datetime, 解析失败时给过去时间 now datetime.now() text text.strip() if 刚刚 in text: return now if 分钟前 in text: minutes int(text.split(分钟前)[0]) return now - timedelta(minutesminutes) if 小时前 in text: hours int(text.split(小时前)[0]) return now - timedelta(hourshours) if 昨天 in text: hour_str text.replace(昨天 , ) hour datetime.strptime(hour_str, %H:%M) return now - timedelta(days1, hoursnow.hour - hour.hour, minutesnow.minute - hour.minute) try: return datetime.strptime(text, %Y-%m-%d %H:%M) except ValueError: return now - timedelta(days3)逻辑说明now - timedelta(days1, hoursnow.hour - hour.hour, ...)这段是把“昨天 22:10”换算成昨天的真实时刻不这样处理所有昨天帖子的publish_time都会集中在今天零点趋势曲线会出现每天 0 点过山车式的假象。最后的except ValueError把无法识别的时间兜底成三天前保证入库不会因为脏时间崩溃但兜底数据不会污染统计主区间。参数说明这个函数的输出精度到分钟因为舆情趋势分析不需要秒级精度。实际毕设里可以把调用包一个try/except再包一层因为个别平台会返回“2024-05-20”这种没有时分的数据。3.3 关键参数请求间隔、重试退避和数据量上限的取舍采集层的参数直接影响两个结果数据能不能抓全、账号能不能活到答辩那天。这里有一张我常用的参数基准表适合校园舆情这种中小规模数据量参数建议值说明请求间隔1.5s ~ 3s 随机固定间隔反而更容易被识别单关键词最大页数3 页足够展示趋势避免捞历史数据单任务超时5s防止慢接口占住 worker重试次数3 次超过后跳过该页不阻塞任务退避策略2s 指数增长连续失败时自动拉长间隔每轮任务间隔30~60 分钟校园舆情不必实时太频繁会封参数说明间隔不要写成固定sleep(2)而是在 1.5 到 3 秒之间取随机值曲线更接近人工操作。重试超过三次就放弃当前页毕设场景里数据完整性优先级低于任务稳定性一页失败不应该拖垮整个关键词任务。任务间隔 30 分钟是平衡点演示时也能接受在几分钟内看到新数据被采进来。限制数据量上限在毕设里特别容易被忽略。爬虫跑一天可能抓回几万条无意义转发入库前在任务入口按max_items_per_run200截断def fetch_keyword_page(keyword: str, max_pages3, max_items200): ... if len(results) max_items: break return results[:max_items]逻辑说明这个截断不是数据完整性上的最佳选择但毕设阶段能防止本地 MySQL 被几 GB 的“自动转发”文本撑爆也能保证舆情统计在可控的数据范围内。参数max_items放在函数签名里而不是写死是为了测试时可以传入更小值快速跑通链路。4. 情感分析与趋势可视化从“有数据”到“看得懂数据”数据落库只是系统完成了一半另一半是把数据翻译成“最近校园里的负面声音在变多还是变少”。情感分析决定舆情是否触发预警可视化决定答辩时能否三分钟讲清楚结论。4.1 情感模型SnowNLP 还是自定义词典校园语料的识别策略情感分析在毕设项目里有两种常见路线直接用现成的 SnowNLP或者引入 BERT 一类的深度学习模型。前者开箱即用但默认模型是在电商评论语料上训练的对“食堂又涨价了”“宿舍热水总是坏”这类校园口语判断经常失灵后者效果更好但配置 CUDA、加载预训练权重这一套下来很多毕设时间就耗进去了。折中方案是不换库只换模型用自己标注的校园语料重训一个 SnowNLP 情感分类器准确率能提升一截还保留了轻量部署的优势。# scripts/train_sentiment.py from snownlp import sentiment # neg.txt 和 pos.txt 每行一条人工标注的校园舆情文本 sentiment.train(data/train_neg.txt, data/train_pos.txt) sentiment.save(models/campus_sentiment.marshal)逻辑说明train的两个文件分别存放负面和正面语料行数建议各 2000 条以上。语料可以从之前采集的数据里抽样再人工标记也可以自己随手写校园场景句子补足。训练完成后save到自定义路径预测时就不再用默认的电商模型。# apps/opinions/sentiment.py from snownlp.sentiment import Sentiment classifier Sentiment() classifier.load(models/campus_sentiment.marshal) def predict_sentiment(text: str) - int: if not text: return 0 score classifier.predict(text) if score 0.6: return 1 if score 0.4: return -1 return 0逻辑说明classifier.predict返回 0 到 1 之间的正情感概率。阈值设成 0.6 和 0.4 是留出 0.4~0.6 的中间地带避免“其实还行”这类模糊文本被强行切成正或负。实际标注数据时你会发现校园舆情里中性内容占比很高强切反而让统计失真。参数说明阈值可以按实际预测结果微调。如果负面召回太少就把下阈值升到 0.5如果正面误报多就把上阈值升到 0.65。这类修改要记在项目说明里答辩时老师问“阈值为什么取 0.6”你有据可答。网络用语是另一个重灾区“排雷”“避雷”“懂的都懂”在默认词典里完全没有。解决方法是给 jieba 加校园词典再接一层关键词兜底# apps/opinions/sentiment.py 追加 import jieba jieba.load_userdict(data/campus_words.txt) STRONG_NEGATIVE_WORDS [乱收费, 吃出虫子, 半夜断电, 宿舍漏水, 挂科率] def predict_sentiment(text: str) - int: if any(word in text for word in STRONG_NEGATIVE_WORDS): return -1 base_score 0 # 先走自定义模型, 逻辑与前面相同 ...逻辑说明自定义词典文件里每一行是“词汇 词频 词性”例如乱收费 20 n。它是让 jieba 正确切分新词的基础。强负面词列表是“规则兜底”当文本里出现明确负面实义词时直接判负不依赖概率模型。毕业设计里这种规则与模型叠加的做法比单纯追求算法复杂度更好落地也更容易向答辩老师解释。4.2 预警规则负面舆情 1 小时超过阈值自动推送预警是舆情系统区别于普通信息管理系统的关键功能。它的规则不复杂难在阈值怎么取、怎么避免“狼来了”效应。# apps/alerts/checker.py from datetime import timedelta from django.utils import timezone from apps.opinions.models import OpinionPost from apps.alerts.models import OpinionAlert CHECK_WINDOW_MINUTES 60 WARN_THRESHOLD 5 def check_alerts_for_keyword(keyword_id: int): start timezone.now() - timedelta(minutesCHECK_WINDOW_MINUTES) recent_negatives OpinionPost.objects.filter( keyword_idkeyword_id, sentiment-1, publish_time__gtestart, ).count() if recent_negatives WARN_THRESHOLD: OpinionAlert.objects.create( level2, contentf关键词 {keyword_id} 近1小时内负面舆情 {recent_negatives} 条, related_countrecent_negatives, keyword_idkeyword_id, )逻辑说明预警的本质是“滑动窗口计数”。1 小时内负面数量达到 5 条就产生一条预警记录窗口信息存在related_count里。这个实现里没做幂等同一小时重复执行会重复建预警实际使用时可以在预警表加唯一约束或者用get_or_create按(keyword_id, created_at)去重毕设阶段可以先不处理。参数说明CHECK_WINDOW_MINUTES60和WARN_THRESHOLD5是两个可调参数。阈值 5 对校园场景偏敏感适合演示时快速看到预警效果真实部署建议改成 20 条/小时。想更精细可以做“负面占比预警”即 1 小时内负面数除以总舆情数超过 30% 才触发这个公式对突发“一条大热点转发几百条”的场景更准确也更好讲。4.3 可视化面板用 ECharts 显示趋势、词云和热点排行可视化是答辩的加分项也是很多人翻车的地方。ECharts 比 Matplotlib 更适合网页端展示因为可以直接在 Django 模板里渲染不用先生成图片文件。趋势图是必选项它直接展示系统“从数据到结论”的能力!-- templates/opinions/trend.html -- div idsentiment-trend styleheight:400px;/div script src/static/js/echarts.min.js/script script fetch(/api/opinions/trend?days30) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(sentiment-trend)); chart.setOption({ tooltip: { trigger: axis }, legend: { data: [负面, 正面] }, xAxis: { type: category, data: data.days }, yAxis: { type: value }, series: [ { name: 负面, type: bar, data: data.neg }, { name: 正面, type: line, data: data.pos } ] }); }); /script对应的数据接口用 Django 的JsonResponse返回注意一个关键参数# apps/opinions/views.py from django.http import JsonResponse from django.db.models import Count from django.utils import timezone from datetime import timedelta def trend_api(request): days int(request.GET.get(days, 30)) start timezone.now() - timedelta(daysdays) rows OpinionPost.objects.filter(publish_time__gtestart) \ .extra(select{day: DATE_FORMAT(publish_time, %%Y-%%m-%%d)}) \ .values(day, sentiment) \ .annotate(countCount(id)) result {days: [], neg: [], pos: []} day_map {} for row in rows: day_map.setdefault(row[day], {1: 0, -1: 0, 0: 0}) day_map[row[day]][row[sentiment]] row[count] for day, counts in sorted(day_map.items()): result[days].append(day) result[neg].append(counts.get(-1, 0)) result[pos].append(counts.get(1, 0)) return JsonResponse(result, json_dumps_params{ensure_ascii: False})逻辑说明核心在extra里的DATE_FORMAT它把publish_time按天截断让查询结果以天为粒度聚合返回给前端的数据结构直接对齐 ECharts 的xAxis.data和series.data。sorted(day_map.items())保证日期按字符串升序排列因为YYYY-MM-DD的字符串排序与时间顺序一致这里不需要额外转时间对象。参数说明json_dumps_params{ensure_ascii: False}这个参数很重要。Django 默认的JsonResponse会把中文转成\uXXXX转义前端显示正常但浏览器调试时满屏反斜杠影响排查设置成False让接口直接返回可读中文。词云可以走后端生成wordcloud图片再渲染到模板也可以前端用 echarts-wordcloud 插件实现毕设里后端生成图片更省资源接口返回图片 URL 即可。5. 避坑指南校园舆情系统跑不起来时先查这 5 个地方这部分是血泪经验汇总。以下 5 个问题把毕业设计同学卡住的比例最高按发生频率从高到低排列每一条都按“现象 → 原因 → 解决”来写。5.1 Python 3.12 装不上依赖用 py -3.10 建虚拟环境现象pip install mysqlclient或pip install jieba时终端报Microsoft Visual C 14.0 is required或者snownlp装完导入报ImportError。原因新装的 Python 3.12 里部分第三方包没有预编译的 wheel会即时尝试本地编译而 Windows 开发环境通常缺 C 构建工具。即使装上了某些老包对 3.12 的 ABI 也不兼容。解决用 Python 3.10 建虚拟环境多数包都有现成的 wheelpy -3.10 -m venv venv venv\Scripts\activate python --version pip install -r requirements.txt逻辑说明py -3.10是 Windows 上 Python Launcher 的调用方式系统里装了 3.10 的解释器就能直接用。创建独立venv而不是全局安装一是避免污染系统 Python二是requirements.txt的版本依赖只在虚拟环境里生效测试完可以直接删掉重建。装完依赖后用pip freeze看版本是否与requirements.txt一致防止 pip 自动升级了子依赖。5.2 Celery 任务不执行Windows 下必须加 --poolsolo现象celery beat启动了定时任务也在日志里出现但采集任务迟迟不跑worker 终端毫无输出。原因Windows 上 Celery 5.x 默认的prefork进程池与 Windows 的进程启动机制不兼容 worker 起不来但进程没退出导致任务一直积压在队列里不消费。解决手动启动 worker 时限制用 solo 线程池并和包版本一并确认celery -A config worker --loglevelinfo --poolsolo celery -A config beat --loglevelinfo逻辑说明--poolsolo让 Celery 在单进程内顺序执行任务避免 Windows 下多进程事件循环的兼容问题。缺点是并发能力下降但毕业设计的数据量完全够用。beat 是调度器它只管把任务按计划发到 Redis真正执行靠 worker两个终端都要开只开 beat 不 worker 是排行榜第一的错误姿势。5.3 MySQL 中文乱码建库没加 utf8mb4现象后台页面上所有中文内容显示成????或者Django RuntimeError: Incorrect string value。原因建数据库时没有指定字符集MySQL 默认latin1存不了中文。解决建库时一次性指定而不是建完再改CREATE DATABASE campus_opinion DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;如果库已经建好可以用一条命令补救ALTER DATABASE campus_opinion CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;逻辑说明建表时DEFAULT CHARSETutf8mb4也写了但表依赖的库字符集不对时表依然可能继承错误的默认值。ALTER DATABASE只改库的默认字符集已经存在的表还需要逐表ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4毕设阶段刚建完库直接改库再同步表结构即可。5.4 爬虫半小时就封频率、 Cookie 和功能开关现象采集任务开始后十几分钟请求状态码从 200 变成 403之后所有采集结果为空。原因请求间隔固定且太短站点按 IP 和 User-Agent 的组合判断为脚本行为。另一个常见原因是登录态过期没有 Cookie 的 Request 被重定向到登录页。解决控制频率是第一次修复把单次抓取间隔调到 2 秒以上并加上随机抖动。同时在settings.py里做一个开关方便演示时快速切断采集任务# config/settings.py CRAWLER_ENABLED True # apps/opinions/tasks.py 中增加 from django.conf import settings if not settings.CRAWLER_ENABLED: return {skip: crawler disabled}逻辑说明这个开关的价值在于答辩现场如果网络状态不稳定你可以直接说明“采集服务当前关闭演示用静态数据”而不是现场重试十几分钟。Cookie 的问题更隐蔽登录后的 Cookie 过期时间可能只有一天建议把 Cookie 导出到配置文件里并在失败日志里提示“请更新 Cookie”而不是默默重试。5.5 情感分析全是中性词典没更新、训练语料不够现象可视化面板里正负面几乎没有波动折线图贴近零轴除了内容全是中性的线上系统。原因SnowNLP 默认模型是电商语料校园场景的“涨价”“熄灯”“挂科率”等词汇在它的词典里是低频词另外标注语料太少模型没有学到校园讨论的语言习惯。解决分两步走先用 4.1 节的自定义词典让 jieba 正确切词再扩充训练集。如果在演示前只有一个晚上的时间优先做“规则兜底”把明确负面的词汇加进STRONG_NEGATIVE_WORDS。效果立竿见影而且逻辑可以被答辩评委理解。# data/campus_words.txt 内容示例 食堂 20 n 宿管 15 n 乱收费 30 n 停水 20 v逻辑说明词典格式是“词 频次 词性”频次是 jieba 切词时的优先级词性要按真实词性写n是名词v是动词。训练语料则是另一个坑标注 100 条和标注 1000 条的结果天壤之别建议从采集库里抽取最热门的 500 条人工标一遍加上规则词就能让输出分布明显分化。6. 用它完成答辩验证脚本、演示流程与可选的进阶方向这章说怎么把系统“变成”你真正能做主的东西。毕设答辩的评价标准不是功能有多新而是你在现场能复现和解释所以完整演示链路比花哨功能更值钱。验收前先写三个最小测试用例只测最核心的业务逻辑作为“代码能跑”的证据# apps/opinions/tests.py from django.test import TestCase from apps.opinions.sentiment import predict_sentiment from scripts.analysis.clean import clean_text class OpinionTests(TestCase): def test_url_removed(self): self.assertEqual( clean_text(食堂涨价了 https://t.cn/abc), 食堂涨价了 ) def test_negative_sentiment(self): self.assertEqual(predict_sentiment(半夜断电还不管), -1) def test_alert_record_created(self): # 构造数据并触发预警, 断言 OpinionAlert 数量1 ...逻辑说明第一个用例验证清洗函数能去掉 URL第二个用例验证强规则词能触发负面判断第三个用例验证预警记录能被创建。三个用例覆盖从文本处理到业务动作的最小闭环跑通python manage.py test就能证明系统核心逻辑成立答辩时现场跑一遍比任何 PPT 截图都有说服力。演示流程上我建议按“造数据—看趋势—看预警”三步走启动 Redis、worker、beat、runserver后在后台添加一个演示关键词手动触发一次采集任务刷新趋势接口看到曲线变化再插入几条负面文本触发阈值让预警记录出现在后台列表里。全程控制在 5 分钟左右一气呵成不要在答辩现场踩长命令。想继续加深度的话有三个方向性价比最高第一个是给预警加时序去重同一关键词在一小时内只创建一条预警这个改动小且能体现设计思考第二个是引入 TF-IDF 加 DBSCAN 的简单事件聚类把零散帖子按主题合并让“食堂涨价”和“超市打折”分开第三个是接企业微信机器人 webhook让预警直接推到手机这是最直观的展示亮点也就几行代码。我每次拿到一套爬虫类毕设源码第一件事永远是确认 Python 版本与依赖关系这在校园舆情系统里比任何算法调优都先决定生死。先跑通最小闭环再谈优化这套系统的价值就一定能讲清楚。希望帮到你。本文还有配套的精品资源点击获取