基于Django的Bilibili青少年模式使用情况数据分析系统

最近后台私信里好几个同学都在问同一个题目：列表里写着“基于Django的Bilibili青少年模式使用情况的数据分析系统”，但网页标题却顶着“Java毕设选题推荐”的标签，还附带“源码、mysql、文档、调试+代码讲解+全bao”。说实话，这个标题的第一眼就暴露了一个很典型的问题——Django是Python生态的Web框架，和Java没有半点关系。但抛开标签的错位，这个题目本身我是推荐的：B站青少年模式是平台防沉迷机制的核心功能，围绕它做使用情况的数据分析，业务场景真实、技术链路完整，从数据采集、MySQL存储、统计建模到可视化展示全都能覆盖，放在计算机专业的毕设和课设里都属于“好写、好过、好答辩”的类型。下面我把这个题目从需求拆解到表结构设计、从爬虫脚本到常见报错，完整过一遍。

1. 选题拆解与技术选型思路

1.1 先拆穿一个坑：Java标签与Django实现之间的错位

很多学生在选题时会被标题里的“Java”三个字误导，以为这是一个Java项目，下载源码后才发现全是Python文件。这种事在毕设资源平台上太常见了，标题负责蹭搜索流量，内容实际是另一套技术栈。Django是Python最成熟的Web框架之一，自带的ORM、Admin后台、模板系统和用户认证模块，能帮人省下大量重复开发时间。如果学校题目明确要求Java技术栈，直接拿这个源码交差是很危险的，建议先跟导师确认清楚。

反过来，如果导师给的方向只是“青少年模式使用情况数据分析”，并没有限定语言，那用Django来实现是一个非常舒服的选择。Python本身在数据分析领域有天然优势，pandas、SnowNLP、jieba这些库都是现成的，后端逻辑和数据分析代码可以写在同一套项目里，不需要跨语言传递数据。还有一个更聪明的用法：哪怕学校要求Java，你也可以把这套题当成“需求说明书”，用Spring Boot重写业务接口，MySQL表结构可以直接复用。

1.2 为什么这个题目值得做进毕设

“视频平台青少年模式”是近几年的热门方向，B站又是国内用户量最大的中长视频平台之一，拿它做数据分析样本，数据来源明确，业务意义清晰。分析青少年模式的开启情况、使用时长、内容偏好和评论情感，能看到用户对防沉迷功能的真实反馈，这个角度在答辩时非常容易讲出价值。

从技术训练角度看，这套题覆盖的知识面也很完整：爬虫采集公开数据、MySQL建表与查询优化、Django后端的API设计、前端ECharts图表渲染、文本情感分析算法。一个项目把本科阶段最常见的几项技能全部串联起来，对找工作时的项目经验描述也有帮助。另外，这类数据分析系统不像纯管理系统那样功能单薄，也不像算法研究那样对数学基础要求很高，属于权衡之后最适合大多数学生完成度的选择。

1.3 技术选型背后的取舍理由

• Django 4.x + Django REST Framework：后端主框架。Django自带的ORM把MySQL操作封装成Python对象，写查询时基本不用碰原生SQL；DRF负责输出标准JSON接口，方便前端渲染。
• MySQL 8.0：关系型数据库。业务数据之间的关系（用户、视频、评论、使用记录）很清晰，适合建多张表管理；MySQL的JSON字段还可以存采集时的原始数据，给后期扩展留余地。
• requests + BeautifulSoup：数据采集层工具。B站页面公开接口返回的JSON结构相对稳定，requests拿到数据后用json库解析即可。
• pandas + NumPy：数据分析标配。从数据库读出来的是二维表，用pandas做分组统计、透视表、时间序列聚合非常顺手。
• SnowNLP / jieba：文本情感分析。处理“青少年模式体验很好”“广告太多不想用”这类评论，打正负情感分数。
• ECharts：可视化。纯前端图表库，柱状图、折线图、饼图、热力图都能画，API简单。

这套组合的核心逻辑是“各取所长”：Django管业务与数据流，pandas管分析计算，ECharts管展示。不使用Django模板强行渲染复杂图表，也不让后端去写前端逻辑，前后端职责分离，调试时能省很多事。

1.4 功能模块划分

• 用户与权限模块：Django自带认证体系，分管理员和普通访客，管理员负责数据维护和系统配置。
• 数据采集模块：定时或手动触发爬虫脚本，抓取公开视频信息、评论数据和青少年模式相关内容。
• 数据清洗入库模块：对采集到的原始JSON做去重、字段对齐、类型转换，批量写入MySQL。
• 统计分析模块：按时间、分类、情感倾向等维度聚合，生成统计结果。
• 可视化展示模块：调用统计接口，用ECharts渲染趋势图、占比图、排行图。
• 报告导出模块：把统计数据导出为Excel报表，便于提交给导师查看。

2. 业务需求与数据分析核心维度

2.1 数据采集层：到底要采集什么数据

很多同学第一反应是“爬B站所有视频”，这个思路需要马上纠正。毕设项目的时间有限，数据量也不需要做到全量，关键是采集的数据能支撑分析目标。推荐聚焦这几类公开数据：视频的基础信息（BVID、标题、分类、播放量、点赞数、发布时间）、视频相关评论、青少年模式下推荐内容池的标签分布。我实际做的时候，是先在B站搜索“青少年模式”相关的视频和话题，拿到一批样本后不断扩展关联视频的ID列表，再逐个抓详情和评论。

采集方式需要注意合规性。优先使用官方公开接口，请求频率控制在低频，设置合理的User-Agent，只抓公开非隐私数据，并在文档中注明“数据仅供学术研究使用，已做脱敏处理”。不要碰用户个人隐私信息，也不要大规模高并发请求，这类问题在毕业论文查重和答辩时都会被问到，提前在文档里写好数据合规说明，是很稳妥的做法。

2.2 必不可少的数据存储层

数据层不建议直接用CSV文件撑完全场，虽然pandas读CSV很方便，但毕设评委会问“为什么不用数据库”。用MySQL建表，既能体现数据库设计能力，也方便后续做SQL查询题。核心表至少需要：用户表、视频信息表、分类表、使用记录表、评论表。使用记录表用来存“用户在什么时间段使用了青少年模式、单次时长多少”，这是后续分析使用趋势的基础；评论表存采集到的文本和情感得分。表结构设计我会在第三章详细展开。

2.3 数据分析层：六个核心分析维度

1. 青少年模式开启率：在采集样本中，明确使用青少年模式的会话占比，衡量功能渗透情况。
2. 使用时长分布：统计单次使用时长、每日总时长的均值与中位数，反映用户粘性。
3. 时段活跃度：按小时聚合使用记录，找出最活跃的时间窗口。
4. 内容分类偏好：统计青少年模式下观看视频的分类占比，绘制饼图和柱状图。
5. 评论文本情感分析：对评论内容打情感分，统计正面、中性、负面占比。
6. 使用趋势变化：按周/月聚合数据，观察开启率和时长的变化趋势，判断功能是否被持续使用。

这六个维度覆盖了“渗透、粘性、偏好、反馈、趋势”五个方向，足够撑起一篇毕业设计论文的分析章节。实际编码时，每个维度对应一个统计函数和一张图表，结构非常清晰。

2.4 可视化展示层：让数据有说服力

可视化部分我建议使用ECharts曲线图展示使用趋势，饼图展示分类占比，柱状图展示时段活跃度，情感分析结果用堆叠条形图或仪表盘展示。前端页面不需要做得多花哨，三个页面就够：数据总览首页、详细分析页、数据管理页。首页放核心指标卡片和趋势折线图，分析页放维度和图表联动，管理页展示原始数据和删除/刷新按钮。图表的数据全部通过后端JSON接口下发，前端用AJAX加载，这样后端统计逻辑改动时前端不必跟着改。

3. 数据库设计与关键表结构详解

3.1 实体关系设计

数据库围绕五个核心实体展开：用户、视频、分类、使用记录、评论。一个用户对应多条使用记录，一条记录属于一个分类；一个视频对应多条评论，一个视频归属于一个分类。用户表可以直接复用Django的auth_user，也可以自定义user_profile表存年龄、性别等脱敏字段。关系上不需要物理外键约束，Django的ORM通过模型间ForeignKey关系就能做关联查询，既保留了数据完整性控制，又避免了批量插入时机票外键导致的性能问题。

3.2 核心表字段设计

使用记录表（analysis_usage_record）是最重要的一张表，核心字段如下：

视频信息表（analysis_video_info）用于存采集到的视频数据：

评论表（analysis_comment_info）需要保留文本内容和情感分数：

3.3 字段类型与索引选择的一些心得

第一点，字符集必须用utf8mb4。B站评论里经常出现emoji，用utf8会直接报编码错误或者写入乱码。创建数据库时执行CREATE DATABASE bilibili_analysis DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;可以避免后面一大串问题。第二点，使用记录表一定要在start_time字段上加索引，因为趋势统计基本都是按时间段GROUP BY，没索引的时候随着数据量增加查询会越来越慢。第三点，bvid字段要建唯一索引，采集脚本反复跑时，用ON DUPLICATE KEY UPDATE实现增量更新，避免数据重复。第四点，避免在Python循环中逐条INSERT，一次批量插入1000条，commit一次，入库时间能缩短一个数量级。

4. 实操过程与关键环节实现

4.1 环境搭建与项目初始化

Django项目的第一步是创建虚拟环境，最好每个毕设单独用一个环境，不要和电脑上的其他项目混装依赖。Windows环境演示一套完整命令：

python -m venv venv venv\Scripts\activate pip install django==4.2 mysqlclient pandas requests beautifulsoup4 djangorestframework django-admin startproject bilibili_analysis cd bilibili_analysis python manage.py startapp analysis

如果mysqlclient安装失败，Windows下通常需要先安装Microsoft C++ Build Tools，或者改用纯Python的pymysql。改成pymysql时，在项目目录的__init__.py里加入：

import pymysql pymysql.install_as_MySQLdb()

这样Django就能通过MySQLdb接口操作MySQL。这个替代方案在处理毕设项目时非常实用，新手不用去折腾C++编译工具链。

4.2 MySQL数据库与Django配置

进入settings.py，把默认SQLite配置替换成MySQL。推荐配置如下：

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'bilibili_analysis', 'USER': 'root', 'PASSWORD': '123456', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }

注意：必须先手动在MySQL里创建好bilibili_analysis这个空库，Django不会自动建库，只会在已有库中建表。创建完后依次执行：

python manage.py makemigrations python manage.py migrate python manage.py createsuperuser

启动开发服务器：

python manage.py runserver

浏览器访问http://127.0.0.1:8000/admin，用刚创建的管理员账号登录Django自带后台。项目能跑通Admin后台，说明环境已经整体打通。

4.3 数据采集脚本的编写思路

采集模块我用requests请求B站公开接口。核心代码如下：

import requests import time import random headers = { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36', 'Referer': 'https://www.bilibili.com/', } def fetch_video_info(bvid): url = 'https://api.bilibili.com/x/web-interface/view' params = {'bvid': bvid} try: resp = requests.get(url, params=params, headers=headers, timeout=5) if resp.status_code == 200: data = resp.json().get('data', {}) return { 'bvid': data.get('bvid'), 'title': data.get('title'), 'category_id': data.get('tid'), 'play_count': data.get('stat', {}).get('view'), 'like_count': data.get('stat', {}).get('like'), 'comment_count': data.get('stat', {}).get('comment'), 'publish_time': data.get('pubdate'), } except Exception as e: print(f'采集失败: {bvid}, 错误: {e}') return None

这只是演示核心逻辑，实际采集时还需要加上“从搜索接口拿BVID列表、逐条抓取详情”的两段式流程。最容易被忽略的是请求间隔，连续快速请求很容易触发风控。我在脚本中加入了随机延时，每次请求之间sleep 1到3秒，并且在控制台打印进度，方便观察跑了多少条。

4.4 数据清洗与批量入库

采集到的数据不能直接写入表，需要先清洗：空字段填充默认值、发布时间时间戳转成datetime类型、评论内容去除多余换行。清洗后的数据推荐用Django ORM的bulk_create批量插入：

from analysis.models import VideoInfo video_objs = [VideoInfo(**item) for item in cleaned_data] VideoInfo.objects.bulk_create(video_objs, batch_size=500)

批量插入比循环create快得多，尤其是采集量到几千条以后，差异非常明显。如果采集脚本重复运行，建议配合update_or_create或者先在代码里做去重，避免主键冲突报错。

4.5 核心统计接口实现

数据分析统计主要靠Django ORM聚合查询。比如统计不同分类的播放量占比：

from django.db.models import Sum from analysis.models import VideoInfo from analysis.serializers import CategoryStatSerializer def category_stat(request): queryset = VideoInfo.objects.values('category_id').annotate( total_play=Sum('play_count') ).order_by('-total_play')[:10] data = list(queryset) return JsonResponse({'code': 200, 'data': data})

这段代码返回一个按分类汇总播放量的JSON数组，前端拿到之后，直接传给ECharts的饼图就能渲染。时段活跃度、趋势统计也都是类似的GROUP BY聚合，使用记录表加好索引之后，几万条数据查询性能完全扛得住。

情感分析模块，我调用SnowNLP对评论做打分：

from snownlp import SnowNLP def analyze_sentiment(text): s = SnowNLP(text) return s.sentiments # 0到1之间的情感倾向值

每条评论得到情感分后，按0.35以下为负面、0.35到0.65为中性、0.65以上为正面分桶统计，最后输出情感分布图数据。整体流程不复杂，但作为一个算法亮点放在论文里很有竞争力。

4.6 可视化页面实现

前端我采用“Django模板 + 原生JavaScript + ECharts”的方案。在模板里引入ECharts的CDN，页面加载完成后用fetch请求统计接口，拿到JSON后初始化图表。不用Vue或React，因为毕设阶段讲清楚原生实现反而让老师觉得基本功扎实。总览页布局是顶部四个指标卡片（总视频数、评论总数、总使用时长、平均情感得分），下面放一个使用趋势折线图和一个分类占比饼图。管理页直接用Django Admin替代，不需要额外写增删改查页面，这是Django框架带来的最大红利。

4.7 项目运行调试的正确顺序

我第一次跑通整套项目时，顺序是：先建数据库和表，再用Admin确认模型没问题，然后单独跑爬虫脚本，把数据落到MySQL，接着调统计接口，最后写前端页面。很多同学喜欢直接从页面开始，结果页面打不开时根本分不清问题在后端还是前端。按“环境→建表→数据→接口→页面”的顺序来，每一步都能验证，出错时排查范围会小很多。

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

5.1 MySQL连接与配置问题

报错error 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'非常高频，Linux环境下基本是因为MySQL服务没启动，执行systemctl start mysqld或systemctl start mysql即可；Windows环境则去“服务”管理器确认MySQL服务是否在运行，开机是否未自动启动。另一个高频问题是MySQL 8默认的SSL认证导致连接失败，报错里能看到ssl相关字样。解决方式是在Django数据库配置的OPTIONS里关闭SSL，或者在Navicat连接时把SSL选项改为“不使用”。如果用Navicat连不上但命令行能连上，多半就是SSL配置不一致，检查一下客户端的协议是第一步。

Navicat本身只是可视化工具，不建议去搜所谓的“破解版”，直接用社区版或JetBrains DataGrip就够用了。很多学生在数据库可视化工具上花的时间比项目本身还多，完全没有必要。

5.2 Django与数据库交互问题

Django迁移时报“Table 'xxx' already exists”，多数情形是自己手动在数据库里建过表，与Django的迁移记录不一致。最简单的解决思路：如果是开发初期，直接删库重建，再执行makemigrations和migrate；如果已有数据不想丢，则需要把django_migrations表中的相关记录手动对齐。

关于mysqlclient安装失败的问题，前面已经提过，Windows优先尝试安装Visual C++ Build Tools，或者改用pymysql方案。Django中的查询与删除对象操作，常用写法如下：

# 查询单条删除 record = UsageRecord.objects.filter(id=1).first() if record: record.delete() # 批量删除 UsageRecord.objects.filter(duration_minutes__lt=0).delete()

如果用Q对象组合条件时不小心漏了括号，会查出一堆意料之外的数据，建议先在Django shell里打印query属性检查生成的SQL，再真正执行删除。

Cookie设置Token这个问题也有很多同学问，做登录模块时在响应中设置token即可：

response = JsonResponse({'code': 200, 'msg': '登录成功'}) response.set_cookie('token', token, max_age=3600, httponly=True)

前端后续请求带上这个Cookie，后端通过request.COOKIES读取。如果使用DRF，可以换成JWT方案，逻辑更标准，但毕设里用Cookie已经足够。

5.3 数据采集与中文乱码问题

中文乱码的根源多半是字符集不统一。数据库表是utf8mb4，Django连接字符集也是utf8mb4，HTML页面头部声明charset=utf-8，这三处必须一致才能彻底解决。采集到的JSON文件如果出现中文乱码，在open文件时显式指定encoding='utf-8'，不要依赖系统默认编码。pandas读取Excel时如果中文路径报错，可以将文件先复制到英文路径下再处理，或者用openpyxl引擎指定参数绕过路径解析问题。

反爬方面，遇到返回错误或验证码时，排查顺序是：User-Agent是否缺失、请求频率是否过高、是否缺少Referer头。把随机延时调到2秒以上，加入随机UA池，大多数风控都能绕开。这个项目的数据量不需要很大，宁可慢一点，保证数据质量稳定。

5.4 运行期性能与部署问题

当使用记录表数据量达到几万条后，Django默认查询会把所有结果一次性加载到内存，页面会变得奇慢。此时有两种处理思路：一是直接在数据库层面完成聚合，只把聚合结果传到Python；二是给查询结果分页。我在统计接口中直接在ORM里GROUP BY，返回前Top10或前50条，前端渲染时数据量很小。

部署环节，本地调试用runserver没问题，但交付演示时若需要正式环境，推荐Nginx + uWSGI + MySQL的组合。Django的静态文件（CSS、JS、图片）通过python manage.py collectstatic收集到指定目录，Nginx直接提供静态文件服务，动态请求转发给uWSGI。整个部署流程我在另一个项目里写过详细文章，这里只提醒一个坑：DEBUG必须设为False，否则静态文件404的同时还会暴露大量调试信息，答辩演示时非常难看。

6. 这套资料包的完整度评估与扩展方向

6.1 一份完整毕设资料包应该包含什么

标题里的“源码、mysql、文档、调试+代码讲解+全bao”，其实就是当前毕设市场上常见的“全套服务”配置。拿到手应该核对这几项：源码能否本地跑通运行、SQL脚本是否能直接导入MySQL、设计文档是否覆盖开题/中期/结题各阶段、演示视频是否与源码版本一致、代码讲解是否覆盖核心模块。我见过不少例子，学生下载资料包后发现文档和代码对不上，版本混乱，最后只能自己从头排错。所以拿到资料包第一件事不是看视频，而是按README文档从头搭环境，把项目跑起来，再逐模块对照文档核对。

如果资料包里有一条龙服务，确实能帮学生节省不少时间，但切忌完全不动脑。答辩时老师随便问一个“使用记录表的主键设计为什么用BIGINT”或者“情感得分是怎么归一化的”，如果答不上来，反而比没有资料包更尴尬。正确姿势是：把核心代码逐行读懂，改掉几个字段和参数，让项目成为“你自己的版本”。

6.2 答辩准备与功能扩展方向

答辩准备三条主线：项目背景与价值、技术实现与创新点、数据与结论的解读。同样一个系统，能把“青少年模式使用趋势分析”讲出有业务含义的结论，比单纯说“我用了Django和MySQL”得分高得多。

功能扩展有两个方向很讨巧。一个是加入预测功能，比如基于历史使用时长数据，用线性回归或随机森林预测下一周的开启率变化，把简单的统计系统升级为“分析与预测系统”。另一个是加入自动化采集调度，使用Django的定时任务或系统定时任务，让爬虫每天自动抓取增量数据并刷新统计结果。这两个扩展都很容易落地，而且答辩时能明显提升项目的技术深度。

青少年模式相关的数据本身就是持续增长的，把采集任务挂起来跑半个月，积累下来的历史数据会让趋势分析更有说服力。如果时间充裕，我建议在完成基础功能后优先做自动采集，数据量上来了，后面写论文时能用的素材也更多。

最后分享一点个人实操体会

我帮人排查过不少类似项目的运行问题，踩过最多的坑往往不在代码本身，而在环境配置和版本兼容。拿到任何一套源码，先别急着改业务，把Django、MySQL、Python三者的版本固定下来，用虚拟环境安装依赖，能少走一半弯路。

还有一个很实在的建议：数据分析类毕设的核心是“分析结论”，不是“页面好看”。界面不用太炫，但每个图表旁边都应该有一段文字说明“这个数据说明了什么、对平台有什么建议”。这套内容写进论文之后，导师会觉得你真正理解了数据，而不是只会调用统计函数。

Bilibili青少年模式使用情况这个题目的可挖掘深度比想象中要大，如果你后续还想扩展，完全可以把它做成不同平台青少年模式的对比分析，也可以剥离开B站，只做通用的“视频平台内容治理数据分析系统”。先把当前这套流程跑通，后面怎么延展都顺理成章。