企业官网建设流程全解析

“Django毕设源码分享”这个标题，我一看就觉得很亲切。每年毕业季，总有不少学弟学妹被Web开发方向的选题折腾得够呛，要么是技术栈太老旧拿不出手，要么是功能太简单撑不起一篇论文的工作量。可视化学习系统这个方向，恰好卡在一个很舒服的位置：技术上不堆砌，但该有的模块一个不少，尤其“可视化”这三个字，是天然的加分项。这篇文章我就以这个项目为例，把从需求拆解到最终部署的完整链路掰开揉碎讲清楚，既有代码层面的实操，也有论文写作和答辩展示的配套思路，希望能给正在做类似选题的朋友一些参考。

先说结论，这个项目的核心竞争力在于“学习数据可视化”这个切入点。传统的学习管理系统，无非是上传课件、布置作业、在线考试，数据的价值被严重浪费。而“可视化学习系统”把用户的学习行为——比如视频观看时长、章节完成度、练习正确率、活跃时段分布——采集起来，并通过图表直观呈现。这个设定的好处太多了：对管理员来说，能一眼看出哪个课程最受欢迎、哪些章节的流失率高，从而优化内容；对学生来说，能看到自己的薄弱点和学习趋势，自查自纠；对导师来说，答辩时看到“学习行为分析”这个功能，会觉得你的工作有实际应用价值，而不只是CRUD（增删改查）的堆积。

下面我从头开始，把这个项目怎么一步步做出来，讲清楚。

1. 项目整体设计与思路拆解

1.1 需求分析：一个可视化学习系统到底要解决什么问题

很多同学拿到题目就开始建表、写代码，这是大忌。我习惯先画一张业务流程图，把自己当作使用者，走一遍完整的用户旅程。对于一个可视化学习系统，核心角色无非三类：学生、教师、管理员。我们逐个分析他们的痛点。

学生想要什么？我想要一个清爽的学习空间，能看视频、做练习、看自己的学习报告。注意“清爽”二字，这意味着界面不能是后台管理系统那种密密麻麻的表单堆砌，而是像慕课网、网易云课堂那样以课程卡片为单位的呈现。学习报告也不是简单的成绩列表，而是“本月累计学习12小时，环比上周增长25%，薄弱知识点集中在‘数据库索引’章节”这类有洞察力的结论。

教师想要什么？教师关心的是教学效果。他需要一个“学情总览”页面，能看到自己所授课程的选课人数、平均完成度、各章节的跳出率。更进阶一点，系统要能自动计算“预警学生名单”，比如某位学生连续一周学习时长低于阈值，或者某章节练习三次未通过，系统主动提醒教师关注。

管理员想要什么？管理员关注的是平台运营。课程的分类分布、用户增长趋势、服务器的资源占用，这些都需要一目了然的图表。权限管理也必不可少，但不需要做到RBAC（基于角色的访问控制）那么复杂，用Django自带的用户组加装饰器就能搞定。

把这个需求清单列出来，数据库表结构和功能模块其实已经呼之欲出了。学生端有课程浏览、章节学习、练习答题、个人学习报告；教师端有课程管理、章节内容维护（视频外链、文本资料）、学情统计；管理员端有用户管理、全站数据看板、系统日志审计。这三个端口的业务逻辑在同一套Django项目中实现，通过中间件和装饰器区分权限，比拆成三个独立项目要省力得多，也方便论文里写“系统采用模块化设计，耦合度低，易扩展”。

1.2 技术选型：为什么是Django而不是Flask或Spring Boot

做毕设或者中小型项目，我向来首推Django，理由是“约定优于配置”的框架哲学太适合这个场景了。初学者最容易陷入的泥潭是“选择困难症”——数据库用MySQL还是PostgreSQL？ORM用SQLAlchemy还是原生SQL？模板引擎用Jinja2还是Mako？这些问题在Django里都不存在，它全帮你定好了。尤其如果你是新手，第一要务是跑通闭环，而不是在技术选型上消耗意志力。

对比Flask，Django自带Admin后台、ORM、迁移工具、Auth体系，极大减少了重复造轮子的工作量。拿用户系统举例，Flask需要自己写登录视图、会话管理、密码加密、找回密码邮件，一套下来至少三五百行代码；Django一条python manage.py startapp users，再配置几行settings，自带的后台就能管理用户了，@login_required装饰器直接保护视图。省下来的时间足够你把可视化图表做精致三个档次。

对比Spring Boot，Django的优势在于开发效率。Java系的注解和配置对初学者过于繁琐，而且部署环节需要装Tomcat、打War包，本地环境和服务器环境不一致的坑能踩到你怀疑人生。Python + Django则轻量得多，python manage.py runserver就能在本地跑起来，部署用Gunicorn + Nginx的组合，整个链路清晰可控。

当然，选择Django也有需要注意的地方。它的ORM在处理复杂聚合查询时需要一些技巧，比如annotate和values的配合、子查询的嵌套，这些在可视化报表的统计接口里会频繁用到。另外Django默认的同步阻塞模型在高并发场景下表现平平，但对毕设和中小型系统来说完全够用。我在部署层用Nginx做静态资源服务和反向代理，稍微缓解一下并发压力，实测效果稳定。

1.3 项目结构规划：一个清晰的目录是后期不崩溃的前提

Django项目如果目录结构混乱，写到后期连自己新建的文件都找不到在哪里。我习惯按照“按功能分app”的方式来组织，而不是把所有视图塞进一个views.py里。推荐结构如下：

visual_learning/ ├── manage.py ├── config/ # 项目配置 │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── users/ # 用户模块 │ ├── courses/ # 课程与章节 │ ├── learning/ # 学习记录、练习答题 │ └── dashboard/ # 可视化图表与报表 ├── static/ # 静态文件（JS、CSS、图片） ├── templates/ # 全局模板 ├── media/ # 用户上传文件 └── docs/ # 设计文档、接口文档

每个app内部继续分层，views按功能拆分为student_views.py、teacher_views.py、admin_views.py，或者用views/目录包，内部包含student.py、teacher.py、admin.py、common.py。Utils工具函数单独放一个utils.py，比如日期处理、图表数据组装、Excel导出等。

这个结构的好处是职责清晰，写论文的时候“系统架构图”也特别好画——画一个层次分明的架构图，从上到下是业务层、应用层、模型层、数据层，对应Django的Template、View、Model、Database。跨app的调用尽量少，比如apps/learning只负责学习记录和答题，它需要课程信息时通过Course模型的外键关系获取即可，不要在learning里重复实现课程查询逻辑。

2. 核心功能模块的详细设计与实现

2.1 用户系统扩展：基于Django Auth的二次开发

Django自带的User模型只包含用户名、密码、邮箱等基础字段，不足以支撑学习系统的业务需求。我的做法是新建一个UserProfile模型，用OneToOneField关联内置的User，扩展出学生号和教师工号、所属班级、头像、学习积分等字段。为什么不直接改User模型？因为替换自定义用户模型需要在新项目初始化时就执行，否则后续迁移会非常痛苦。如果你是从头搭建项目，也可以直接继承AbstractUser，但考虑到很多同学习惯用现成的迁移文件，OneToOne扩展是最稳妥的兼容方案。

# apps/users/models.py from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): """ 自定义用户模型，替换默认的User 后续可扩展手机号、头像等字段 """ mobile = models.CharField(max_length=11, blank=True, null=True, verbose_name="手机号") avatar = models.ImageField(upload_to='avatars/', blank=True, null=True, verbose_name="头像") role = models.CharField(max_length=10, choices=(('student', '学生'), ('teacher', '教师'), ('admin', '管理员')), default='student') class Meta: db_table = 'auth_user_ext' verbose_name = "用户扩展"

登录认证支持邮箱+密码的方式，AUTHENTICATION_BACKENDS里自定义一个后端，不再赘述。需要留意的是，用AbstractUser替换默认User模型必须在第一次makemigrations之前完成，已经跑过迁移的老项目直接换会很麻烦。建议从一开始就用自定义用户模型，一劳永逸。

注册流程上，我加了邀请码机制。管理员在后台批量生成邀请码，学生注册时必须填入有效邀请码才能完成。这个设计的业务考量是防止垃圾注册，同时论文里可以多写一个“系统安全机制”的章节。教师账号则由管理员在后台直接创建，初始密码随机生成，首次登录强制修改。

2.2 课程与章节模型：树形结构的优雅实现

课程、章节、课时（或者叫知识点）之间是典型的三级树形结构。最直观的建模方式是用三个模型加外键逐级关联：

class Course(models.Model): title = models.CharField(max_length=100) cover = models.ImageField(upload_to='covers/') description = models.TextField() teacher = models.ForeignKey(User, on_delete=models.CASCADE, related_name='courses_taught') created_at = models.DateTimeField(auto_now_add=True) class Chapter(models.Model): course = models.ForeignKey(Course, on_delete=models.CASCADE, related_name='chapters') name = models.CharField(max_length=100) order = models.PositiveIntegerField(default=0) class Meta: ordering = ['order'] class Lesson(models.Model): chapter = models.ForeignKey(Chapter, on_delete=models.CASCADE, related_name='lessons') title = models.CharField(max_length=100) video_url = models.URLField(blank=True) content = models.TextField(blank=True) # 图文内容 duration = models.PositiveIntegerField(default=0, help_text="视频时长，单位分钟") order = models.PositiveIntegerField(default=0)

注意这里的related_name使用，我用chapters和lessons作为反向查询的名字，在模板和ORM查询时会非常顺手。比如在课程详情页，一行代码就能取出所有章节及课时：

course.chapters.prefetch_related('lessons').all()

因为关联的数据量不大，用prefetch_related避免N+1查询问题。

章节排序我直接用一个order字段控制，不做复杂的拖拽排序。教师编辑课程时，通过ModelForm和inlineformset_factory实现在同一个页面管理多个章节和课时，这个技巧论文里可以写“批量增删改查的优化实践”，工作量不大但技术含量可观。

2.3 学习行为采集：埋点设计与异步处理

学习系统最核心的数据是“学习行为”。我定义了三类行为：观看视频（包括开始、暂停、结束）、阅读图文材料（记录滚动深度和停留时间）、完成练习（记录选项、用时、得分）。每类行为都会产生一条记录，写入StudyRecord表。

为了控制服务器压力，写操作用了异步队列的方案。可能有人会问：“毕设项目为什么还要引入消息队列？”我的回答是：从架构设计的角度出发，这是一个“亮点功能”，能体现你对系统容错性的思考，而且实现并不复杂。

# apps/learning/tasks.py from celery import shared_task from .models import StudyRecord @shared_task def save_study_record(record_data): StudyRecord.objects.create(**record_data)

前端通过Ajax将行为数据POST到某个视图，该视图不直接写数据库，而是调用save_study_record.delay(data)丢给Celery后台。这样即使在高峰期，前端也不会因为数据库写入慢而卡顿。本地开发时用内存队列跑起来非常方便。

采集时刻表数据的关键字段是：user_id、lesson_id、event_type、value（比如播放进度百分比）、event_time。注意event_time不能使用auto_now_add，因为异步任务可能会延迟执行，我们要保留的是用户操作的真实时间，所以前端传参时附带new Date().getTime()。

2.4 练习与题库：支持多种题型的灵活设计

题库的设计比较讲究。为了支撑论文里的“智能化组卷”或有“错题本”功能，我建议题库模型采用“面包屑式”设计：一张Question表存所有通用字段（题干、难度系数、知识点标签、答案解析），然后用几个子表存各题型专属字段（选择题的选项用JSON数组存储，判断题只存答案，简答题存参考答案）。

class Question(models.Model): TYPE_CHOICES = (('single', '单选题'), ('multiple', '多选题'), ('judge', '判断题')) course = models.ForeignKey(Course, related_name='questions') type = models.CharField(max_length=10, choices=TYPE_CHOICES) stem = models.TextField(verbose_name='题干') options = models.JSONField(default=dict, blank=True) # {'A': 'xxx', 'B': 'xxx'} answer = models.CharField(max_length=50) difficulty = models.FloatField(default=0.5, verbose_name='难度系数') knowledge_points = models.JSONField(default=list, blank=True) analysis = models.TextField(blank=True, verbose_name='答案解析')

题目与用户的答题记录AnswerRecord外键关联。判分逻辑很简单：客观题直接比对答案，主观题（如果系统支持的话）就存待批改状态，教师在后台列表点击查看并填写分数。考虑到毕设工作量，我建议只做客观题，用自动判分，系统效率高，学生体验也顺畅。

有一点值得特别说明：选项用JSONField而不是单独一张选项表，虽然从数据库三范式的角度看“不规范”，但从业务角度看，题干和选项是不可分割的整体，查询时不需要跨表，性能更好，代码也更简洁。在论文的设计说明里可以专门写一小段“非规范化设计在特定场景中的权衡”，导师会觉得你考虑问题很全面。

3. 可视化大屏与图表的实现细节

3.1 图表库选型：ECharts确实是首选

可视化是这个项目的门面，务必在视觉上做出“高级感”。我的首选是百度开源的ECharts，理由很直接：文档全、示例多、配置灵活，而且图表类型覆盖了所有业务需求——折线图看学习趋势、柱状图看课程热度、饼图看知识点分布、雷达图看学生综合能力、热力图看一周活跃时段。最省事的是，它的中文文档对初学者非常友好，照着示例改数据就能跑出来一个像模像样的图表。

前端集成方式很简单：用CDN引入echarts.min.js，或者在static/js/里放一份本地文件。需要渲染图表的页面，在HTML里写一个<div id="chart" style="height:400px"></div>，然后在script标签里执行初始化。注意一个坑：页面可能因为数据已经加载完成、但图表尚未执行初始化而出现空白，建议把初始化代码放在window.onload或者JQuery的$(document).ready里。

如果页面里有多个图表，建议封装一个initChart公共函数，传入DOM元素ID、图表配置项、数据，返回一个chart实例。这样代码复用性高，也方便后续维护。

3.2 后端报表接口设计：SQL聚合与Python处理的平衡

可视化的核心是后端要提供干净的结构化数据。假设前端要展示“本周每日学习时长分布”，后端接口应该返回这样的JSON格式：

[ {"date": "2025-06-02", "study_seconds": 3600}, {"date": "2025-06-03", "study_seconds": 5400}, {"date": "2025-06-04", "study_seconds": 1800} ]

这个数据在ORM里如何查询？我们需要对StudyRecord按天分组并汇总时长。最直接的方式是用ORM的extra或TruncDate：

from django.db.models.functions import TruncDate from django.db.models import Sum daily_study = ( StudyRecord.objects .filter(user_id=request.user.id, event_type='video', event_time__gte=start_date, event_time__lt=end_date) .annotate(day=TruncDate('event_time')) .values('day') .annotate(total_seconds=Sum('value')) .order_by('day') )

这里有个细节要提醒：event_time是UTC时间还是本地时间，直接决定“天”的划分是否正确。Django的USE_TZ配置如果你开启为True，数据库存储的是UTC时间，查询时TruncDate会用UTC来切分，导致和中国时区对不上。最省心的办法是把event_time存储为本地时间戳（不使用带时区的DateTimeField，或者设置USE_TZ=False），虽然牺牲了多时区支持，但毕设场景完全够用，还不用处理时区转换的头疼问题。

对于更复杂的统计，比如“各知识点掌握程度”，单纯ORM聚合不够直观，我会在Python里做二次加工。先查出某学生所有答题记录，按知识点分组算正确率，再用一个映射表把知识点对应到章节名称，最终组装成前端能直接消费的数据。这个过程虽然看起来“绕了一圈”，但胜在灵活，且便于写单元测试。

3.3 可视化大屏布局与展示效果

“可视化学习系统”少不了一个大屏页面。我的做法是做一个独立路由/dashboard/overview/，整体采用深色科技风背景（深蓝渐变加霓虹光效文字），页面由多个图表组件拼成。大屏的布局用Bootstrap的栅格系统，或者干脆用CSS Grid，分成12列，每个图表占3列或6列。页面顶部是标题和时间，左上角放“今日活跃人数”、“新增用户数”、“学习总时长”三个数字卡片，中间是学习时长的折线趋势图，右侧是课程分类占比饼图，下方是热门课程排行榜和学习行为热力图。

大屏页面的数据通过Ajax定时轮询，每30秒请求一次最新数据，局部更新图表。这个“实时刷新”功能在答辩演示时特别能抓眼球——现场看到数字跳动和图表更新，效果比静态截图强一百倍。实现也不复杂，setInterval里重新setOption就行。

强调一下，图表不是越多越好，而是逻辑要通。比如“课程热度”和“学习行为热力图”之间最好有业务上的关联，事后在讲解时能串成故事：“从热力图看，周三晚上是学习高峰期，而热门课程中恰好在周三晚上组织直播答疑，说明直播确实拉动了活跃度”——这种有业务洞察的解说词，是论文答辩中拉开档次的关键。

4. 部署上线与性能优化

4.1 本地开发环境的坑与建议

本地开发阶段，最大的坑往往是静态文件路径。Django默认的静态文件配置在开发环境中可以通过runserver正常访问，但注意DEBUG=False时就不会再由服务器代劳了。我建议从第一天起就按生产模式配置：STATIC_ROOT和STATIC_URL分开，开发时用django.contrib.staticfiles的runserver，部署时用Nginx。

数据库方面，开发用SQLite没问题，但部署前务必迁移到MySQL或PostgreSQL。SQLite的并发写能力有限，而且某些SQL函数（比如TruncDate）在不同数据库上的行为有差异。迁移过程用Django自带的dumpdata导出、再loaddata导入，很方便。需要提醒的是，如果数据量很大，导出JSON文件可能非常大，loaddata时间比较长，要耐心等待。

虚拟环境务必用venv，依赖清单用pip freeze > requirements.txt保存。我见过太多因为依赖不一致，在本地能跑、到服务器上一堆报错的情况。另外建议把requirements.txt按依赖类型分类，基础依赖、生产依赖、开发依赖分开，方便排查问题。

4.2 Linux服务器部署：Nginx + Gunicorn + MySQL的组合

部署方案我用的是“Nginx + Gunicorn + MySQL”的经典组合。Gunicorn负责跑Django应用，Nginx负责反向代理和静态文件处理。具体流程可以总结为：

• 服务器安装Python 3.10+，创建虚拟环境，安装项目依赖。
• 安装并配置MySQL，创建数据库和用户，修改settings.py中的数据库配置。
• 迁移数据：python manage.py makemigrations && python manage.py migrate。
• 收集静态文件：python manage.py collectstatic --noinput，复制到Nginx指定的目录。
• 用Gunicorn启动项目，绑定的端口比如8001：gunicorn config.wsgi:application -b 0.0.0.0:8001 --workers=3。
• Nginx配置一个server块，监听80端口，location /static/指向静态目录，其余请求proxy_pass http://127.0.0.1:8001。

配置Nginx时要特别注意proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;这两行，否则Django的request.META['REMOTE_ADDR']拿到的会是Nginx的地址而不是用户真实地址，影响登录审计和访问控制。

关于Gunicorn的workers数，经验公式是2*CPU核心数+1。我的小服务器是2核4G，设了5个worker，实测能支撑小几十人同时在线。如果要更高性能，可以考虑换uvicorn用ASGI支持的异步模式，但Django的同步视图在ASGI下只是兼容运行，性能提升有限，毕设不折腾这个。

系统托管方面，用systemd来守护Gunicorn进程，配置一个service文件，设置Restart=always。这一点非常重要，否则某个进程崩了又没有人及时拉起，整个系统的可用性就没保障了。

4.3 缓存与性能优化：让页面秒开

可视化系统的图表页如果每次都实时算聚合SQL，数据量大了之后会变慢。我引入了Redis做缓存，针对两类内容：一是管理员的“全站看板”数据，这个全局只有一个，缓存时间可以设5分钟；二是学生的“个人学习报告”，用user_id做缓存键，缓存时间设10分钟。当有新学习记录写入时，需要主动删除对应用户的缓存，否则报告更新滞后，影响体验。这个逻辑用Django的信号机制（post_savesignal）实现比较干净，每次StudyRecord保存后自动清除相关缓存。

另一个性能优化点是数据库索引。StudyRecord表的user_id、event_time、event_type三个字段建立联合索引，能显著提升按用户和时间范围查询的速度。索引的原理在论文里可以写一段“数据库索引对查询性能的影响”，配合EXPLAIN命令的实际对比数据，很有说服力。

前端性能优化也不能忽视。ECharts的包本身不小，建议用按需引入的方式。CDN上有按需构建的版本，或者通过echarts/core这样的入口按需注册图表类型和组件。图片资源用懒加载插件lazyload，视频播放用django-video-encoding或者直接外嵌B站/优酷的播放器，减少带宽压力。如果页面图表太多，还可以考虑前端用IntersectionObserver做可视区域懒渲染，滚动到哪个图表才真正初始化哪个，优化首屏速度。

5. 常见问题与排查技巧实录

5.1 学习记录重复写入与幂等性

这是一个特别典型的坑。前端播放器每5秒上报一次播放进度，但网络抖动可能导致重试，造成同一节课同一时间点的记录写入两次，统计数据就会翻倍。解决思路是加一个“幂等键”，比如user_id + lesson_id + session_id组合唯一索引，用get_or_create或update_or_create来写，而不是简单的create。前端每次进入课程时生成一个session_id，课程期间保持不变，这样重复的请求不会生成多条记录。

后端处理时，还有更稳妥的方式：MySQL中使用INSERT ... ON DUPLICATE KEY UPDATE，Django里可以用queryset.update_or_create模拟，虽然效率略低，但逻辑简单可靠。论文里可以写“系统设计了请求去重机制，通过业务唯一键保证学习记录的一致性”，导师会注意到这个细节。

5.2 图表中文乱码与字体问题

服务器上生成的图片验证码或者导出PDF如果包含中文，常常出现乱码，原因是系统没有安装中文字体。这个坑很隐蔽，因为本地开发是带有字体的，上了服务器就露馅。解决办法是确保服务器装好中文字体，比如fonts-wqy-zenhei，或者把字体文件放在项目static/fonts/下，用matplotlib或Pillow动态加载。如果你的图表是纯前端ECharts渲染，一般不存在这个字体的坑；但一旦涉及到后端生成图片（比如论文里的图），就要格外留意。

5.3 Celery定时任务不执行

如果集成了定时任务，比如每天凌晨统计昨日数据，要检查Celery Beat是否正常启动。排错思路：先确认Redis连接是否正常（redis-cli ping），再看Celery worker的日志有没有报错，最后测试任务函数本身能否手动执行成功。定时任务的时区配置也有讲究，CELERY_TIMEZONE要设成Asia/Shanghai，并且DJANGO_SETTINGS_MODULE环境变量要正确，否则Celery独立于Django启动时找不到配置。

5.4 一个排查技巧速查表

还有一个老生常谈但屡试不爽的问题：报错“__init__()missing 1 required positional argument: 'request'”通常是视图类的as_view()用法有误，Django的类视图在URL里要用类名.as_view()`，而不是直接传类对象。

6. 论文与答辩的进阶准备

6.1 论文结构建议：怎么把项目写成“有深度”的毕设

很多同学项目做完了，但论文不知道怎么组织。我提供一个参考目录框架，你在写的时候可以按这个骨架填充：

• 绪论：研究背景与意义（可视化教育、学习分析的兴起）、国内外研究现状（引用几篇相关文献）、主要研究内容与章节安排。
• 相关技术简介：Python、Django框架、ECharts、MySQL/Redis、Celery异步任务。这一章别写太长，挑和系统直接相关的部分，每项写清“为什么选它”。
• 系统需求分析与总体设计：需求分析（功能需求、非功能需求）、系统架构设计（三层架构图）、功能模块划分、数据库设计（ER图、数据表说明）。
• 系统详细设计与实现：按“用户模块、课程模块、学习行为模块、可视化模块、部署方案”逐章展开，每章包含数据流程、核心代码片段（重要方法）、界面截图。
• 系统测试：测试环境、功能测试用例表格（覆盖每个模块的主要功能点）、性能测试（用locust或wrk做压测，给出QPS和响应时间）、兼容性测试。
• 总结与展望：总结工作、指出不足、展望未来（比如引入推荐算法、智能预警、移动端适配）。

论文答辩时有一个很强的加分项是“对比验证”。你可以部署两套环境，一套不加缓存、不加索引，一套优化过，然后跑同样的压测脚本，用柱状图对比响应时间。这就不只是感性描述“系统性能良好”，而是有数据支撑的“性能优化效果验证”，导师的评价会高不少。

6.2 答辩演示的动线设计

答辩演示往往只有5-10分钟，一定要提前规划好一条完整演示路径，不能想点哪就点哪。我的建议动线是：

1. 从登录页面进入，展示用户登录和权限跳转。
2. 以学生身份进入课程列表，选择一门课，进入章节页，播放一段视频，点一个练习。
3. 切到个人学习报告页面，展示刚才的操作如何实时反映到可视化图表中（数据联动，这个点要讲清楚）。
4. 以教师身份演示课程管理、学情总览，说明如何查看预警学生。
5. 以管理员身份展示全局大屏，强调实时刷新和大数据量的呈现效果。
6. 最后留1分钟讲部署架构图，展示Nginx/Gunicorn/MySQL/Redis的链路。

每个步骤都要提前录好备用视频，万一现场网络不好或浏览器卡住，直接播放录像兜底。我见过太多现场演示翻车的案例，这条“预案思维”请一定记在心里。

6.3 一套代码如何扩展成“亮点功能”

如果你还有额外的时间和精力，下面几个扩展方向性价比很高，而且并不难实现：

• 学习路径推荐：按学生完成度、正确率等数据，推荐下一门最适合的课程。用简单的规则引擎实现即可，比如“初级课程完成80%以上且正确率超70%，自动解锁中级课程”。
• 知识点图谱：把课程章节之间的前置关系用关系图（ECharts Graph）可视化，学生点某个节点能跳到对应章节。
• 班级横向对比：以班级为单位，对比平均学习时长、平均成绩，直观看出班级整体的学风。
• 导出报告：用reportlab或python-docx生成PDF/Word格式的学习报告，支持教师一键导出全班学情。

这些扩展功能不用全做，挑一个做得完整、做得精致，就足够在“后续工作展望”和答辩加分项里大书特书了。

最后再分享一个小技巧，也是我做了好几个项目后悟出来的：写代码之前先把数据库的ER图画明白，表结构一旦定了，后面的业务逻辑基本就是顺着表关系“翻译”成代码，不太会跑偏。可视化系统的核心表无非就是User、Course、Chapter、Lesson、StudyRecord、Question、AnswerRecord这几张，把它们之间的关系理清楚，这个项目的心智模型就建立了。希望这篇文章能帮你在做毕设的路上少踩几个坑，顺利通关。