基于Django+BERT的网络舆情分析系统设计：从数据库到模型调用

简介：这是一份基于Python语言与MySQL数据库开发的网络舆情分析系统毕业设计论文资源，面向计算机专业学生、毕业设计者以及网络舆情管理相关岗位人员，可作为系统开发与论文撰写的完整参考。论文从计算机技术发展对信息传播和言论发布的影响切入，指出人工逐条查看特定微博的查找方式存在效率低、刷新慢等痛点，进而提出以城市或地区为关键词进行舆情监控的设计目标。资源包共1个docx文件，大小1.73MB，内容涵盖论文封面、独创性声明、中英文摘要、需求分析、系统总体架构、数据库设计以及系统实现过程，并附有核心源码、数据库表结构及功能模块说明，便于对照学习。已有1262人学习/下载。读者可从中掌握言论分析、言论管理、用户管理等功能模块的实现思路，了解Python与MySQL在工程中的整合方法，同时获得毕业设计论文的排版结构和写作参考。

1. 网络舆情分析系统：从海量言论里捞出需要预警的那几条

管理网络舆情的工作者每天面对的是各平台上的海量言论，如果还靠人工一条条翻看特定账号的微博，效率低且时效性差。这套基于 Python 和 MySQL 的网络舆情分析系统正是为此设计的：用户在文本分析框输入一段评论，系统会调用深度神经网络（DNN）和 BERT 模型做情感判断，返回负面预警结论；管理员则可以在后台管理用户、查看言论数据、用柱状图和饼图对比两种算法的分析结果。整套系统是经典的 B/S 架构 Web 项目，后端用 Django，数据存 MySQL，前端是 HTML5 配合 CSS 与 JavaScript。这份毕业设计资源把源码、数据库脚本、论文全文捆绑在一起，适合正在选毕设题目的学生、想完整跑通一个含文本分析功能 Web 项目的开发者，以及想了解舆情系统数据链路怎么设计的产品方向读者。

2. 系统架构与模块划分：B/S 三层结构下的七块业务

2.1 这系统到底能干什么：七个功能模块的角色拆解

从论文的需求分析章节看，这套系统并不是一个只有登录和增删改查的“教学 Demo”，而是围绕“采集言论 → 分析情感 → 管理结果 → 管理用户”这条完整链路设计的。七个核心功能模块各有明确分工。

登录注册是所有操作的闸门，未注册用户只能看到系统公告和站内新闻，这是论文里明确提到的访问控制。文本分析负责产出“判断结果”，文本管理负责把这些结果存下来并跟踪处理状态，用户管理则把普通用户和管理员的权限边界划清楚。值得注意的是，对比分析模块是这个系统区别于普通论坛项目的地方——它同时使用 DNN 和 BERT 两种算法分析同一段文本，让管理人员能对比不同模型的判断差异，避免单一模型的误判被直接采信。

2.2 技术选型解读：为什么是 Python、MySQL 和双算法

技术栈的判断可以从论文的目录结构和功能描述推断出来。后端语言是 Python，开发环境用的是 Sublime Text，论文里提到这个编辑器“在市面上进行 Python 和 Django 编程时非常流行”，所以这套系统的后端框架基本可以锁定为 Django。为什么选 Python 而不是 JSP 或 PHP？论文给的理由是三条：结构清晰且面向对象、浏览器下响应速度快、连接数据库的方式稳定。从实际开发角度看，Django 自带的 ORM、Admin 后台和表单校验也确实能极大缩短这类管理系统的开发周期。

数据库选 MySQL 同样有明确考量：小巧开源、查询和执行速度快、存储与查询机制稳定。在国内高校和中小型项目中，MySQL 几乎是 Django 项目的默认搭配，配合 Navicat 做可视化导入导出，开发体验非常顺。前端则用 HTML5 加 CSS 和 JavaScript，负责表单提交、页面布局和动态效果，属于这套系统里最“标准”的部分。

算法层是这套系统的技术亮点。论文明确写了系统用到 DNN（深度神经网络）和 BERT 两种模型，BERT 是谷歌研究院 2018 年提出的预训练模型，在文本分类任务上的表现大幅领先传统方法。系统同时挂两个模型，目的就是“把舆情分析做到最准”，对比分析模块就是这两种模型结果的可视化出口。实际跑这种毕业设计项目，我一般会在 Django 的视图层封装一个模型调用服务，底层接训练好的模型文件，上层只暴露“输入文本返回情感结果”的接口。

2.3 源码目录结构：拿到资源包先看哪几个文件

整理一套带源码的 Django 项目，目录通常长这样。这套系统虽然我没法断言每个文件的名字都一致，但按 Django 的标准工程习惯和论文功能描述，大概率逃不出这个骨架。

network_opinion/ ├── manage.py # Django 项目管理入口 ├── requirements.txt # 依赖清单（Django、mysqlclient、transformers 等） ├── db.sqlite3 或 opinion.sql # 实际数据或建表脚本 ├── opinion_system/ │ ├── settings.py # 项目配置：数据库、APP 注册、静态文件 │ ├── urls.py # 路由映射：URL 到视图函数 │ ├── models.py # 数据模型：用户、文本、分类、新闻 │ ├── views.py # 核心业务逻辑：登录、分析、管理 │ └── admin.py # Django Admin 后台注册 ├── templates/ │ ├── login.html # 登录页 │ ├── register.html # 注册页 │ ├── index.html # 首页 │ ├── text_analysis.html # 文本分析页 │ └── user_manage.html # 用户管理页 ├── static/ │ ├── css/ # 样式文件 │ └── js/ # 前端脚本 └── algorithm/ ├── dnn_model.py # DNN 模型封装 └── bert_model.py # BERT 模型封装

拿到资源包的第一时间，我会先打开 requirements.txt 和数据库脚本，而不是急着看 views.py。原因很简单：依赖版本和数据库结构决定项目能不能跑起来，代码逻辑反而是其次。settings.py 里的 DATABASES 配置需要和本地 MySQL 账号密码对上，templates 目录决定页面能不能渲染出来，这两处是绝大多数运行失败的高发区。

提示：如果资源包里没有 requirements.txt，可以看论文的开发环境章节，按“Django + mysqlclient + transformers”的组合自己补齐，版本不必追新，能跑通优先。

3. 数据库设计：四张业务表如何撑起言论分析与用户权限

3.1 实体关系梳理：用户、文本、分类、新闻之间的关联

论文第 4.2 节花了不小篇幅强调数据库设计要前置，否则“数据库结构改变后所有代码都要改”。它规划了四类表：用户信息表、文本分类表、文本信息表、文本管理信息表，再加上首页展示需要的站内新闻表，整个系统一共五张业务表。

实体之间的关系不复杂，但层次清楚。用户与文本是一对多的关系：一个用户可以提交多条分析文本。文本分类与文本信息是一对多的关系：分类表管理言论的种类，文本信息表记录每条言论的详细内容。文本与文本管理信息是一对一的关系：每条文本对应一条管理记录，用于追踪“未处理/已处理”的状态。站内新闻表是独立数据，只服务首页展示，不参与分析链路。

这套设计的一个巧思在于把“分析结果”和“管理状态”分开存储。文本表只记录模型给出的情感判断结果，管理表单独存处理人和处理状态。这样舆情负责人把一条负面言论标记为“已处理”时，不需要改写原始分析记录，数据的历史痕迹被完整保留下来。

3.2 核心建表 SQL：按论文字段补全的落库方案

论文只描述了表的功能定位，没有给出完整的建表语句。这里按常规做法补一版能在 MySQL 5.7 以上版本直接执行的建表 SQL，字段完全对齐论文提到的内容。

-- 用户信息表 CREATE TABLE user_info ( user_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID，主键', username VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名', password VARCHAR(128) NOT NULL COMMENT '密码（建议存哈希值）', phone VARCHAR(20) COMMENT '手机号', role TINYINT DEFAULT 1 COMMENT '角色：1普通用户 2管理员', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表'; -- 文本分类表 CREATE TABLE text_category ( category_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '分类ID', category_name VARCHAR(50) NOT NULL COMMENT '分类名称，如负面/正面/中性' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文本分类表'; -- 文本信息表 CREATE TABLE text_info ( text_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '文本ID', user_id INT NOT NULL COMMENT '提交用户ID', category_id INT COMMENT '分类ID，关联分类表', content TEXT NOT NULL COMMENT '言论内容', sentiment_result VARCHAR(20) COMMENT '情感判断结果', dnn_score FLOAT COMMENT 'DNN模型输出分数', bert_score FLOAT COMMENT 'BERT模型输出分数', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '提交时间', FOREIGN KEY (user_id) REFERENCES user_info(user_id), FOREIGN KEY (category_id) REFERENCES text_category(category_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文本信息表'; -- 文本管理信息表 CREATE TABLE text_manage ( manage_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '管理记录ID', text_id INT NOT NULL COMMENT '关联文本ID', status TINYINT DEFAULT 0 COMMENT '处理状态：0未处理 1已处理', handler VARCHAR(50) COMMENT '处理人', handle_time DATETIME COMMENT '处理时间', remark VARCHAR(255) COMMENT '备注', FOREIGN KEY (text_id) REFERENCES text_info(text_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文本管理信息表'; -- 站内新闻表 CREATE TABLE news_info ( news_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '新闻ID', title VARCHAR(100) NOT NULL COMMENT '新闻标题', content TEXT COMMENT '新闻内容', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '发布时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='站内新闻表';

注意几个设计细节：user_info 表的 username 加了 UNIQUE 约束，防止注册时用户名重复；role 字段用 TINYINT 而不是字符串，方便后续扩展更多角色层级；text_info 表同时存了 dnn_score 和 bert_score 两个浮点字段，这是为了让对比分析模块能直接读取两种模型的原始输出，而不需要重新调用模型计算。所有表都用 utf8mb4 字符集，否则中文言论存进去可能出现乱码。

提示：如果你拿到的源码里没有现成的 SQL 脚本，按上面这套建表是能对上论文功能描述的。迁移到 Django ORM 时，可以在 models.py 里用等价字段定义，再由 makemigrations 自动生成表结构，效果一致。

3.3 为什么文本分类表和文本信息表要拆成两张

很多初学者会把分类做成文本表里的一个字符串字段，省一张表。但这套系统把分类单独拆出来，论文里也给了解释：用分类表管理言论种类，用文本信息表详细管理文本信息。这个拆法有三个实际好处。

第一，分类名称可以单独维护。比如论文提到的“未处理/已处理”是一种状态分类，但文本情感本身还有“正面/负面/中性”之分，如果要新增“疑似谣言”分类，只需要往分类表插一行，不用改动已经存好的几千条文本记录。第二，数据冗余减少。如果分类名直接写死在文本表里，每条记录都重复存一遍字符串，既占空间又容易写错。第三，为后续统计查询铺路。对比分析模块用饼图展示分类占比时，直接按 category_id 分组聚合即可，SQL 写起来非常干净。

我在实际拆这类项目时，最怕看到的是“开发到一半发现需要加权限字段，于是回头改表结构，连带所有 SQL 和页面一起返工”。这套系统的表设计虽然简单，但表和表之间的边界划得清楚，数据分析、结果管理、用户权限三条线互不干扰，这正是论文里强调“数据库设计必须在编程之前完成”的原因。

4. 核心功能实现：登录鉴权到文本分析的完整链路

4.1 登录注册与会话控制：从表单到 session 的一整趟流程

论文明确规定了访问规则：未注册用户只能浏览首页公告和新闻，只有登录后才有权限使用文本分析和文本管理。Django 里最常规的做法是写一个登录视图，配合 request.session 控制状态。

# views.py - 登录视图 from django.shortcuts import render, redirect from django.contrib.auth.hashers import check_password from .models import UserInfo def login_view(request): if request.method == 'POST': username = request.POST.get('username', '') password = request.POST.get('password', '') if not username or not password: error = '用户名和密码不能为空' return render(request, 'login.html', {'error': error}) try: user = UserInfo.objects.get(username=username) except UserInfo.DoesNotExist: error = '用户不存在' return render(request, 'login.html', {'error': error}) if check_password(password, user.password): request.session['user_id'] = user.user_id request.session['role'] = user.role return redirect('/index/') else: error = '密码错误' return render(request, 'login.html', {'error': error}) return render(request, 'login.html')

这段代码的逻辑很直白：POST 请求里取出 username 和 password 两个字段，先做非空校验，再按用户名查数据库，最后用 Django 自带的 check_password 函数比对密码哈希。比对成功后把用户 ID 和角色写进 session，后续每个受保护页面检查 session 是否存在即可。这里用 check_password 而不是直接比对明文密码，是 Django 的安全默认值——用户表里存的是哈希串，即使数据库泄露也不会直接暴露明文密码。

参数说明：request.POST.get() 是 Django 取表单字段的标准姿势，第二个参数 '' 是默认值，避免前端漏传字段导致 KeyError。redirect('/index/') 是 302 跳转，用户登录成功后直接落到首页总览。session 机制默认由 Django 的 SessionMiddleware 支撑，数据存在服务端，客户端只拿 sessionid 的 Cookie，不需要手动处理 Cookie。

4.2 文本分析模块：输入一句话，返回负面概率

文本分析是这个系统最核心的模块。用户在前端文本框里输入内容，点击分析后系统要完成：调用算法模型 → 得到情感判断 → 存入文本表 → 返回结果给页面展示。为了避免视图函数里堆一大段模型代码，我通常会把模型调用做成独立的 service 层。

# services/analysis_service.py import joblib from transformers import BertTokenizer, BertForSequenceClassification import torch class TextAnalysisService: def __init__(self): # 生产环境建议从配置文件读取路径，这里写死便于演示 self.dnn_model = joblib.load('algorithm/dnn_model.pkl') self.tokenizer = BertTokenizer.from_pretrained('bert-base-chinese') self.bert_model = BertForSequenceClassification.from_pretrained( 'algorithm/bert_model', num_labels=3) def analyze(self, content): """统一接口：入参文本，出参情感分类和两个模型的分数""" # DNN 预测 dnn_result = self.dnn_model.predict([content])[0] dnn_score = float(self.dnn_model.predict_proba([content])[0].max()) # BERT 预测 inputs = self.tokenizer(content, return_tensors='pt', max_length=128) outputs = self.bert_model(**inputs) probs = torch.softmax(outputs.logits, dim=1) bert_label = int(torch.argmax(probs, dim=1)[0]) bert_score = float(probs.max().item()) from .models import TextCategory category_map = {0: '负面', 1: '正面', 2: '中性'} sentiment = category_map.get(bert_label, '未知') return { 'sentiment': sentiment, 'dnn_score': dnn_score, 'bert_score': bert_score }

分析服务对外只暴露一个 analyze 方法，入参是一段文本，出参是包含情感结论和两个模型分数的字典。DNN 模型用 joblib 加载本地 pkl 文件，BERT 模型则走 transformers 的 BertForSequenceClassification，num_labels=3 表示三分类任务。对舆情预警来说，只有“负面”类别才需要触发后续预警动作，判断逻辑放在视图层处理。

参数说明：max_length=128 控制 BERT 输入的最大 token 长度，超过部分截断，避免长文本拖慢推理速度；return_tensors='pt' 指定返回 PyTorch 张量格式；probs.max().item() 取出最大概率值并转成 Python 浮点数，方便存进 MySQL 的 FLOAT 字段。这套接口设计的好处是视图层完全不知道底层用的是哪个模型，后续把 DNN 换成其他算法，只需要改 service 内部实现。

4.3 文本管理与用户管理：后台数据维护的落地姿势

文本管理模块解决的是“分析完之后这些数据去哪了”的问题。论文说这个功能可以查看所有文本数据并管理，还专门提到管理状态列“未处理、已处理”。对应的 Django 视图大概是这样的：

# views.py - 文本管理视图 from django.shortcuts import render, redirect from .models import TextInfo, TextManage from .services.analysis_service import TextAnalysisService def text_manage_view(request): if not request.session.get('user_id'): return redirect('/login/') if request.method == 'POST': content = request.POST.get('content', '') if content: service = TextAnalysisService() result = service.analyze(content) text = TextInfo.objects.create( user_id=request.session['user_id'], content=content, sentiment_result=result['sentiment'], dnn_score=result['dnn_score'], bert_score=result['bert_score'] ) TextManage.objects.create(text_id=text.text_id, status=0) return redirect('/text_manage/') texts = TextInfo.objects.all().order_by('-create_time') return render(request, 'text_manage.html', {'texts': texts})

分析结果入库的动作在 POST 分支里完成：调 analyze 拿到结果 → 向 text_info 表插入一条新记录 → 同步向 text_manage 表插一条 status=0 的管理记录。text_manage 和 text_info 同时插入，保证“每条文本都有对应管理记录”的数据完整性。管理页的列表按 create_time 倒序排列，新提交的舆情永远排在最前面，方便管理员优先处理。

用户管理模块的逻辑更简单，管理员进入页面后能创建新用户、按姓名搜索、修改用户信息、删除违规账号。权限控制只需要在视图开头判断 request.session.get('role') 是否等于管理员角色值，非管理员直接跳回首页即可。这样用户权限、文本管理权限、分析权限三条链路的边界就全部收口了。

5. 跑通项目时的常见坑与排查：从依赖安装到模型加载的实战记录

5.1 环境与数据库层：启动失败的三个高频原因

现象：运行 python manage.py runserver 后在登录页提交表单，页面报错，提示 MySQL 连接失败，或者数据库操作返回 2003/1045 错误码。

原因：这类错误绝大多数出在 settings.py 的数据库配置和本地 MySQL 环境不匹配。2003 表示 MySQL 服务没启动或端口不对，1045 表示用户名或密码不正确。遇到这种问题先别怀疑代码，八成是环境问题。

解决：第一步确认本地 MySQL 服务已经启动，Windows 下在服务管理器里查看 MySQL 服务状态。第二步检查 settings.py 里的 DATABASES 配置，把 NAME、USER、PASSWORD、HOST、PORT 逐项对一遍。我一般会先在命令行用 mysql -u root -p 手工连一次库，能连上说明账号密码没问题，再回过来看 Django 配置。

现象：登录成功后首页的舆情列表和文本分析结果里的中文全部显示成问号或乱码。

原因：数据库表没有使用 utf8mb4 字符集，或者 Django 连接 MySQL 时没有指定 charset。中文乱码是这类系统里最折磨人的问题，因为它不影响程序报错，只影响数据正确性，属于“黑匣子”式故障，排查起来比直接报错更费劲。

解决：建表语句统一加 DEFAULT CHARSET=utf8mb4，MySQL 连接 URL 或 Django 配置里加上 charset 参数。如果数据已经写入，需要先把表删掉重建再重新导入数据，没有后悔药可吃，所以强烈建议在第一次建库时就确认字符集。

现象：pip install -r requirements.txt 后项目启动报版本冲突，最常见的是 Django 版本和 mysqlclient 版本不兼容，或者 transformers 版本要求过高导致 Python 3.6 环境装不上。

原因：requirements.txt 里锁定的版本和当前 Python 环境不匹配。很多毕业设计资源包的依赖清单是作者本机生成的，换一台机器就踩坑。

解决：不要无脑装最新版，按照当前 Python 版本来选 Django 和 mysqlclient 的兼容组合。Python 3.8 配 Django 3.x 加 mysqlclient 2.x 是比较稳的组合；如果 transformers 版本要求太高，降级到 4.x 的早期版本可以绕开。这类依赖问题，虚拟环境是唯一的解药。

5.2 模型与数据层：算法相关的高低频踩坑点

现象：点击文本分析后页面长时间无响应，过一会儿报内存不足或进程被杀，控制台出现 OutOfMemory 相关错误。

原因：BERT 模型体积动辄几百 MB，加载进内存后占用非常高。8GB 内存的开发机器同时跑 Django 服务、MySQL 和两个模型，很容易触到内存天花板。论文里的开发环境恰恰是 8GB 内存的笔记本，所以这几乎是可以预见的坑。

解决：第一种办法是改小模型，把 bert-base-chinese 换成蒸馏后的小模型，速度和占用都会明显下降；第二种办法是模型懒加载，只在第一次请求时初始化，不要放在 Django 启动时加载；第三种办法是直接把两个模型的计算放到独立进程里，Django 通过 HTTP 或本地队列接口调用，但这个方案对毕业设计来说改动量偏大，不推荐新手尝试。

现象：从平台采集舆情数据时，程序跑了一会儿就停住，或者采集到的内容少得可怜，导致首页统计图没有数据可显示。

原因：这类系统的基础数据来自公开页面的采集程序，但采集逻辑里如果缺少异常捕获、请求间隔和断点续采机制，触发反爬限制或网络波动时就会静默中断。

解决：给采集循环加上 try...except 包裹单条请求，失败时记录日志而不是整体退出；两次请求之间加 sleep 间隔，控制采集频率；每采到一定数量就增量写入数据库，避免最后统一落库导致任务中断后数据全部丢失。这三板斧做完，采集稳定性会明显提升。

注意：采集公开言论时要遵守平台协议和相关规定，只处理公开发布的信息，不要碰未授权的内容，这也是这个系统本身“保障网民隐私权和言论自由权”的前提。

6. 二次开发实战：替换文本分析模型并验证效果

6.1 预留模型接口，让视图层不感知底层算法

这套系统最值得改的地方是算法层。原文的 DNN + BERT 组合在性能上有明显瓶颈，如果你只是想快速跑通演示，保持原样没问题；但要做课程升级或者简历项目，我建议把模型替换成体积更小、部署更轻的方案。前提是接口不动。

# services/analysis_service.py 改造后的统一接口 class TextAnalysisService: def __init__(self, model_type='fasttext'): self.model_type = model_type if model_type == 'fasttext': import fasttext self.model = fasttext.load_model('algorithm/fasttext_model.bin') elif model_type == 'bert': # 保留原 BERT 实现 pass def analyze(self, content): if self.model_type == 'fasttext': label, score = self.model.predict(content) sentiment = label.replace('__label__', '') return {'sentiment': sentiment, 'score': score[0]}

改造的核心思路是隔离变化：视图层调用的还是 analyze(content) 这个方法，返回的还是同样的字典结构，只是内部实现从 BERT 变成了 fastText 或者其他轻量分类器。这样即使把模型换成自己用 sklearn 训练的逻辑回归，也不影响文本管理和文本管理模块的既有代码。

6.2 改造后的验证与回归：用准确率和召回率说话

换完模型不能只看“能跑通”，还要做效果验证。我在评估替换方案时，一般会先手工标注几百条数据分正负中性，然后把模型预测结果和真实标注做对比，计算准确率和召回率，用它们决定这个模型是否值得替换。

# evaluate.py from services.analysis_service import TextAnalysisService service = TextAnalysisService(model_type='fasttext') test_data = [('这服务太差了', '负面'), ('今天天气不错', '正面'), ('普通的一天', '中性')] correct = 0 for content, true_label in test_data: result = service.analyze(content) if result['sentiment'] == true_label: correct += 1 accuracy = correct / len(test_data) print(f'准确率: {accuracy:.2f}')

验证脚本的逻辑很简单：准备一批带标注的测试样本，逐条喂给分析服务，统计预测结果和真实标签的匹配比例。这样做有两点作用：第一，验证模型接口在替换后是否正常工作；第二，用数字对比新旧模型的判断能力，避免出现“能运行但结果明显离谱”的情况。准确率低于原模型的话，要么调参，要么换回原方案。

6.3 还能往哪改：数据源、权限级别和可视化

除了换模型，这套系统还有三个值得改动的方向。数据源层面，原文的采集范围只有微博，实际上可以把微信公众号文章、贴吧帖子、新闻评论区都纳入采集源，每条言论打上来源标记，扩展 text_info 表的 source 字段。权限层面，现在的用户管理只有管理员和非管理员两级，可以改成多级角色，比如“普通用户、分析员、超级管理员”，分析员只能看文本不能删用户，超级管理员才有全部权限。可视化层面，对比分析模块目前只有饼图和柱状图，可以引入 ECharts 的时间线折线图，看某个话题的情感倾向随时间的变化趋势。

这三个方向都不需要推翻原有架构，每条都能在现有表结构上加字段或加页面来实现。从那以后，我每次拿到一套带论文的 Django 源码，都会强制先看数据库脚本和依赖清单，再动代码，这个习惯让我避开了很多翻车现场。希望帮到你。

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