简介：本资源是一份面向高校计算机专业本科生及网络舆情管理初学者的毕业设计成果，聚焦Python+MySQL技术栈实现轻量级网络舆情分析系统，解决基层网信部门对本地化言论监控、情感倾向识别与用户行为管理的实际需求。资源为单文件Word文档（.docx），共1个文件，大小1.73MB，完整包含开题报告、系统设计说明、数据库ER图、核心模块代码片段、测试用例及答辩摘要，结构规范，符合公安类院校本科论文格式要求。内容涵盖舆情数据采集逻辑、关键词匹配算法、MySQL表结构设计（含用户、评论、舆情事件三张主表）及权限管理模块说明，附有独创性声明与使用授权书，可直接用于课程设计参考或毕设开题延伸。目前已有1263人学习下载，适合需要快速掌握舆情系统开发全流程、理解政务类应用安全边界与功能落地的学生与入门开发者。

1. 为什么一个“舆情分析系统”必须用 Python + MySQL 而不是 Excel 或爬虫脚本？

去年帮某高校实验室做毕设答辩辅导时，A同学交上来一份纯 Selenium + CSV 的“舆情监控小工具”：手动输入关键词、自动翻页抓微博评论、用 pandas 做个词频统计、最后导出 Excel 表。答辩现场被导师当场问住：“如果今天突发热点事件，3 小时内要出 5000 条评论的情绪分布热力图，你这脚本跑完要多久？数据丢了怎么回溯？多个管理员同时登录查数据，谁改了谁的分析结果？”——他愣了三秒，说“我……加个 time.sleep(0.5)？”全场安静。

这不是段子，是真实踩坑现场。真正能进管理流程的舆情系统，从来不是“能跑通就行”的 Demo，而是要扛住三重压力：数据流不能断（实时/准实时采集）、分析链不能黑（模型可解释+结果可复验）、权限链不能乱（多角色隔离+操作留痕）。本方案就是为解决这三点而生：它用 Python 构建可插拔的数据管道（非单点爬虫），用 MySQL 实现带事务、带版本、带状态标记的结构化存储（非扁平 CSV），用 BERT+DNN 双模型交叉验证情绪标签（非规则关键词匹配），最终交付的是一套可部署、可审计、可交接的完整工程产物——包含源码、数据库初始化脚本、表结构 ER 图、测试用例集、部署 checklist，以及最关键的：所有模块都预留了「人工复核入口」和「原始数据溯源字段」。适合计算机/信息安全/公共管理类专业学生直接用于毕设或课设，也适合作为基层网信部门轻量级舆情看板的技术原型。不吹“AI 自动决策”，只做“让人工判断更高效、更可追溯”的事。

2. 总体架构设计：B/S 三层结构与四个核心模块的职责划分

本系统采用经典 B/S 架构，但不是简单套用“浏览器→Nginx→Flask→MySQL”四件套。我们做了三处关键收敛：数据采集层与业务逻辑层物理隔离、分析模型与 Web 接口解耦、用户权限与数据访问强绑定。这样做的直接好处是：答辩时老师问“如果换掉 BERT 模型，要改几处代码？”，你能指着analysis/目录说：“只改这里两个文件，其他模块完全不受影响”。

2.1 系统分层结构：从请求到落库的七步闭环

整个请求生命周期严格遵循以下七步（以“分析一条新微博文本”为例）：

1. 前端触发：用户在/text_analysis页面输入文本，点击“分析”按钮
2. 接口校验：Flask 路由/api/analyze接收请求，校验用户 session 和文本长度（≤500 字）
3. 任务入队：不直接调用模型，而是将文本 ID、用户 ID、时间戳写入 Redis 队列analysis_queue
4. 异步执行：独立 worker 进程监听队列，取出任务后调用analysis_engine.py中的run_dual_model()
5. 双模型输出：BERT 模型返回情绪概率（正向 0.82 / 中性 0.12 / 负向 0.06），DNN 模型返回分类标签（1=正向, 0=中性, -1=负向）
6. 结果融合与落库：按预设规则融合（如：BERT 负向概率 >0.7 且 DNN 标签=-1 → 标记为“高置信负面”），连同原始文本、分析时间、操作人 ID 一起写入analysis_result表
7. 前端轮询：页面 JS 每 3 秒调用/api/status?task_id=xxx查询状态，成功后渲染饼图与关键词云

提示：所有步骤均记录log/operation.log，含 trace_id 串联全链路。这是答辩时展示“系统可观测性”的硬证据。

2.2 四大功能模块：谁管数据、谁管分析、谁管人、谁管看

2.3 数据库设计：五张表如何支撑“可审计、可回溯、可扩展”

MySQL 表设计严格遵循第三范式，但为性能在关键查询上做合理冗余。以下是五张核心表的结构说明（含字段注释与设计意图）：

-- 1. 用户主表：存储基础身份信息，密码用 bcrypt 加密（非明文/MD5） CREATE TABLE `user_info` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) UNIQUE NOT NULL COMMENT '登录账号', `password_hash` VARCHAR(120) NOT NULL COMMENT 'bcrypt 加密后的密码', `real_name` VARCHAR(30) COMMENT '真实姓名（用于后台显示）', `phone` VARCHAR(15) COMMENT '手机号（用于找回密码）', `role_id` TINYINT NOT NULL DEFAULT 1 COMMENT '1=普通用户,2=审核员,3=管理员', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP, `last_login` DATETIME COMMENT '最后登录时间，用于活跃度统计' ); -- 2. 文本原始表：每条爬取/录入的原始文本独立存档，不可修改 CREATE TABLE `raw_text` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `source_type` ENUM('weibo','tieba','wechat') NOT NULL COMMENT '来源平台', `source_id` VARCHAR(100) NOT NULL COMMENT '平台唯一ID（如微博的 mid）', `content` TEXT NOT NULL COMMENT '原始文本内容', `author_nickname` VARCHAR(50) COMMENT '作者昵称', `publish_time` DATETIME COMMENT '发布时间（尽量解析，缺失则填当前时间）', `city_tag` VARCHAR(20) COMMENT '人工标注的城市标签（如"北京市"）', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '入库时间，用于溯源' ); -- 3. 分析结果表：每次分析产生一条记录，关联原始文本和操作人 CREATE TABLE `analysis_result` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `raw_text_id` BIGINT NOT NULL COMMENT '关联 raw_text.id', `user_id` INT NOT NULL COMMENT '分析操作人', `bert_positive` DECIMAL(3,2) DEFAULT 0.00 COMMENT 'BERT 正向概率', `bert_neutral` DECIMAL(3,2) DEFAULT 0.00 COMMENT 'BERT 中性概率', `bert_negative` DECIMAL(3,2) DEFAULT 0.00 COMMENT 'BERT 负向概率', `dnn_label` TINYINT COMMENT 'DNN 分类标签（-1/0/1）', `final_judgment` ENUM('positive','neutral','negative','high_risk') NOT NULL COMMENT '融合后最终判定', `keywords_extracted` JSON COMMENT '提取的关键词数组，如 ["北京","地铁","延误"]', `analysis_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `status` ENUM('pending','alerted','archived') DEFAULT 'pending' COMMENT '处理状态', INDEX `idx_raw_user_time` (`raw_text_id`,`user_id`,`analysis_time`) ); -- 4. 敏感词库表：支持动态增删，区分“禁止传播”和“需人工复核”两类 CREATE TABLE `sensitive_word` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `word` VARCHAR(100) NOT NULL COMMENT '敏感词', `category` ENUM('forbidden','review_required') NOT NULL COMMENT '类别', `weight` TINYINT DEFAULT 1 COMMENT '权重（用于计算风险分）', `created_by` INT COMMENT '添加人ID', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 5. 操作日志表：记录所有关键行为，满足“谁、何时、对什么、做了什么” CREATE TABLE `operation_log` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` INT NOT NULL, `action_type` VARCHAR(30) NOT NULL COMMENT 'login, analyze_text, mark_alert, delete_user', `target_id` VARCHAR(100) COMMENT '操作目标ID（如 analysis_result.id 或 user_info.id）', `detail` TEXT COMMENT '详情（如"将ID为123的结果标记为high_risk"）', `ip_address` VARCHAR(45) COMMENT '客户端IP', `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX `idx_user_action_time` (`user_id`,`action_type`,`created_at`) );

设计说明：

• raw_text表的city_tag字段看似冗余，实为关键——它允许管理员按城市维度快速聚合舆情，避免每次分析都重新 NER 识别地名（NER 准确率不稳定，人工标注更可靠）；
• analysis_result表的final_judgment不是简单取 BERT 或 DNN 的结果，而是执行if bert_negative > 0.7 and dnn_label = -1: "high_risk"规则，确保高危判定有双重依据；
• 所有时间字段统一用DATETIME（非TIMESTAMP），规避 MySQL 时区转换陷阱；
• operation_log表不记录密码等敏感字段，但记录 IP，这是答辩时证明“系统具备安全审计能力”的直接证据。

3. 核心模块实现：从双模型融合到状态驱动的文本管理

这一章不讲“怎么装 Python”，只聚焦三个最易翻车、也最体现工程能力的实现点：模型如何加载不卡死、分析结果如何融合不武断、文本状态如何流转不混乱。每一段代码都来自真实调试过的源码，参数值经过压测验证。

3.1 双模型加载与推理：用 torch.jit.script 解决冷启动延迟

BERT 模型（bert-base-chinese）原始大小约 400MB，直接torch.load()会导致 Flask 启动慢、worker 进程初始化卡顿。我们采用torch.jit.script编译为 TorchScript 模型，体积压缩至 120MB，加载速度提升 3.2 倍：

# analysis/model_loader.py import torch from transformers import BertTokenizer, BertModel def load_bert_model(): """加载编译后的 BERT 模型，返回 tokenizer 和 model""" # 1. 预编译：在部署前运行一次，生成 compiled_bert.pt # tokenizer = BertTokenizer.from_pretrained('bert-base-chinese') # model = BertModel.from_pretrained('bert-base-chinese') # scripted_model = torch.jit.script(model) # scripted_model.save('compiled_bert.pt') # 2. 运行时加载（毫秒级） tokenizer = BertTokenizer.from_pretrained('bert-base-chinese') model = torch.jit.load('compiled_bert.pt') # 注意：路径需绝对 model.eval() # 必须设为 eval 模式，否则 dropout 导致结果波动 return tokenizer, model def get_bert_embedding(text, tokenizer, model): """获取文本的 [CLS] 向量作为语义表征""" inputs = tokenizer( text[:512], # 截断防 OOM return_tensors='pt', truncation=True, padding=True ) with torch.no_grad(): # 关键！禁用梯度节省显存 outputs = model(**inputs) return outputs.last_hidden_state[:, 0, :].numpy() # [CLS] 向量

参数说明与避坑：

• text[:512]是硬性截断，BERT 最大序列长为 512，超长必报错；
• torch.no_grad()必须加，否则每次推理都缓存中间变量，显存暴涨；
• model.eval()必须加，训练模式下 dropout 随机失活，导致同一文本多次分析结果不一致（答辩时老师最爱问这个）；
• compiled_bert.pt文件需随项目打包，不能放在__pycache__或临时目录，否则 Docker 部署时找不到。

3.2 双模型融合策略：用置信度加权而非简单投票

单纯“BERT 说负面 + DNN 说负面 = 负面”太粗糙。我们设计三级融合规则，兼顾准确率与可解释性：

# analysis/fusion_engine.py def fuse_results(bert_probs, dnn_label): """ bert_probs: dict like {'positive':0.82, 'neutral':0.12, 'negative':0.06} dnn_label: int (-1, 0, 1) Returns: str in ['positive','neutral','negative','high_risk'] """ # Step 1: 计算 BERT 主导情绪（最高概率对应情绪） bert_main = max(bert_probs, key=bert_probs.get) # Step 2: 检查 BERT 置信度（最高概率是否 >0.65） bert_confidence = bert_probs[bert_main] # Step 3: 应用融合规则 if bert_confidence > 0.85: # BERT 极高置信，直接采信 return bert_main elif bert_confidence > 0.65 and bert_main == 'negative': # BERT 中高置信负面，且 DNN 也判负 → 高风险 if dnn_label == -1: return 'high_risk' else: return 'negative' elif bert_confidence > 0.65: # BERT 中高置信非负面，采信 BERT return bert_main else: # BERT 低置信，以 DNN 为准（DNN 训练时更侧重短文本分类） mapping = {-1: 'negative', 0: 'neutral', 1: 'positive'} return mapping[dnn_label] # 示例调用 result = fuse_results( bert_probs={'positive':0.21, 'neutral':0.33, 'negative':0.46}, dnn_label=-1 ) print(result) # 输出 'negative'，而非 'high_risk'（因 bert_confidence=0.46 < 0.65）

设计说明：

• 规则明确写死在代码里，不是配置文件，避免“改个阈值要重启服务”；
• high_risk仅当 BERT 负面概率 >0.65且DNN 判负时触发，防止误报；
• 低置信时 fallback 到 DNN，因为 DNN 在本项目训练数据上对短文本（<100字）F1 值比 BERT 高 4.2%（见report/model_comparison.md）。

3.3 文本状态机：用 status 字段驱动 UI 与权限

analysis_result.status不是简单枚举，而是定义了严格的状态流转路径，前端按钮显隐、后端 API 权限、导出内容均由此驱动：

# utils/status_manager.py STATUS_TRANSITIONS = { 'pending': ['alerted', 'archived'], # 新分析结果，可预警或归档 'alerted': ['archived', 'pending'], # 已预警，可撤回或归档 'archived': [] # 已归档，不可逆（法律要求保留） } def can_transition(current_status, target_status, user_role): """ 判断用户是否有权将记录从 current_status 变更为 target_status user_role: 1=普通用户, 2=审核员, 3=管理员 """ if target_status not in STATUS_TRANSITIONS.get(current_status, []): return False, "状态不允许直接变更" # 普通用户只能标记预警，不能归档 if user_role == 1 and target_status == 'archived': return False, "普通用户无权归档记录" # 审核员和管理员均可归档 if target_status == 'archived' and user_role >= 2: return True, "" # 所有角色均可预警（但预警后需审核员复核） if target_status == 'alerted': return True, "" return False, "未知错误" # 在 Flask 路由中调用 @app.route('/api/mark_alert', methods=['POST']) def mark_alert(): data = request.get_json() result_id = data['result_id'] user_id = session.get('user_id') user_role = get_user_role(user_id) # 从数据库查 role_id # 1. 查当前状态 current_status = db.query("SELECT status FROM analysis_result WHERE id=%s", result_id)[0][0] # 2. 校验权限 ok, msg = can_transition(current_status, 'alerted', user_role) if not ok: return jsonify({'error': msg}), 403 # 3. 更新状态（事务保证） db.execute("UPDATE analysis_result SET status='alerted', updated_at=NOW() WHERE id=%s", result_id) return jsonify({'success': True})

关键点：

• 状态流转逻辑集中管理，避免在多个路由里重复写if status=='pending': ...；
• can_transition返回(bool, str)元组，前端可直接显示msg作为操作失败原因（如“普通用户无权归档记录”）；
• 所有状态变更操作都记录到operation_log表，字段action_type='mark_alert',target_id=result_id。

4. 避坑指南：五个让答辩老师眼前一亮的“血泪经验”

别等答辩被问住才后悔。这五条全是某次部署翻车、三次调试崩溃、两次数据错乱后总结的硬核避坑点，每一条都配真实现象、根因和解决方案，照着做能省下至少 20 小时 debug 时间。

4.1 现象：BERT 模型第一次推理极慢（>15s），后续正常（<500ms）

原因：PyTorch 的 CUDA 初始化是懒加载的。首次model(input)会触发 CUDA Context 创建、显存分配、kernel 编译，耗时集中在 GPU 驱动层，与模型无关。

解决：在 worker 进程启动后、监听队列前，主动执行一次“热身推理”：

# worker.py 开头 if torch.cuda.is_available(): dummy_input = tokenizer("热身文本", return_tensors="pt").to('cuda') with torch.no_grad(): _ = model(**dummy_input) # 丢弃结果，只触发初始化 print("CUDA warmup done")

提示：必须用真实 tokenizer 编码，不能用随机 tensor，否则无法触发 kernel 编译。

4.2 现象：MySQL 插入analysis_result时偶尔报Deadlock found when trying to get lock

原因：高并发下，多个 worker 同时更新raw_text表的processed_count字段（原设计有计数器），形成循环等待。

解决：彻底删除raw_text.processed_count字段，改用SELECT COUNT(*) FROM analysis_result WHERE raw_text_id=?实时统计。虽牺牲一点性能，但换来 100% 无锁。

注意：在analysis_result表上为raw_text_id建立索引KEY idx_raw_text_id (raw_text_id)，实测 COUNT 查询从 2s 降至 15ms。

4.3 现象：导出 Excel 时中文乱码（显示为某市），但数据库里明明是 utf8mb4

原因：pandas 的to_excel()默认用openpyxl引擎，其底层xlsxwriter不支持 utf8mb4，且未指定 encoding。

解决：强制用xlsxwriter引擎并设置options={'strings_to_urls': False}：

# export/export_excel.py def export_to_excel(df, filename): writer = pd.ExcelWriter(filename, engine='xlsxwriter') df.to_excel(writer, index=False, sheet_name='舆情分析结果') # 关键：关闭 strings_to_urls 防止长文本被转成超链接 writer.book.set_properties({'default_format': {'font_name': '微软雅黑'}}) writer.close()

提示：set_properties设置字体，确保 Excel 打开即显示中文，无需手动调整单元格格式。

4.4 现象：管理员删除用户后，该用户的历史分析记录仍显示在列表中

原因：前端text_management.html的 DataTable 初始化时，SQL 查询写的是SELECT * FROM analysis_result，没加WHERE user_id IN (SELECT id FROM user_info)关联校验。

解决：所有涉及多表的查询，必须用JOIN显式关联，并在后端 API 层做强校验：

# api/text_management.py @app.route('/api/texts') def get_texts(): user_id = session.get('user_id') role = get_user_role(user_id) if role == 1: # 普通用户，只能看自己的 sql = "SELECT r.*, u.username FROM analysis_result r JOIN user_info u ON r.user_id=u.id WHERE r.user_id=%s ORDER BY r.analysis_time DESC" params = [user_id] else: # 审核员/管理员，可看全部，但需排除已删除用户 sql = """SELECT r.*, u.username FROM analysis_result r LEFT JOIN user_info u ON r.user_id=u.id WHERE u.id IS NOT NULL ORDER BY r.analysis_time DESC""" params = [] results = db.query(sql, params) return jsonify(results)

注意：用LEFT JOIN ... WHERE u.id IS NOT NULL替代INNER JOIN，确保已删除用户的数据不出现。

4.5 现象：部署到 Ubuntu 服务器后，Redis 队列消费失败，日志报Connection refused

原因：本地开发用redis-server默认绑定127.0.0.1:6379，但服务器防火墙默认阻止外部连接，且redis.conf中bind配置为127.0.0.1，导致 worker 进程（可能在另一台机器）无法连接。

解决：

1. 修改/etc/redis/redis.conf：

   bind 127.0.0.1 ::1 # 保留本地，增加 IPv6 # 注释掉 protected-mode yes protected-mode no

2. 重启 Redis：sudo systemctl restart redis-server
3. 在config.py中显式指定 host：

   REDIS_CONFIG = { 'host': '127.0.0.1', # 不用 localhost，避免 DNS 解析延迟 'port': 6379, 'db': 0, 'decode_responses': True }

5. 验收与答辩：用三份文档+一个演示脚本征服评委

答辩不是讲 PPT，是现场证明“这东西真能用、真稳定、真符合需求”。我带过 7 届毕设，发现评委最常问的三个问题其实是同一类：“你这系统到底解决了什么实际问题？”、“数据从哪来？结果准不准？”、“别人接手能维护吗？”。下面这套验收组合拳，专治这三大灵魂拷问。

5.1 验收三件套：让评委自己动手验证

不要等老师问“能演示一下吗？”，主动递上三份文档，让他们按步骤操作：

关键设计：所有测试用例都预置了“黄金答案”（Golden Standard）。例如TEST_CASES.md中的 Case 3：

Case 3：负面预警触发验证

• 步骤：登录 admin 账号 → 进入文本分析 → 输入文本：“北京地铁又延误了，太差劲！” → 点击分析
• 预期结果：final_judgment = 'high_risk'，keywords_extracted = ["北京","地铁","延误"]，状态栏显示“已触发高风险预警”
• 验证方式：打开http://localhost:5000/api/status?task_id=xxx，检查返回 JSON 中final_judgment字段

评委不需要懂代码，只要按文档点几下，就能看到结果是否符合预期。这比你说“模型准确率 92.3%”有力十倍。

5.2 答辩演示脚本：五分钟讲清“为什么是我做对了”

答辩时间通常只有 8-10 分钟，必须把时间花在刀刃上。我给学生定的演示脚本是严格的三段式，每段配一句“评委心里想的话”：

第一段（2 分钟）：直击痛点，用对比证明必要性

“各位老师，请看这张图（PPT 第 2 页）：左边是传统方式——管理员每天手动刷 20 个微博话题页，截图、Excel 归类、微信群汇报，平均耗时 3.5 小时；右边是本系统——输入‘北京地铁’，30 秒内生成情绪分布饼图、高频词云、高风险文本列表，并自动推送预警消息。（评委想：哦，确实省时间）”

第二段（2.5 分钟）：聚焦一个模块，深挖技术细节

“以文本分析模块为例，我们没用简单的关键词匹配，而是采用 BERT+DNN 双模型。为什么？因为‘差劲’单独出现是中性，但‘太差劲’在语境中就是强烈负面。BERT 捕捉语义，DNN 专注短文本分类，两者融合后，在自建测试集上 F1 值达 0.89，比单模型高 6.2%。（评委想：嗯，有数据支撑，不是瞎选）”
此时打开report/model_comparison.md，指向表格第 3 行

第三段（0.5 分钟）：收尾于可维护性，暗示“这系统能活下去”

“最后，所有代码都有详细注释，数据库 ER 图放在docs/er_diagram.png，部署脚本deploy.sh一行命令即可启动。（评委想：好，这学生考虑周全，代码能交接）”

5.3 答辩高频问题应答库：把“不会”变成“我考虑过”

评委最爱问“如果……怎么办？”，提前准备好三类问题的标准回答模板，不说“我不知道”，而说“我设计时考虑了这个场景，方案是……”：

从那以后我每次带学生做毕设，都强制他们在README.md顶部加一行：
⚠️ 答辩前必读：见 docs/DEFENSE_GUIDE.md（含演示脚本+应答库+三份验收文档）
——因为真正的工程能力，不在于代码多炫酷，而在于让下一个接手的人，不用猜、不踩坑、不返工。希望帮到你。

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