基于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对象写查询时基本不用碰原生SQLDRF负责输出标准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 数据分析层六个核心分析维度青少年模式开启率在采集样本中明确使用青少年模式的会话占比衡量功能渗透情况。使用时长分布统计单次使用时长、每日总时长的均值与中位数反映用户粘性。时段活跃度按小时聚合使用记录找出最活跃的时间窗口。内容分类偏好统计青少年模式下观看视频的分类占比绘制饼图和柱状图。评论文本情感分析对评论内容打情感分统计正面、中性、负面占比。使用趋势变化按周/月聚合数据观察开启率和时长的变化趋势判断功能是否被持续使用。这六个维度覆盖了“渗透、粘性、偏好、反馈、趋势”五个方向足够撑起一篇毕业设计论文的分析章节。实际编码时每个维度对应一个统计函数和一张图表结构非常清晰。2.4 可视化展示层让数据有说服力可视化部分我建议使用ECharts曲线图展示使用趋势饼图展示分类占比柱状图展示时段活跃度情感分析结果用堆叠条形图或仪表盘展示。前端页面不需要做得多花哨三个页面就够数据总览首页、详细分析页、数据管理页。首页放核心指标卡片和趋势折线图分析页放维度和图表联动管理页展示原始数据和删除/刷新按钮。图表的数据全部通过后端JSON接口下发前端用AJAX加载这样后端统计逻辑改动时前端不必跟着改。3. 数据库设计与关键表结构详解3.1 实体关系设计数据库围绕五个核心实体展开用户、视频、分类、使用记录、评论。一个用户对应多条使用记录一条记录属于一个分类一个视频对应多条评论一个视频归属于一个分类。用户表可以直接复用Django的auth_user也可以自定义user_profile表存年龄、性别等脱敏字段。关系上不需要物理外键约束Django的ORM通过模型间ForeignKey关系就能做关联查询既保留了数据完整性控制又避免了批量插入时机票外键导致的性能问题。3.2 核心表字段设计使用记录表analysis_usage_record是最重要的一张表核心字段如下字段名类型说明idBIGINT主键自增user_idBIGINT关联用户IDstart_timeDATETIME本次使用开始时间end_timeDATETIME本次使用结束时间duration_minutesINT使用时长分钟category_idBIGINT观看内容分类is_teen_modeTINYINT是否在青少年模式内device_typeVARCHAR(20)设备类型手机/平板/PCcreated_atDATETIME记录写入时间视频信息表analysis_video_info用于存采集到的视频数据字段名类型说明idBIGINT主键自增bvidVARCHAR(20)B站视频唯一编号建唯一索引titleVARCHAR(200)视频标题category_idBIGINT分类IDplay_countBIGINT播放量like_countBIGINT点赞数comment_countINT评论数publish_timeDATETIME发布时间评论表analysis_comment_info需要保留文本内容和情感分数字段名类型说明idBIGINT主键自增video_idBIGINT关联视频IDuser_idBIGINT评论用户IDcontentTEXT评论内容sentiment_scoreFLOAT情感得分-1到1之间comment_timeDATETIME评论时间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 django4.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, paramsparams, headersheaders, timeout5) 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_size500)批量插入比循环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_playSum(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): Cant 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(id1).first() if record: record.delete() # 批量删除 UsageRecord.objects.filter(duration_minutes__lt0).delete()如果用Q对象组合条件时不小心漏了括号会查出一堆意料之外的数据建议先在Django shell里打印query属性检查生成的SQL再真正执行删除。Cookie设置Token这个问题也有很多同学问做登录模块时在响应中设置token即可response JsonResponse({code: 200, msg: 登录成功}) response.set_cookie(token, token, max_age3600, httponlyTrue)前端后续请求带上这个Cookie后端通过request.COOKIES读取。如果使用DRF可以换成JWT方案逻辑更标准但毕设里用Cookie已经足够。5.3 数据采集与中文乱码问题中文乱码的根源多半是字符集不统一。数据库表是utf8mb4Django连接字符集也是utf8mb4HTML页面头部声明charsetutf-8这三处必须一致才能彻底解决。采集到的JSON文件如果出现中文乱码在open文件时显式指定encodingutf-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站只做通用的“视频平台内容治理数据分析系统”。先把当前这套流程跑通后面怎么延展都顺理成章。