又到毕业设计季，每年这个时候都有人后台问我同一个问题：“老师让做一个XX管理系统 / XX分析系统，但Django我还没跑通，怎么交差？”今天就以“基于Django的大学生网络行为分析系统”为例，把这一类选题从技术选型、数据采集、行为分析、可视化，到部署交付、远程调试、文档整理的完整链路拆开讲一遍。
这套东西不是简单的增删改查，它同时覆盖了Django的MTV模式、ORM数据库设计、中间件机制、异步任务、图表可视化、权限控制和生产部署，是性价比非常高的一类毕设选题。只要搞清楚底层逻辑，哪怕你是Django新手，也能在两周内做出一套能答辩、能演示、能跑demo的系统。
这套系统的核心是“采集—分析—展示”三个环节。采集端接收学生用户在网络环境中的访问记录，分析端对记录做频次、时段、分类、时长等维度的聚合，展示端通过图表和列表把分析结果呈现给辅导员或管理员。听起来抽象，落地下来就是一套“有人管、有人看、有数据”的Web平台。
这篇博客会按实际开发顺序来讲，不是教科书式的功能介绍，而是我踩过坑、填过窟窿之后的操作记录。全文尽量少说废话，关键代码直接给，参数和原理尽量说透。
1. 项目整体设计与技术选型
1.1 为什么用Django而不是Flask或Spring Boot
Django能成为这类毕设的首选，核心原因是“开发效率”。网络行为分析系统的业务逻辑不算特别复杂，但涉及的东西很杂：用户登录、权限分级、数据记录、定时统计、图表接口、后台管理。如果全用手写，工作量会失控。
Django自带Admin后台是一个巨大的优势。毕设里经常有“管理员查看用户列表”“管理员管理角色”这种功能，Django的Admin在Model建好后，登录管理页就能直接用，连前端页面都省了。再有就是MTV模式，Model、Template、View三层分离，代码结构清晰，导师看设计文档也好写。M在上、T在上、V在中间，请求进来之后由URL路由匹配到View，View去操作Model拿数据，再渲染到Template上。理解了这个流程，后面所有功能都是在这个链路上加点东西罢了。
Flask虽然轻量，但ORM、迁移、后台、认证全要自己配，对毕设来说拖太久。Spring Boot在企业里用得广，可Java环境部署、依赖注入那套对新手不友好，更关键的是毕设论文写Django的MTV模式，比写Spring的MVC更容易讲清楚。
1.2 系统功能模块划分与总体架构
我一般把系统拆成四个模块：用户与权限模块、数据采集模块、行为分析模块、可视化展示模块。
用户与权限模块负责登录、注册（或导入学生名单）、角色控制。角色至少分三种：学生本人、辅导员（或班主任）、系统管理员。三种角色的权限差异很大：学生只看自己的行为报告，辅导员看自己管理范围内的学生列表和班级汇总，管理员管理全部数据和系统配置。
这里多说一句，网络上很多人把RBAC（基于角色的访问控制）念成“rabc”，做毕设的时候别写错。Django自带的Group和Permission就能实现RBAC，但毕设里往往还需要在中间件或装饰器里做一层二次校验。我的方案是：创建用户的时候指定角色字段（用IntegerField，0学生、1导员、2管理员），再写一个自定义装饰器check_role来判断当前登录用户的角色。这样做的好处是逻辑直观，答辩时也容易解释：一个装饰器，挡住了非授权访问。
数据采集模块是整个系统的技术核心。严格意义上的网络行为分析需要抓取网络流量、解析TCP包、提取URL，这类方案在毕设里并不好落地，因为需要有真实网络环境支撑，而且容易触碰隐私和安全边界。我的处理方式是用“日志采集”代替“流量采集”：在学生访问系统内资源时记录请求日志，这样既符合网络行为分析的主题，又避免了复杂的底层抓包，也便于写成可演示的功能。
数据采集方式有三种落地方案，我在第3部分会详细写：Django中间件采集、浏览器端埋点采集、日志文件分析采集。三种方案各有优劣，可以根据导师的要求来选，也可以组合使用。行为分析模块则负责把原始日志转换成有意义的用户画像：访问次数、活跃时段、访问网站分类（学习类、生活类、娱乐类）、连续使用时长、高频访问时段等。
可视化展示模块是答辩拿分的关键部分。图表库我推荐用ECharts，中文资料多，图表漂亮，对Django模板也友好。不需要后端生成图片，前端直接用Ajax请求JSON数据，渲染成折线图、柱状图、饼图、热度地图，信息量一下子就上来了。
1.3 技术栈与版本选择建议
技术栈建议：
- 后端：Python 3.10 + Django 4.2 LTS
- 数据库：SQLite（开发） / MySQL 8.0（生产）
- 前端：Bootstrap 5 + AdminLTE 3（后台模板）+ ECharts 5
- 部署：Windows服务器下用Waitress + Nginx，Linux下用Gunicorn + Nginx
版本选择的逻辑是：Django 4.2是LTS版本，支持周期长，文档多，网上遇到问题更容易搜到答案。Django 5.0出的时候很多第三方库还没适配，毕设没有必要赶新版本。Python用3.10或3.11都行，但注意Django 4.2对Python版本有下限要求（3.8以上），用3.10最稳，不会遇到第三方包不兼容的问题。
数据库我建议开发阶段直接用SQLite，等系统跑通了再切MySQL。SQLite是文件型数据库，不用安装服务，拖到哪里都能跑，对毕设答辩现场演示来说非常重要。有些同学答辩前突然换电脑，SQLite直接拷贝库文件就能启动，MySQL还得装服务、备份恢复，手忙脚乱容易出错。
2. 核心模块设计与数据库建模
2.1 用户、角色与权限的数据表设计
数据库建模是整套系统的地基。表结构设计得好，后端代码写起来就顺手；设计得不好，后面就是无尽的补丁和临时判断。
用户相关的表直接继承Django自带User模型，再额外扩展一个UserProfile，存放学号、班级、角色等持有属性。不直接在User上加字段的好处是：不破坏Django默认表，将来迁移升级不容易出问题。建议设计如下：
class UserProfile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE) student_id = models.CharField(max_length=20, unique=True, null=True, blank=True) class_name = models.CharField(max_length=50, null=True, blank=True) role = models.IntegerField(default=0) # 0:学生 1:辅导员 2:管理员一个容易踩的坑是：不要在UserProfile里再用ForeignKey关联User，而要用OneToOneField。因为一个用户只能对应一份扩展信息，如果用了ForeignKey，逻辑上就能一个用户挂多份档案，违反了业务规则，数据也容易脏。
角色权限的校验放在装饰器里。我写了一个check_role的装饰器，参数是允许访问的角色列表：
from functools import wraps from django.http import JsonResponse def check_role(allowed_roles): def decorator(view_func): @wraps(view_func) def wrapper(request, *args, **kwargs): profile = UserProfile.objects.filter(user=request.user).first() if not profile or profile.role not in allowed_roles: return JsonResponse({"code": 403, "msg": "无权访问"}) return view_func(request, *args, **kwargs) return wrapper return decorator这个装饰器用法很简单：在视图函数上加一行@check_role([1, 2])，就表示只有辅导员和管理员能访问。答辩的时候往这个方向讲，导师会认为你对权限控制有真正的业务思考。
2.2 行为记录表的结构与索引设计
行为记录表是数据采集模块落地的核心，字段设计要兼顾两个目标：一是记录什么时间谁访问了什么内容，二是方便后续按多个维度做聚合统计。
建议设计如下：
class BehaviorRecord(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) access_time = models.DateTimeField(auto_now_add=True) url_path = models.CharField(max_length=255) method = models.CharField(max_length=10) ip_address = models.GenericIPAddressField(null=True, blank=True) duration = models.IntegerField(default=0) # 停留时长，单位秒 category = models.CharField(max_length=20, default='other') # study/life/entertainment/other created_at = models.DateTimeField(auto_now_add=True)这里要强调的是duration字段。原始日志不会主动告诉你“这个人待了多久”，需要自己计算。我的方案是在记录里存上一个请求的时间和当前请求的时间，差值就当作在上一界面的停留时长。这个逻辑不完美，但足够支撑毕设级别的行为分析。
索引设计上，给user和access_time加联合索引，因为最高频的查询是“某个学生在某段时间内的记录列表”。Django用Meta声明：
class Meta: indexes = [ models.Index(fields=['user', 'access_time']), ] ordering = ['-access_time']表结构一定要在设计阶段就定好，不要边写边改。我见过不少同学，模型改了三次，数据库迁移一直报冲突，最后干脆把db文件删了重新跑迁移——这在开发期没问题，但如果你已经录入了演示数据，删库重来会浪费很多时间。
2.3 行为分类与标签体系设计
行为分析如果只做到统计“访问次数”，深度明显不够。导师问问题的时候，八成会问：“你怎么判断这个学生访问的是学习网站还是娱乐网站？”所以分类标签体系是必须做的。
我的推荐方案是用“URL匹配关键字”来做分类。不需要用机器学习，因为毕设的数据来源有限，机器学习模型训练不出来，效果还不如规则匹配稳定。
CLASSIFY_RULES = { 'study': ['python', 'java', 'course', 'mooc', 'cnki', 'github', 'stackoverflow'], 'life': ['taobao', 'jd.com', 'zhihu', 'bilibili', 'douban'], 'entertainment': ['youtube', 'tt', 'douyu', 'huya', 'game'], }写一个分类函数，遍历规则列表，匹配到就返回对应的分类，匹配不到就输出other。这个函数在采集阶段同步调用，把分类结果直接写入BehaviorRecord的category字段，后续统计时直接按category聚合，不用每次都重新分类。
2.4 核心分析指标的计算逻辑
行为分析模块的核心指标包含：日活跃度（当天访问条数）、时段活跃热力（按小时统计访问次数）、类别占比（学习/生活/娱乐/其他）、平均停留时长、最长连续使用时长、周活跃趋势。
计算逻辑上要区分“实时查询”和“预聚合”两种。毕设规模的数据量级，直接实时查询就够了。比如统计某个学生近7天的活跃趋势，Django ORM写法如下：
from django.db.models import Count from django.utils import timezone from datetime import timedelta days = [] now = timezone.now() for i in range(7, 0, -1): day_start = now - timedelta(days=i) day_end = now - timedelta(days=i-1) count = BehaviorRecord.objects.filter( user=request.user, access_time__range=(day_start, day_end) ).count() days.append({"date": day_start.strftime("%m-%d"), "count": count})这个是死循环逐天统计，也可以换成TruncDate + annotate一次查出来，性能更好。我建议写进作品里的是后者，答辩时有技术含量：
from django.db.models.functions import TruncDate records = (BehaviorRecord.objects .filter(user=request.user, access_time__gte=now - timedelta(days=7)) .annotate(day=TruncDate('access_time')) .values('day') .annotate(count=Count('id')) .order_by('day'))这里面的原理是：TruncDate把datetime截断成date，再按day分组计数。一条SQL就完成了7天的聚合，而不是循环7次查询，效率差距在数据量大一点的时候非常明显。导师看到这个写法，会认为你的ORM功底是扎实的。
3. 实操过程与核心环节实现
3.1 项目创建与App规划
实际开发的第一步，建议先创建项目，再创建两个App：一个叫users，负责用户、角色、权限相关的所有内容；另一个叫analysis，负责行为采集、分类、统计和展示。
pip install django==4.2 django-admin startproject behavior_system cd behavior_system python manage.py startapp users python manage.py startapp analysis然后在settings.py的INSTALLED_APPS里注册这两个App。要注意，App的名字尽量不要用“test”“demo”这类太泛的名。用有语义的名字，不仅在代码里好识别，在论文的“系统实现”章节也更好写，一句话就能说清楚“users模块是做什么的”。
3.2 数据采集模块的三种实现方案对比
数据采集是整个系统的信息来源，方案选型直接影响后续所有功能的可行性和答辩的说服力。
方案一：Django中间件采集。这个是首选。Django的中间件在请求进入视图前和响应返回前都会执行，能拿到request对象，里面包含用户、URL、IP等字段。写一个自定义中间件，每个请求进来时记录一条行为记录，不需要前端做任何配合，纯后端就完成了数据采集。
class BehaviorLogMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): user = request.user if user.is_authenticated: path = request.path # 排除admin后台等静态请求 if not path.startswith('/static/') and not path.startswith('/admin/'): BehaviorRecord.objects.create( user=user, url_path=path, method=request.method, ip_address=request.META.get('REMOTE_ADDR'), category=classify_url(path) ) response = self.get_response(request) return response中间件的优点是采集自动化、精度高；缺点是不能记录用户在系统外的访问行为，比如学生打开了知乎、抖音再回到系统，中间那段在系统内的空白时间会被漏掉。做毕设来说，这个精度已经足够了，只要在论文里写清楚“本系统采集的是学生在校内平台内的行为日志”，逻辑就圆了。
方案二：浏览器端埋点采集。在前端页面里插入JavaScript代码，用fetch或sendBeacon把行为数据发送到后端接口。优点是能采集到鼠标点击、滚动时长、页面停留时间这些更细的数据；缺点是侵入性强，前端页面都要加入口，而且容易被人看穿。如果你不想写太多前端代码，不建议用这个方案。
方案三：分析Nginx日志。在Nginx的access.log里配置输出格式，定期写脚本解析日志，导入数据库。这个方案的优点是数据量真实，不需要前端配合；缺点是需要有真正的网络环境流量支撑，本地开发测试时没有日志可解析，演示效果很难保证。我只推荐对Linux和Nginx比较熟的读者选这个方案，否则调试成本很大。
3.3 分析接口与可视化对接实现
数据采集进来之后，要给前端图表提供JSON接口。我习惯用Django自带的JsonResponse来返回数据，接口路径设计成REST风格：/api/trend/、/api/category/、/api/hot-time/。
通常我把接口写view函数，配合JsonResponse直接返回。不需要引入Django REST Framework，毕设用DRF虽然是加分项，但它那套序列化器的学习成本有点高，普通函数视图配JsonResponse完全够用。
一个返回“类别占比饼图”数据的接口，写法可以是这样：
def category_stats(request): user = request.user profile = UserProfile.objects.get(user=user) if profile.role == 0: records = BehaviorRecord.objects.filter(user=user) else: records = BehaviorRecord.objects.filter(user__userprofile__class_name=profile.class_name) data = records.values('category').annotate(total=Count('id')) return JsonResponse({"code": 0, "data": list(data)})这里要注意，查询两个用户在不同角色下看到的数据范围不一样，学生只能看自己，辅导员能看本班的汇总。这条查询里用了跨关系的过滤，user__userprofile__class_name，Django的ORM会自动做表关联，但要注意关联字段名一定要和模型里的related_name对得上，否则会报FieldError。
前端模板里，用ECharts的饼图组件拿这个数据，核心代码就这一段：
fetch('/api/category/') .then(res => res.json()) .then(res => { if (res.code === 0) { categoryChart.setOption({ series: [{ type: 'pie', data: res.data.map(item => ({name: item.category, value: item.total})) }] }); } });3.4 创建模拟数据脚本与演示准备
一个很容易被忽视但极其重要的环节：写一个generate_demo_data.py脚本，批量生成模拟数据。毕设答辩的演示环节，如果库里只有你自己测试时留下的零星记录，图表画出来非常难看，就像一条心电图直接拉了直线。用脚本生成一个月的模拟行为记录，图表效果立刻饱满起来。
脚本逻辑不复杂：遍历20个学生用户，对每个用户循环30天，每天随机生成5到20条记录，时间和IP随机，URL从内置的样本列表里随机取。
import random from datetime import datetime, timedelta from django.contrib.auth.models import User from analysis.models import BehaviorRecord urls = { 'study': ['/course/python/1024', '/course/java/2048', '/resource/paper/309'], 'life': ['/community/zhihu/123', '/mall/taobao/888'], 'entertainment': ['/video/bilibili/233', '/game/steam/666'], } for user in User.objects.filter(userprofile__role=0)[:20]: start_date = datetime.now() - timedelta(days=30) for day_offset in range(30): for _ in range(random.randint(5, 20)): category = random.choice(list(urls.keys())) path = random.choice(urls[category]) access_time = start_date + timedelta(days=day_offset, hours=random.randint(8, 23), minutes=random.randint(0, 59)) BehaviorRecord.objects.create( user=user, url_path=path, method='GET', category=category, access_time=access_time )这个脚本可以在shell环境里执行：python manage.py shell < generate_demo_data.py，跑完就能看到数据量上来了。注意在答辩前生成一次演示数据，之后不要再随便跑这个脚本，否则会把已有的演示数据弄乱。
4. 部署、远程调试与项目交付
4.1 本地开发调试时的常用操作
开发阶段，python manage.py runserver启动开发服务器就够了。开发服务器支持自动重载，改完代码立刻生效，对调试非常友好。但要注意，runserver只适合本地开发，不适合作为生产环境服务。原因很简单：它是单线程的，性能不够，而且在并发请求下容易出现不可预期的错误。
本地调试时一个很容易忽略的坑是数据库迁移顺序。先创建Model，然后马上执行python manage.py makemigrations和python manage.py migrate。每次改Model，都要重复这个过程。如果忘了执行迁移，会报OperationalError: no such table: xxx，这个错误几乎是新手必踩的，看到之后先别慌，检查一下刚才有没有跑迁移。
4.2 Windows服务器下Waitress + Nginx部署
先讲Windows环境下的部署方案，因为很多同学的服务器是Windows Server，或者就用自己的Windows电脑做演示。Django的runserver不能用于生产，推荐用Waitress。它是Windows下兼容性最好的Python WSGI服务器，安装和使用都很简单：
pip install waitress waitress-serve --listen=127.0.0.1:8000 behavior_system.wsgi:application注意这里behavior_system.wsgi:application是对应你的项目名，如果你项目名不叫behavior_system，这个命令要相应修改。
只跑Waitress，用户只能通过IP加端口访问，而且静态文件默认不会处理，图片CSS都会丢。所以需要在前端加一层Nginx做反向代理和静态文件托管。Nginx的配置核心部分如下：
server { listen 80; server_name your_server_ip; location /static/ { alias D:/project/behavior_system/static/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }关键点在于：proxy_pass代理到Waitress监听的8000端口；location /static/直接让Nginx处理静态文件，不走Python后端。如果静态文件404，绝大多数情况是alias路径写错了，仔细检查路径最后一个斜杠。我在这个坑上至少帮人排查过十次，每次都花了很多时间。
部署完成后的访问流程是：浏览器请求Nginx 80端口，Nginx把非静态请求转发给Waitress，Waitress把请求交给Django应用处理，Django返回响应。静态资源由Nginx直接从磁盘读取返回，整个链路就通了。
4.3 远程调试的几种操作方式
毕设远程调试常见有两种场景：一种是自己的项目在本地，需要让导师或合作同学远程访问看看效果；另一种是你帮客户做完项目，对方需要远程调试和验收。针对这两种场景，我分别给一套可操作的方式。
本地服务对公网暴露的问题，我强烈推荐用内网穿透工具（如cpolar、ngrok、frp）。走一遍就能把本地8000端口映射成一个公网地址，其他人打开这个地址就能访问系统。我实际用下来，frp和cpolar在Windows上都很稳定，基本是零配置。要提醒一句：只把穿透工具用于开发和演示，不要在生产环境长期用，安全和稳定性都不适合，而且公网地址泄露后容易被人扫描攻击，演示完最好立刻关闭通道。
远程调试代码的话，用VS Code的Remote-SSH插件是最顺手的。服务器上装好SSH服务，本地VS Code安装Remote-SSH插件，连上服务器后就能像编辑本地代码一样改服务器上的项目。调试时下断点、看变量、跑终端命令，体验和本地开发基本一样。
我的调试建议是：先让项目在本地完整跑通，再部署到服务器，最后才开远程调试。三层分层排查，哪一层出了问题就单独处理，不要让几个步骤混在一起。经常有人把运行不了的问题归结为服务器环境问题，结果折腾一天发现是代码里少传了一个参数，白白浪费时间。
4.4 文档撰写与答辩准备
毕设项目不只是代码，文档和答辩同样重要。需要交付的材料一般包括：开题报告、中期检查、毕业论文、答辩PPT、演示视频。论文里核心要写清楚的章节是“系统分析与设计”，要把模块划分、数据库表结构、关键流程讲明白。
数据库设计的章节，不建议贴所有模型的代码，而是画ER图加数据字典。数据字典里说明每个字段的含义、类型、是否为空即可。行为分析和可视化部分，建议贴核心代码片段加效果截图，代码太长就只贴关键函数，让导师能看出你有实现能力就行。
答辩PPT的时间一般是10分钟，结构化安排建议是：选题背景1页，可行性分析1页，系统结构2页，技术难点2页，功能演示4页（附截图），总结与展望1页。重点在功能演示部分，截图要清晰，数据样本要足够，图表效果要饱满。导师如果问你“这个系统还有什么不足”，不要慌，如实说“网络行为数据依赖服务器端日志，覆盖面有限，后续可以结合客户端埋点增强采集精度”，这比硬撑着说“系统已经完美”要好得多。
5. 常见问题与排查技巧
5.1 静态文件加载失败（图片不显示/样式丢失）
这个问题的出现频率在所有Django问题里排第一。典型现象是你本地runserver时页面正常，部署到服务器后样式全部丢失，或者本地VSCode里写的img标签引用的图片显示不出来。
排查路径分三步：第一步，确认settings.py里有没有设STATIC_URL和STATICFILES_DIRS；第二步，确认模板里用了{% load static %}且图片地址是{% static 'img/xxx.png' %}；第三步，确认部署模式下有没有执行python manage.py collectstatic。这个命令会把所有App里的静态文件复制到一个统一目录，Nginx配置里指的就是这个目录。如果少了这一步，无论你怎么改配置文件，静态文件都是404。
模板中加载图片的正确写法是：
{% load static %} <img src="{% static 'img/avatar.png' %}" alt="头像">这里最隐蔽的坑是：STATIC_URL和STATIC_ROOT容易混淆。STATIC_URL是浏览器访问静态资源的URL前缀，比如/static/；STATIC_ROOT是执行collectstatic后文件存放的物理路径。Nginx alias要指向STATIC_ROOT这个目录，而不是项目根目录下的static目录。两个地方不匹配的问题，很多老手也会一时想不起来。
5.2 数据库迁移与查询对象删除的问题
Django开发中，Model的增删改查是日常高频操作。删除对象的方式有三种：filter(...).delete()、get(...).delete()和Queryset.delete()，区别在于前者是批量删除（返回删除条数），后两个是针对单一对象的操作。
有一种很常见的报错是DoesNotExist，出现的原因是用get()查询了一个不存在的记录，比如BehaviorRecord.objects.get(id=999)，系统会直接抛异常。实际写代码时，建议优先用filter().first()，查不到返回None，不会中断流程。群里见到的另一个高频问题是在delete()之后，外键关联的数据还在。这是因为没有设置级联删除，默认情况下Django会保护有外键关联的数据，报ProtectedError。如果你希望删除父记录时自动删除子记录，在ForeignKey的on_delete参数里用models.CASCADE。
5.3 ORM查询性能的N+1问题
行为分析系统的列表页要展示用户信息加行为记录时，很容易触发N+1查询。比如循环显示每条BehaviorRecord对应的用户名，如果用record.user.username的方式去拿，每条记录都会去查一次用户表，数据量到一万条以上时页面直接卡住。
解决办法是加select_related('user')，Django会通过JOIN一次性把用户信息查出来，内存里直接用，不会再发额外的SQL。这个优化往往能带来几千倍的性能提升，一行代码就解决：
records = BehaviorRecord.objects.select_related('user').filter(user_id=1)顺手再补一个观点：如果导师问“如何优化系统性能”，至少要从三个维度答。查询优化（select_related/prefetch_related、增加索引）、缓存方案（Django的cache框架里常用Redis）、前端优化（压缩静态文件、懒加载图片）。其中的前置条件是先把数据库层面做好，才是缓存的事。很多人的误区是上来就谈Redis，但库里连个索引都没建，等于光靠缓存扛压力，治标不治本。
5.4 部署到服务器后的报错排查
听说有人部署到服务器后访问首页白屏、或者返回502/500。这里有个排查顺序，按优先级从低到高排：先看Waitress服务有没有启动，再看Nginx的error.log，再看Django的日志或者DEBUG模式有没有被关掉。这三个地方，80%的问题都能定位。
生产环境关闭DEBUG后，Django默认不会处理静态文件（runserver开发阶段默认处理，Waitress不会），所以生产部署一定要配好Nginx静态文件路径和collectstatic流程。如果关闭DEBUG之后，错误页面变成空白了，那要让Waitress把捕获的异常写进日志文件，再用tail命令看日志。这一步放到文档里写清楚，答辩时遇到突发情况能快速定位，而不是在演示台上手忙脚乱。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
迁移时报no such table | 没有执行migrate或Makemigrations失败 | 依次执行python manage.py makemigrations、python manage.py migrate |
| 登录后访问接口返回403 | 角色权限装饰器校验不通过 | 检查UserProfile里该用户的role字段是否设置正确 |
| 图表加载空白 | 前端JS报错，或接口返回的是HTML而不是JSON | 打开浏览器F12，看Console和Network面板，确认接口状态码和返回内容 |
| 图片资源404 | STATIC配置或collectstatic缺失 | 检查STATIC_ROOT路径，执行collectstatic，检查Nginx alias路径 |
| 部署后首页502 | Waitress没有启动或端口不一致 | 确认waitress-serve监听端口和Nginx proxy_pass端口一致 |
| 查询列表页特别慢 | 缺少索引或N+1查询 | 联合索引加select_related优化 |
| 演示时数据库突然报错 | 可能之前误删了db文件，或迁移版本不一致 | 定期备份db.sqlite3，答辩前不要改动数据模型 |
6. 我在交付这个项目时积累的经验
前面讲了大量从零搭建的技术细节，最后再单独拎一个部分说点交付的事情。因为这类毕业设计项目，不仅是技术产物，更是一个包含源码、文档、安装部署、答疑维护的完整交付物。
承接这类项目时，我从来不把“运行起来”当成交付标准，而是把”换一台干净的电脑，按照我的部署文档也能跑起来”作为验收标准。这中间要做的事情是：把环境安装写入requirements.txt，把启动命令写成一个start.bat或start.sh脚本，把静态文件的收集过程和执行结果记录清楚。这样交付之后，不管对方本地用什么环境，照着文档一步步走，都能把系统跑起来，不会出现“在你机器上是好的，在我这里就不行”的情况。
如果你打算自己答辩，那么请在答辩前至少完整走一遍部署流程，从数据库初始化、创建管理员账号、启动服务到浏览器访问，每一步最好写个小笔记。很多同学答辩现场翻车，不是写得多差，而是上台前没有做最终检查。演练的时候我会要求自己做到一个标准：全程不看教程文档，能靠记忆把系统从零跑起来。能达到这个程度，现场演示基本稳了。
另外一个容易被忽略的点是对业务场景的“深度思考痕迹”的记录。比如我们做行为分析，分析结果出来之后要怎么用？辅导员的视角下，这个系统的核心价值是“识别异常行为趋势”：某个学生连续一周在深夜时段访问娱乐类网站，系统能不能自动生成提醒？这类逻辑也许不必在代码里全部实现，但在论文的展望章节和答辩提问环节，有这种思考会让导师觉得你确实理解了业务的价值，而不只是会调框架的API。
再说一个关于数据展示的经验：做行为分析的图表时，不要只做柱状图和折线图，要有“热力图”。24小时乘以7天的活跃度热力图，放在页面顶部，一眼就能看到学生在哪个时段最活跃、哪几天行为异常。这种图表的视觉冲击力非常强，答辩时往往是全场最亮眼的展示项。ECharts里用heatmap系列实现，配合visualMap组件调整颜色深浅，难度不高但效果拔群。
实际操作中，我做图表通常坚持“一个页面只放一张主图”的原则，而不是把所有图表堆在一个首页上。主图放趋势图，辅助信息用卡片展示数值指标，其余图表放到二级页面。这样界面清爽，演示节奏也好控制——你点开一个页面，讲清楚这张图说明了什么，比在一堆图里来回切换要有条理得多。
这个系统后续还可以继续扩展：接入真实的网络接口日志做更细的流量分析，加入行为异常预警（比如连续长时间使用），给前端换成Vue3做前后端分离，或者用Django Channels实现实时数据推送。方向很多，但对于毕设来说，先踏实把当前这一版做稳定、做完整、做好演示，就已经赢过大多数人了。
