企业官网建设流程全解析

做毕业设计最怕什么？不是技术难，项目复杂，而是选了一个又老又没营养的题目，比如“图书管理系统”“学生信息管理系统”，模板化严重，答辩时老师问两句就露馅。今天想分享的这套题目是个相当有代表性的方向：基于django的Bilibili青少年模式使用情况的数据分析系统。名字虽然长，核心其实就三个词——django、Bilibili、数据分析。它难得的点在于，选题有社会热度（青少年模式是平台方和监管方都在持续推进的机制），技术上有层次（从后端框架到数据清洗再到可视化全链路），而且实现起来不那么卷，只要逻辑清楚，工作量是实实在在可以看得见的。无论是想做个像样的毕设，还是想在企业项目里积累一些数据统计模块的经验，这套东西都值得拆开嚼一嚼。

我下面会把整个系统的设计思路、数据模型、功能实现、可视化方案和那些只有真正经手过一遍才会遇到的坑全部摊开来讲，尽量讲到一种“带着照着做就能落地”的程度。

1. 项目整体设计与选题价值

1.1 为什么这个选题比传统管理系统更有底气

先聊聊选题层面的东西，因为很多同学项目写着写着就卡死了，回头一看全是选题的时候埋的雷。

传统管理系统（图书、教务、超市进销存）本质上就是几个增删改查页面的排列组合，技术含量低，需求描述基本是十年前的产物，答辩时老师最常问的就是“你的系统解决了什么别人解决不了的问题”，答不上来就尴尬。而“基于django的Bilibili青少年模式使用情况的数据分析系统”天然自带三个加分项：

第一，数据源有故事。Bilibili是一个日活过亿的UGC视频社区，它的青少年模式是个真实存在且被持续讨论的机制，系统设计时可以向“未成年人内容过滤”这个社会议题靠拢，这是“需求来源”的最好背书。

第二，分析链路是完整闭环。不是简单的表单、报表，而是从“采集用户行为数据”到“特征加工”再到“可视化洞察”的完整链路，涉及的数据处理技术点是实打实的。

第三，django框架能够很好地承载这类应用。它的ORM、Admin、模板引擎、认证体系开箱即用，对毕业设计来说，与其用Flask那种“光着膀子干”的微框架硬撑业务逻辑，不如用django全家桶让系统结构更完整，更能撑起“设计”两个字的分量。

这个系统能做什么？一句话：监控和分析某一类用户（未成年人画像）在Bilibili平台上的内容消费行为模式，包括使用时段、视频类别偏好、观看时长分布、弹幕互动频率、搜索行为特征等。系统最终要输出的是“面向运营和管理者的决策数据”，也就是给平台做内容治理或者给家长提供使用建议时，有数据可依。

适合谁参考？如果你是2024届、2025届计算机相关专业的学生，正在为选题焦虑；或者你是想学习一个完整的django数据可视化项目怎么搭的初级开发者；再或者你只是在帮亲戚朋友找毕设方案的——都适用。

1.2 总体架构选型：为什么是django全家桶而不是微服务

架构上我的建议是不上微服务，不搞Redis缓存，不做消息队列，就用一个django项目打天下。

原因很简单：毕设的核心逻辑是“把数据分析清楚”，而不是“让系统承受高并发”。微服务那一套会让你陷入服务发现、网关配置、分布式事务的泥潭里，工作量爆炸但展示出来的部分又不容易让答辩老师快速理解。

推荐的分层是：

前端层：HTML + CSS + JavaScript + ECharts（图表） 控制层：django views（接收请求、调度数据分析任务） 业务层：service模块（封装核心统计分析算法） 数据层：django ORM + SQLite/MySQL

SQLite可以作为开发环境默认库，部署时切换成MySQL。django的ORM在这时候体现出了极大便利——你不需要写复杂的SQL join语句，数据的聚合、分组、过滤直接在Python层表达，改起来也快。

为什么要用ECharts而不是直接塞给前端一个表格？因为数据分析系统的灵魂在于“让人一眼看出规律”，ECharts的图表交互能力和组件丰富程度比Charts.js更成熟，而且中文文档对毕设作者友好得多。

1.3 影响范围与应用场景分析

不要小看这个系统的延展空间，往深了推，它能覆盖下面几个真实场景：

• 平台运营侧：分析青少年模式下不同内容品类的完播率、点赞率、搜索热词，帮助产品团队调整“青少年模式底栏推荐策略”。
• 内容治理侧：识别峰值时段（比如21-23点），反推内容审核人力排班是否需要跟着波动。
• 家长教育侧：输出“一周观看内容品类报表”，让家长不用翻手机也能直观知道孩子看了什么。

顺着这个思路做，你不会只交一个“课程作业”，而是可以宣称“这是一个具备产品化潜力的数据分析原型系统”。

2. 核心细节解析与数据模型设计

2.1 数据模型：怎么把Bilibili青少年模式的数据抽象成表

数据分析系统最关键的第一步是把业务行为翻译成数据表结构。这一步要做扎实，否则后面写统计逻辑时会反复改表结构。

我的设计里，一共三张核心表：

表一：用户基础信息表（Users） 这张表存储画像维度信息，注意不要存明文密码等敏感字段，在毕设场景下用django自带的User模型扩展一个Profile即可。扩展字段包括：年龄段、首次开启青少年模式时间、当前模式状态（普通/青少年）、所在省份、设备类型（移动端/PC/平板）。

表二：使用行为明细表（BehaviorRecord） 这是全系统的数据基础，记录每一次“行为动作”。字段设计如下：

id: 自增主键 user_id: 外键关联Users表 behavior_type: 行为类型（VIEW, SEARCH, LIKE, COMMENT, SHARE） content_category: 内容大类（知识、游戏、音乐、动画、影视、生活） video_duration: 视频总时长（秒） watch_duration: 实际观看时长（秒） is_completed: 是否看完（布尔型） trigger_time: 行为触发时间（datetime）

这里我要特别强调：behavior_type和content_category建议用整数枚举（0-5），不要直接存中文字符串。一是省空间，二是查询对比时效率更高，三是后续如果要扩展类型不用改表结构。大部分同学在这翻车，因为存了太多冗余信息，结果统计时被数据清洗折腾得头大。

表三：上下文状态表（ContextSnapshot）

这是容易被忽视但分析价值极高的一张表。数据分析系统如果想回答“青少年模式下，用户的观看行为是否发生了变化”，必须保留行为发生时的上下文状态。字段包括：是否处于青少年模式、当日累计使用时长、当前连续使用时长、上一次模式切换时间间隔。

为什么要专门存这个？因为同一个用户，在青少年模式和非青少年模式下，行为模式往往差异很大。比如普通模式下刷游戏视频能刷到凌晨，切到青少年模式后可能十分钟就退出了。如果不记录上下文状态，你会得出极不准确的结论。

2.2 关键设计决策：为什么把“状态”单独拆表

有人会问：这不就是一个字段的事吗，干嘛单拆一张表？我用亲身经历回答你：如果并在一张表里，每增加一个状态维度，你都要去改用户表，改完还要写迁移脚本，烦不说，还容易破坏已有数据。拆成ContextSnapshot表之后，场景快照独立演进，行为表和上下文表通过user_id和trigger_time关联，多个分析任务可以同时抽取不同时间段的快照，互不干扰。

此外，还有隐私合规的考量。青少年数据属于敏感个人信息，系统设计里就该把“最小化存储”体现出来——上下文表中不存具体用户，只存行为指纹ID，这是一种“设计即合规”的思路，在项目说明文档里写上这一点，答辩老师会高看一眼。

2.3 数据模拟与采集策略

这是必须诚实面对的问题。毕设阶段你无法拿到B站真实的青少年模式用户明细数据，也不可能自己大规模爬取用户行为，那么数据从哪来？

我的方案是写一个数据模拟脚本，在合理假设的前提下生成约1-3万条行为记录。具体参数遵循以下几点假设：

• 用户总量：500人（模拟一个中等规模测试社区）
• 男女比例：6:4
• 内容类别分布：知识类占比15%，游戏类占比30%，动画类占比20%，音乐类占比15%，影视类占比10%，生活类占比10%
• 观看时长与视频时长比值的正态分布：均值0.7，标准差0.2

这一步诚实地写进项目文档里，说明叫“基于蒙特卡洛模拟的样本数据生成”，不是你造假，而是你在无法获取商业数据的环境下用科学手段构造数据集，这个思路本身就有说明力。

不过我也建议系统预留“导入真实CSV数据”的入口，一旦后期拿到脱敏数据，可以直接替换模拟器。

3. 功能模块拆解与可视化实现

3.1 核心功能模块一：使用概况总览

数据看板首页，用卡片展示五个核心指标：今日活跃用户数、平均单次使用时长、青少年模式开启率、热门内容Top3、峰值时段。

这几个指标怎么算？

• 今日活跃用户数：BehaviorRecord.objects.filter(trigger_time__date=date.today()).values("user_id").distinct().count()
• 平均单次使用时长：先按(user_id, session_id)分组计算会话时长，再求平均值。session_id需要在写入行为数据时一并写入，可以在生成数据的脚本里用“连续行为间隔超过30分钟算一个新会话”的规则来定义。
• 青少年模式开启率：ContextSnapshot.objects.filter(is_teen_mode=True).count() * 1.0 / ContextSnapshot.objects.count()

这些指标单独看不难，但把它们整合到一张看板上，还要让图表联动，需要前后端配合好。前端我用ECharts的init方法创建实例，后端通过django的JsonResponse返回统计JSON，前端fetch拿到数据后setOption，完全够用。

3.2 核心功能模块二：时段规律分析

这是我最推荐你在答辩时重点展示的模块，因为它的分析结果有很强的故事性。

实现思路是把一天24小时切分成96个15分钟窗口，然后统计每个窗口内的行为事件密度（即每15分钟的行为触发次数）。用django ORM怎么写？

from django.db.models import Count from django.db.models.functions import TruncHour, TruncMinute results = ( BehaviorRecord.objects .filter(trigger_time__date=target_date) .annotate(hour=TruncHour("trigger_time")) .values("hour") .annotate(event_count=Count("id")) .order_by("hour") )

如果要精确到15分钟窗口，用TruncMinute配合分钟整除就能算出来：

from django.db.models import F from django.db.models.functions import Cast BehaviorRecord.objects.annotate( minute_part=ExtractMinute(F("trigger_time")) ).annotate( quarter=Cast((F("minute_part") / 15), output_field=IntegerField()) )

看到没有，django的ORM最迷人的地方就在这里——你不用写一行原生SQL，就能完成数据库端的分组聚合计算，性能也不错。

可视化层面，我会画一张双曲线图：一条是“青少年模式行为密度”，另一条是“普通模式行为密度”。两条曲线叠加，能很明显地看出切换模式后，用户的活跃时段如何发生位移。实际操作中我们发现，模拟数据里青少年模式在19-21点出现明显高峰，而普通模式在21-23点仍维持高位。这个发现可以引导出结论：“青少年模式有效降低了深夜使用行为的发生概率”，这就是分析的价值。

3.3 核心功能模块三：内容偏好画像

内容偏好画像背后的分析逻辑并不复杂：对用户的历史观看记录做聚合，统计每个内容类别的观看总时长和观看次数，再计算“偏好指数”。

这里需要引入一点信息论的思想。指数公式为：

偏好指数 = (某类别观看时长 / 总观看时长) / (某类别内容供给量 / 总内容供给量)

如果偏好指数大于1，说明该类别的消费份额超过了供给份额，用户存在明显偏好；小于1则说明需求相对低迷。这样算出来的“偏好”比单纯看观看时长Top1、Top2要科学得多，因为它剔除了“内容供给分布不均”的干扰。

数据输出格式大致如下：

{ "category": "知识", "watch_share": 0.28, "supply_share": 0.15, "preference_index": 1.87, "trend": "up" }

前端我建议用雷达图展现多类别偏好指数。为什么雷达图比柱状图好？因为雷达图可以同时展现多个维度的相对关系，“高维对比”一目了然，答辩老师一看就知道你考虑过可视化语义。

3.4 核心功能模块四：线性模型下的使用时长预测

这部分属于锦上添花，但能让你的系统含金量上一个台阶。

我用一个最简单的多元线性回归，预测“青少年模式下的用户单次使用时长”。特征变量取：当日累计使用时长、时段（上午、下午、晚上、深夜）、内容类别、后续是否发生搜索行为。

django集成机器学习的方式很直接：训练阶段用scikit-learn在本地生成模型参数，然后通过django的joblib加载模型文件进行预测。代码结构如下：

import joblib model = joblib.load("analysis/ml_models/duration_predictor.pkl") def predict_duration(request): feature_vector = [ float(request.GET.get("daily_total", 0)), float(request.GET.get("period_code", 0)), float(request.GET.get("category_code", 0)), float(request.GET.get("search_after", 0)) ] pred = model.predict([feature_vector])[0] return JsonResponse({"predicted_seconds": round(pred, 2)})

为什么选线性回归而不是决策树、随机森林？因为线性回归的可解释性在答辩时很加分。你可以说出每个特征的系数，比如“深夜时段的系数为负，说明深夜观看会缩短单次使用时长”，这种从系数反推业务含义的能力是黑盒模型给不了的。

4. 实操过程与核心环节实现

4.1 django项目初始化和App规划

环境准备阶段，我建议直接用conda建一个Python 3.10的虚拟环境，避免系统Python环境弄脏。然后：

conda create -n bili_analysis python=3.10 -y conda activate bili_analysis pip install django==4.2 scikit-learn pandas joblib django-admin startproject bili_analysis_system cd bili_analysis_system python manage.py startapp users python manage.py startapp behavior python manage.py startapp analysis python manage.py startapp dashboard

App划分的逻辑很清楚：users管用户画像，behavior管行为数据录入与查询，analysis管统计分析业务，dashboard管看板和图表接口。混在一个App里会越到后面越乱，职责分离是不可省的一步。

项目跑起来后，先去settings.py注册这些App：

INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'users', 'behavior', 'analysis', 'dashboard', ]

4.2 models.py表结构落地

以behavior这个App为例，我给的models.py核心代码如下：

from django.db import models from django.contrib.auth.models import User class BehaviorRecord(models.Model): BEHAVIOR_TYPES = [ (0, "VIEW"), (1, "SEARCH"), (2, "LIKE"), (3, "COMMENT"), (4, "SHARE"), (5, "BLOCK"), ] CATEGORY_TYPES = [ (0, "知识"), (1, "游戏"), (2, "动画"), (3, "音乐"), (4, "影视"), (5, "生活"), ] user = models.ForeignKey(User, on_delete=models.CASCADE, related_name="behavior_records") behavior_type = models.IntegerField(choices=BEHAVIOR_TYPES) content_category = models.IntegerField(choices=CATEGORY_TYPES) video_duration = models.IntegerField(help_text="视频总时长（秒）") watch_duration = models.IntegerField(help_text="实际观看时长（秒）") is_completed = models.BooleanField(default=False) trigger_time = models.DateTimeField(db_index=True) class Meta: ordering = ["-trigger_time"] indexes = [ models.Index(fields=["user", "trigger_time"]), models.Index(fields=["content_category", "trigger_time"]), ] class ContextSnapshot(models.Model): record = models.OneToOneField(BehaviorRecord, on_delete=models.CASCADE, related_name="context") is_teen_mode = models.BooleanField(default=True) daily_usage_seconds = models.IntegerField() continuous_usage_seconds = models.IntegerField() last_mode_change_interval = models.IntegerField()

两个细节你务必注意：

• 把trigger_time加上db_index，后面大量按时间范围过滤的查询会快很多。数据量过万后，没索引的datetime字段查询会肉眼可见地慢。
• 双字段联合索引(user, trigger_time)能有效加速“查询某个用户一段时间的行为记录”这种高频操作。

写完后执行python manage.py makemigrations和python manage.py migrate，把表结构同步到数据库。

4.3 数据生成脚本的编写要点

我专门写了一个generate_mock_data.py脚本放在项目根目录，通过python manage.py shell < generate_mock_data.py方式运行。

脚本的核心逻辑是：

import random from datetime import datetime, timedelta from users.models import UserProfile from behavior.models import BehaviorRecord, ContextSnapshot CATEGORY_WEIGHTS = [0.15, 0.30, 0.20, 0.15, 0.10, 0.10] BEHAVIOR_WEIGHTS = [0.70, 0.05, 0.10, 0.05, 0.05, 0.05] def gen_user(): return User.objects.create(username=f"mock_user_{random.randint(1000,9999)}") def gen_record(user, ts, is_teen_mode): category = random.choices(range(6), weights=CATEGORY_WEIGHTS)[0] behavior_type = random.choices(range(6), weights=BEHAVIOR_WEIGHTS)[0] video_duration = random.randint(60, 1800) # 青少年模式下完播率更高，观看时长占比也略高 if is_teen_mode: watch_duration = int(video_duration * min(1.0, random.gauss(0.8, 0.15))) is_completed = random.random() < 0.75 else: watch_duration = int(video_duration * min(1.0, random.gauss(0.55, 0.2))) is_completed = random.random() < 0.35 return BehaviorRecord(...)

留意青少年模式下参数为何不同——模拟数据不瞎造，要建立在行为学假设上。青少年模式下内容经过筛选，更符合其认知水平，因此完播率和观看完成度理论上应该高于普通模式下的随机浏览，这跟现实中青少年模式“精选内容”的特征一致。这种“有依据的假设”贯穿整个生成过程，数据分布才经得起统计检验。

生成完数据后，跑几条BehaviorRecord.objects.count()、BehaviorRecord.objects.filter(trigger_time__date=...).count()去验证数据落库情况。这里遇到过一个大坑：批量生成时没有关闭django的auto_now属性，导致trigger_time被自动覆盖为写入时刻，所有记录的时间戳都是一样的。解决办法是生成记录时显式赋值trigger_time=ts，并保证auto_now_add=False。

4.4 数据看板接口的实现

在dashboard这个App中，我按“指标卡片接口”、“趋势图接口”、“雷达图接口”来拆分视图函数，不搞一个大而全的接口。每个视图只做一件事：

from django.http import JsonResponse from django.db.models import Count, Sum from django.utils import timezone from behavior.models import BehaviorRecord, ContextSnapshot def overview_metrics(request): today = timezone.localdate() active_users = ( BehaviorRecord.objects .filter(trigger_time__date=today) .values("user_id") .distinct() .count() ) total_records = BehaviorRecord.objects.count() avg_watch = BehaviorRecord.objects.aggregate(avg_dur=Sum("watch_duration") / Count("id")) teen_rate = ( ContextSnapshot.objects.filter(is_teen_mode=True).count() * 100.0 / ContextSnapshot.objects.count() ) return JsonResponse({ "active_users": active_users, "total_records": total_records, "avg_watch_duration": round(avg_watch["avg_dur"], 2), "teen_mode_rate": round(teen_rate, 2), })

口径一致性问题我踩过坑。比如“今日活跃用户数”，如果行为表里没有当天记录但用户登录过系统，算不算活跃？这里我明确口径：活跃 = 当天至少触发过一条行为记录的用户，并在接口注释里写清楚。口径不一致导致前后端数据对不上，是开发调试中最浪费时间的问题之一。

前端模板用一个简易的dashboard.html，通过fetch获取JSON渲染。

fetch("/dashboard/api/overview_metrics/") .then(response => response.json()) .then(data => { document.getElementById("activeUsers").innerText = data.active_users; document.getElementById("avgWatchDuration").innerText = data.avg_watch_duration + "s"; document.getElementById("teenModeRate").innerText = data.teen_mode_rate + "%"; });

4.5 可视化图表的前端集成

图表部分，我以最常用的ECharts折线图为例：

// 引入 ECharts 主模块 import * as echarts from 'echarts'; let chart = echarts.init(document.getElementById("trendChart")); fetch("/dashboard/api/hourly_trend/?date=2025-01-10") .then(res => res.json()) .then(data => { chart.setOption({ tooltip: { trigger: "axis" }, legend: { data: ["青少年模式", "普通模式"] }, xAxis: { type: "category", data: data.hours }, yAxis: { type: "value" }, series: [ { name: "青少年模式", type: "line", smooth: true, data: data.teen_counts }, { name: "普通模式", type: "line", smooth: true, data: data.normal_counts } ] }); });

这部分要测试的点在于ECharts的响应式重绘，tab切换或者窗口缩放时，图表得调用chart.resize()，否则会出现留白或挤压。我见过好多项目答辩现场演示切tab后图表变形，这种细节最影响评价。

4.6 django Admin后台的二次定制

django自带Admin是个宝，很多同学只用默认样式，没有发光。青少年模式使用情况分析系统的数据管理后台，我推荐花半小时做简单定制：

在admin.py中：

@admin.register(BehaviorRecord) class BehaviorRecordAdmin(admin.ModelAdmin): list_display = ("id", "user", "behavior_type", "content_category", "watch_duration", "is_completed", "trigger_time") list_filter = ("behavior_type", "content_category", "is_completed", "trigger_time") search_fields = ("user__username",) date_hierarchy = "trigger_time"

date_hierarchy是一个非常实用的钻取工具，自动生成“年-月-日”的下钻链接，筛选数据效率暴增。这一步做完，系统就有了一个可用的后台管理界面，也算是毕设文档里的一处亮点。

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

5.1 ORM查询性能坑：N+1查询问题

刚开始统计分析时，我写了类似下面的代码：

for record in BehaviorRecord.objects.filter(user_id=1): print(record.context.is_teen_mode)

每访问一个关联对象，数据库就执行一次新的查询，5000条记录下来，卡到页面超时。优化方式是使用select_related：

records = BehaviorRecord.objects.filter(user_id=1).select_related("context")

这会把两张表的JOIN结果一次性加载到内存，查询次数从N+1降到1。类似的还有prefetch_related，适用于多对多和反向外键。这类优化技巧在项目性能优化章节里写一段，能有效体现实操深度。

5.2 动态字段排序导致的注入风险

在使用表头排序功能时，如果不加过滤直接把用户传入的排序字段拼进order_by，会有产生异常的风险：

sort_field = request.GET.get("sort", "trigger_time") records = BehaviorRecord.objects.order_by(sort_field)

排序字段白名单一定要限制：

ALLOWED_SORT = {"time": "trigger_time", "duration": "watch_duration", "category": "content_category"} sort_key = ALLOWED_SORT.get(request.GET.get("sort"), "trigger_time") records = BehaviorRecord.objects.order_by(sort_key)

虽然这不是严格的SQL注入（django ORM的参数化机制会保护一部分），但动态字段名不校验，传个不存在的字段可能直接抛异常，浪费排查时间。

5.3 数据可视化时的NaN值处理

统计均值时，如果数据库中某类别的记录数为0，聚合结果会出现None除以0的情况，前端直接显示NaN，图表断线。我的处理方式是在视图层统一兜底：

def safe_avg(dividend, divisor): return round(dividend / divisor, 2) if divisor else 0

这个“数据兜底意识”很关键，写接口时不要假设数据永远是完整的，要对缺失情况有预案。

5.4 青少年模式判断的口径不一问题

“青少年模式开启率”到底是算“当前处于模式的用户数占比”还是“每次行为发生时处于模式的记录占比”？两种算法结果可能差出10个百分点。查阅了不少公开资料后，我采用按“记录占比”算，因为这个口径更能反应用户真实使用过程中的模式覆盖情况。

所有涉及比例计算的接口统一萃取成一个工具函数，避免dashboard和mobile接口各算一遍，数值不一致。

5.5 时间分组查询的时区陷阱

django的USE_TZ = True配置下，数据库存的是UTC时间，而前端展示需要北京时间。如果直接按trigger_time__hour分组，你会发现“深夜高峰”被记到了前一天下午，前后端数据完全对不上。

建议做法是：

from django.db.models.functions import TruncHour from django.utils import timezone from datetime import timedelta local_tz = timezone.get_current_timezone() BehaviorRecord.objects.annotate( local_hour=TruncHour(trigger_time + timedelta(hours=8)) )

这里我图省事直接加了8小时，严谨做法是用django.utils.timezone.localtime()转换，但在聚合QuerySet中操作起来更繁琐，直接加固定偏移对北京时间环境下的演示项目可以接受。这些时间处理的细节如果没经验，能卡你两三个小时。

6. 项目复盘与可扩展方向

这套系统完整做下来，本质上你已经把django从模型设计到视图编写，从数据分析到可视化呈现，从性能优化到安全控制全过了一遍，这些东西可以原封不动地移植到企业里的运营数据分析后台。

我个人在实际操作中的体会是：毕业设计项目代码量不重要，重要的是让每个模块都“自己觉得经得起追问”。比如“为什么用线性回归”不能答“因为别人都用”，要能从可解释性、复杂度、适合小数据量三个维度说出理由；“为什么选ECharts”不能只说“好看”，要说出ECharts对时空数据可视化的生态优势。这些“为什么”累积起来，就是一个有深度的项目。

最后再分享一个小技巧：项目说明文档里，建议画一张“用户使用流程图”——从用户进入青少年模式，到内容推荐，到行为触发，再到数据采集、分析、展示的整体时序。这张图不必用多高级的工具画，逻辑清楚比画得精美重要得多，因为答辩老师80%的问题都会顺着这张图展开。

如果时间充裕，可以再往上扩展两个方向：一个是接入django-channels做WebSocket实时推送，让看板数据每隔几秒自动刷新，不用手动点浏览器刷新；另一个是加一个PDF报表导出功能，生成每日数据分析报告，这在实际工作中是真实需求。

这个选题最终的落点是：谁看了你的系统都能信服“数据分析不是炫技，是把数据变成行动依据”。能做到这一点，你的毕设就成功了。