基于大数据的B站青少年模式使用情况数据分析系统构建指南

既然要做“基于大数据的Bilibili青少年模式使用情况的数据分析系统”这种毕设项目，我得先跟你说句实在话：这题出得挺巧的。既有技术深度可以挖，又有社会话题可以做文章，答辩的时候比较好讲。B站本身就是年轻人聚集地，青少年模式又是平台治理的热门方向，把这两个结合起来做数据分析，导师不会觉得你在水，反而会觉得你对热点有敏感度。下面我把这个题目从选型、设计到落地的完整思路，以及源码、论文、部署文档这些交付物的写法，一次性都给你捋清楚。

1. 这个毕设到底在做什么

1.1 题目拆解与核心需求定位

先把题目拆开看：“基于大数据”、“Bilibili青少年模式”、“使用情况”、“数据分析系统”，这四个词串起来，核心任务就一句话：爬取B站青少年模式下的公开内容数据，清洗之后做多维度的统计分析和可视化展示，最后交付一个可运行的系统。

很多同学见到“大数据”三个字就慌，以为要搭集群、配Hadoop、天天跟Spark打交道。其实本科阶段的毕设，重点在于“完整的技术链路”，而不是“多大规模的数据量”。你只要能证明自己掌握了从采集、存储、清洗、分析到展示的全流程，数据量在十万条级别其实就足够了。真要你把千亿级数据跑在集群上，你实验室那几台机器也撑不住，所以别自己吓自己。

这个题目还有一个隐含优势：B站的数据是结构化程度很高的，视频信息、UP主信息、播放数据都有明确的字段定义，不像文本情感分析那样需要消耗大量时间在预处理上。你拿到手的原始数据基本是JSON结构，解析之后可以直接入库，这对后续的分析环节省了太大力气。

1.2 为什么这个题目在答辩时有天然优势

我见过太多毕设题目，什么“基于SpringBoot的图书管理系统”、“基于Java的酒店预订系统”，这种题目的通病是技术含量看着低、扩展点少。你的题目不一样，它有四个明显的答辩加分项：

第一，数据来源是真实且动态的。B站的内容每天在更新，你的系统跑一次得到的结果可能就不同,这就意味着你在演示的时候，可以现场展示数据采集的过程，说服力很强。

第二，分析维度有社会意义。青少年模式使用情况，这本身是一个内容治理命题，你可以做时间维度上的内容曝光趋势分析，也可以做不同分区的资源分布对比，这些结论有现实参考价值，评委愿意听。

第三，技术栈覆盖面广。爬虫、数据处理、数据库、可视化、前后端，每一层都有东西可以讲，论文也能写出章节感。

第四，可扩展性强。如果评委问“你还能做什么”，你可以说加上时间序列预测、内容分类模型、用户画像等等，显得有前瞻性。

2. 技术选型与整体架构设计

2.1 技术栈选型：为什么我建议用Python全家桶

技术选型这件事，原则上就一条：用你最有把握的，而不是最新最炫的。B站相关的大数据毕设项目，Python全家桶是绝对的主流，原因很简单：

• 爬虫阶段：Requests请求库 + BeautifulSoup/JSON解析，语法简单，出现问题也好调试。Scrapy虽然功能强，但学习成本高，考虑到本科生毕设周期，不建议自己给自己加戏。
• 数据清洗：Pandas是无可替代的，处理表格型数据的一套API，从读取到过滤、聚合、去重、采样，覆盖全部日常操作。
• 数据分析：基础的统计分析用Pandas就够，如果展示分析深度，可以叠加NumPy做数值计算。
• 可视化：首选ECharts，图表类型丰富、交互性好、起视觉效果好，评审老师看着会觉得很专业。PyECharts可以让你用Python代码直接生成HTML片段，接入Flask之后动态返回图表配置，比前端手写JS省力得多。
• 后端框架：Flask，轻量、理解成本低，一个py文件就能启动服务，做毕设级的数据展示后端绰绰有余。
• 数据库：MySQL，主流、稳定、BI工具和可视化库都有现成连接驱动，论文里写出来也好看。

这套组合在毕设中最大的好处是出图快、调试方便。你写了一个Pandas聚合函数，马上能在Jupyter里跑出结果，确认没问题再搬到Flask里，每一层都不需要来回切换语言思维。

2.2 系统分层：采集、存储、分析、展示四层架构

整个系统按功能可以拆成四个层次，这也是数据类项目通用的分层方式，写论文的时候直接拿来做系统架构图：

这样分层的好处是每一层都可以独立测试。比如存储层出问题了，你直接用Navicat查表就能定位，不需要从前端一路排查下去；分析层算法想调整，你单独跑一个脚本就行，不用动Web服务。

2.3 功能模块划分与数据流走向

系统的功能模块大致分为五个：数据采集模块、数据管理模块、分析计算模块、可视化展示模块、系统管理模块。

数据流是这样的：采集脚本通过B站公开接口拿到视频元数据和分区信息，先落到本地JSON备份，然后清洗去重，再写入MySQL。后端服务从数据库读数据，交给分析引擎做聚合计算，结果以JSON格式传给前端页面，前端通过ECharts渲染成图表。

这里有一个容易被忽略的点：清洗后的数据应该单独落一份到表里，不要覆盖原始数据。为什么？因为你后期如果要调整清洗策略，或者发现某个字段解析有误，原始数据还在，重新清洗一遍就行。我见过好几个同学把原始数据直接覆盖掉，后面论文里要补数据口径的时候找不到源头，非常狼狈。

3. 数据模型设计与数据库表单设计

3.1 核心数据表结构设计

数据库设计是整个项目的地基，表建得合理，后面分析的时候SQL都不知道省多少事。以视频信息表为例，核心字段如下：

CREATE TABLE `video_info` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', `bvid` VARCHAR(64) NOT NULL COMMENT 'B站视频唯一标识', `title` VARCHAR(512) NOT NULL COMMENT '视频标题', `tid` INT NOT NULL COMMENT '分区ID', `tname` VARCHAR(64) NOT NULL COMMENT '分区名称', `owner_name` VARCHAR(128) NOT NULL DEFAULT '' COMMENT 'UP主昵称', `pub_time` DATETIME NOT NULL COMMENT '发布时间', `duration` INT NOT NULL DEFAULT 0 COMMENT '视频时长（秒）', `view_count` INT NOT NULL DEFAULT 0 COMMENT '播放量', `danmaku_count` INT NOT NULL DEFAULT 0 COMMENT '弹幕数', `like_count` INT NOT NULL DEFAULT 0 COMMENT '点赞数', `coin_count` INT NOT NULL DEFAULT 0 COMMENT '投币数', `favorite_count` INT NOT NULL DEFAULT 0 COMMENT '收藏数', `share_count` INT NOT NULL DEFAULT 0 COMMENT '分享数', `reply_count` INT NOT NULL DEFAULT 0 COMMENT '评论数', `is_teenager_mode` TINYINT NOT NULL DEFAULT 0 COMMENT '是否青少年模式可见', PRIMARY KEY (`id`), UNIQUE KEY `uk_bvid` (`bvid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='视频信息表';

注意到两个设计细节：

一个是bvid设置了唯一索引。同一视频在采集过程中可能被重复请求到，没有唯一索引的话，去重就得靠程序判断，效率低且容易出错。有了唯一索引，插入时用INSERT IGNORE就可以自动忽略重复数据。

另一个是is_teenager_mode字段。这个字段的设计思路是：在爬取时分别请求青少年模式入口和普通模式入口，同一个视频如果在两种模式下都出现了，就标记为1，这样就为后续做模式对比分析留好了钩子。

3.2 采集任务与数据字典管理

除了业务数据表，系统里还应该有一张采集任务表，记录每次采集的执行时间、采集范围、任务状态、成功和失败数量。这张表的作用有两个：一是论文里写“系统的数据更新机制”的时候有据可依；二是定位爬虫问题的时候，可以快速查到是哪个批次的数据出了问题。

CREATE TABLE `task_record` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `task_name` VARCHAR(128) NOT NULL COMMENT '任务名称', `task_type` TINYINT NOT NULL DEFAULT 0 COMMENT '采集类型：0-分区；1-关键词搜索；2-U主投稿', `start_time` DATETIME DEFAULT NULL, `end_time` DATETIME DEFAULT NULL, `total_count` INT DEFAULT 0 COMMENT '请求总数', `success_count` INT DEFAULT 0 COMMENT '成功数', `failed_count` INT DEFAULT 0 COMMENT '失败数', `status` TINYINT DEFAULT 0 COMMENT '状态：0-运行中；1-完成；2-异常', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

数据字典这块，建议在论文附录里放一张字段说明表，把每个字段的含义、类型、来源、取值逻辑写清楚。论文评阅老师有时候不会仔细看你的代码，但一定会看数据字典——这是判断你系统设计是否规范的重要依据。

4. 数据采集实现：B站公开接口的接入与调优

4.1 采集入口怎么找：分区分页与检索接口

B站的数据采集，优先推荐使用官方开放接口，而不是直接解析网页HTML。网页解析有两个痛处：一是B站页面是动态渲染的，有些数据藏在JS接口里，你得开着浏览器开发者工具一个一个找；二是网页结构经常微调，今天能用的Selector明天可能就失效了。

推荐的做法是直接调用B站的内容分区列表接口。以科技分区为例，通过浏览器开发者工具，请求https://api.bilibili.com/x/web-interface/newlist，带上rid参数（分区ID）、pn参数（页码）、ps参数（每页数量）以及必要的Cookie，返回的JSON里就带了视频列表的完整信息，包括bvid、title、pub_time、duration、owner_name等核心字段。

import requests def fetch_video_list(rid: int, page_num: int = 1, page_size: int = 20, cookies: str = "") -> list: url = "https://api.bilibili.com/x/web-interface/newlist" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": "https://www.bilibili.com/", } params = { "rid": rid, "pn": page_num, "ps": page_size, } # cookies参数建议动态维护，避免过期 if cookies: headers["Cookie"] = cookies resp = requests.get(url, headers=headers, params=params, timeout=10) resp.raise_for_status() data = resp.json() if data.get("code") == 0 and data.get("data"): return data["data"].get("archives") or [] return []

这里提醒一下：接口只返回当前分类下的“新投稿”按时间排序的数据，如果你需要按播放量排序，可以考虑热门列表接口/x/web-interface/popular。来得及的话，建议两个接口都采，采集的时候记录数据来源，分析的时候还可以对比“热门内容”和“新内容”在青少年模式下的差异。

4.2 新增数据采集（增量采集）

如果需要采集动态新增的数据，追加采集（增量更新）是很常见的方式。在实现上，可以利用B站搜索接口索引最近更新视频，或者定期对已收藏UP主的主页进行扫描。这里给出一种最直接的增量方案：按更新时间刷新列表。

具体思路是：每次采集前，先查询数据库里最新的视频pub_time，然后从那个时间节点开始向后翻页采集；遇到时间早于游标的记录就停止。这种方式实现起来比较简单，伪代码如下：

def incremental_fetch(rid, latest_time): page = 1 while True: videos = fetch_video_list(rid, page_num=page) if not videos: break oldest_time = min(v.get("pub_time_as") for v in videos) if oldest_time < latest_time: videos = [v for v in videos if v.get("pub_time_as") >= latest_time] save_to_db(videos) break save_to_db(videos) page += 1 time.sleep(1)

增量采集的意义不仅是省流量，还能让系统日志里显示“本次新增XX条数据”，在毕业答辩现场演示的时候，这个数字是动态的，观看体验很像真实的运营后台。

4.3 反爬思路与请求频控的取舍

说到B站爬虫，很多人第一反应是“会被封”。其实B站对普通频率的请求是比较宽容的，毕设项目不是生产环境，不需要追求速度，只需要保证稳定采集。我这里有两个原则：

第一，单线程优先，频控放宽。你不需要用多线程把采集速度提高到每秒几十个请求——数据量也就几万条，按单线程每秒1个请求的速度，两三个小时也能采完。把time.sleep()设置在0.5~1.5秒之间，加一点随机抖动，就非常安全了。

第二，Collection与Cookie策略。B站部分接口对未登录和已登录的返回内容会有差异。建议准备一个账号的Cookie放在配置里，请求的时候带上，能访问到的数据更全。不要用高频的账号直接跑，万一触发风控，换个账号再试即可。

4.4 异常重试与日志埋点

采集过程最怕的是跑到一半抛异常，程序停了，你还不知道停在哪。所以要实现两个机制：一是单条请求异常重试，连续失败超过3次就跳过，记录失败原因；二是本地日志输出，每完成一个分区、翻到第几页，都把进度打印出来。

import time import logging logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s') def fetch_with_retry(url, params, headers, max_retry=3): for attempt in range(1, max_retry + 1): try: resp = requests.get(url, params=params, headers=headers, timeout=10) if resp.status_code == 200: return resp.json() except Exception as e: logging.error(f"请求异常: {e}, 第{attempt}次重试") time.sleep(2 * attempt) return None

这一套做下来，你在论文中可以写“系统具备健壮的容错机制”，答辩的时候也能答上来“程序挂了怎么办”这类问题。

5. 数据清洗与特征工程建设

5.1 数据清洗的三个核心环节

采集下来的原始数据不能直接用，至少要经过三个步骤：

第一步，字段抽取与类型转换。接口返回的JSON里嵌套层级很深，比如owner字段是个对象，里面才有name。直接用Pandas读JSON会发现列层次混乱，所以前期先拍平，只抽自己需要的字段。

import pandas as pd def transform_archive(item: dict) -> dict: return { "bvid": item.get("bvid"), "title": item.get("title"), "tid": item.get("tid"), "tname": item.get("tname"), "owner_name": item.get("owner", {}).get("name"), "pub_time": pd.to_datetime(item.get("pub_date", None), unit="s", errors="coerce"), "duration": item.get("duration", 0), "view": item.get("stat", {}).get("view", 0), "like": item.get("stat", {}).get("like", 0), "coin": item.get("stat", {}).get("coin", 0), "favorite": item.get("stat", {}).get("favorite", 0), "share": item.get("stat", {}).get("share", 0), "reply": item.get("stat", {}).get("reply", 0), "danmaku": item.get("stat", {}).get("danmaku", 0), }

第二步，去重与全角半角统一。标题里可能混入全角逗号、空格等字符，直接str.strip()处理一遍。bvid重复的直接drop_duplicates()。

第三步，异常值过滤。播放量为0、发布时间在1970年附近之类的数据，大概率是占位数据，需要过滤掉。这一步会让数据量缩水，但留下来的数据才是有分析价值的。

5.2 青少年模式识别：怎么判断“可见性”

“青少年模式使用情况”这个题眼，核心是你要能识别出一个视频在青少年模式下是否可见。做法是这样的：B站有一部分视频在青少年模式下会被限制，本质上是内容白名单/黑名单机制。你可以构造两套请求——一套不带青少年模式参数请求普通列表，一套通过B站的青少年模式首页接口请求受限列表，然后对比两者的bvid集合。

对比逻辑：

• 同时出现在两个集合中：普通可见 + 青少年可见
• 只出现在普通集合中：青少年模式不可见

这个“可见/不可见”的二元标记，是整个系统的核心特征。后续分析哪些分区、哪些类型的视频更容易被限制、各分区青少年内容覆盖率是多少，都依赖这个标签。

5.3 新增统计特征：互动率、完播率估算、内容时长分层

除了原始字段，建议构造几个有分析价值的衍生特征。这些特征在论文里可以单独成为一章节，展示你做了“特征工程”的工作。

互动率的计算公式：

video["interact_rate"] = ( (video["like_count"] + video["coin_count"] + video["favorite_count"] + video["reply_count"]) / (video["view_count"] + 1) # +1防止除零 )

这个指标衡量的是“每播放一次会带来多少互动”，比单纯看播放量更能反映内容质量。

时长分层可以做离散化：小于60秒的算短视频，60到600秒的算中视频，大于600秒的算长视频。为什么这个分层有用？因为在分析B站青少年模式的内容生态时，时长的分布能反映内容形态的偏向，比如知识区可能中长视频偏多，娱乐区短视频偏多。这种结论在论文里一写就是“发现”，特别适合拿来当分析章节的小标题。

6. 数据分析维度与可视化大屏设计

6.1 分析维度的设计方案

数据分析这件事，不怕维度多，就怕没逻辑。建议按照“基础描述—对比分析—趋势分析—关联探索”四个层次组织维度：

基础描述统计：青少年模式下可见视频的总数、日均新增量、播放量均值中位数、互动量Top10榜单。

分区对比分析：不同分区的视频数量占比、可见率对比、平均播放量对比、互动率对比。这个维度是整个系统最出彩的，因为用堆叠柱状图和雷达图展示分区生态结构差异，视觉效果特别直观。

时间趋势分析：按周/月聚合新增视频数量、播放量走势，判断青少年内容供给的波动情况。这里要注意区分发布时间和采集时间，别把两个时间字段搞混了。

内容特征分析：时长分布直方图、标题词频TopN（用jieba分词）、UP主发布频率TopN等，丰富分析维度。

6.2 可视化图表与ECharts的接入细节

可视化大屏建议设计成上下左右布局：

• 顶部：系统标题 + 数据总览关键指标（四个Statistic Card）
• 左侧：分区可用率的横状条形图
• 中间：播放量/互动量日趋势的折线图 + 时长分布直方图
• 右侧：可见性对比的饼图 + 热门视频Top10排行榜
• 底部：数据更新日志滚动列表

ECharts接入的常规姿势是通过PyECharts生成HTML片段，再嵌入Flask渲染的页面中。比如做一个热门视频Top10的柱状图：

from pyecharts import options as opts from pyecharts.charts import Bar def generate_top10_bar(data): bar = ( Bar() .add_xaxis(data["title"].tolist()) .add_yaxis("播放量", data["view_count"].tolist()) .set_global_opts( title_opts=opts.TitleOpts(title="青少年可见视频播放量TOP10"), xaxis_opts=opts.AxisOpts(axislabel_opts=opts.LabelOpts(rotate=30)), ) ) return bar.render_embed()

拿到render_embed()返回的HTML代码后，用|safe过滤器插到Flask模板里即可，一行搞定，不需要前端跟JS折腾。

6.3 分析结果如何体现在论文里

论文的数据分析章节，不能只贴一堆图表，关键是把“数据结论”写出来。比如我的项目里跑出来一个结论：知识区在青少年模式可见比例约为80%，而舞蹈区只有20%；互动率排名第一的内容类型不是知识类，而是动画类的MAD/AMV作品。这种结论必须配上数据支撑，加上一句“这说明青少年模式在供给内容类型上存在显著的分区差异，建议优化调节机制”——这就是你的论文里“建议”章节的天然素材，根本不用苦想怎么写。

7. 系统部署与交付：源码、论文、部署文档的安排

7.1 本地/Docker部署的两种方式

一类部署方式是本地直接运行。因为技术栈是Flask+MySQL这样的轻量组合，对机器的要求很低。你需要做的事情包括：

1. 安装Python 3.9+、MySQL 8.0+；
2. 执行requirements.txt安装依赖；
3. 初始化数据库表结构；
4. 运行主程序。

把这四步写清楚，部署文档就完成了60%。注意requirements.txt一定要固定版本：

flask==3.0.3 requests==2.32.3 pandas==2.2.3 pymysql==1.4.6 pyecharts==2.0.5

另一类是Docker部署。如果你熟悉Docker，用docker build把它打包成镜像，在论文里可以写“系统支持容器化一键部署”。不过需要提醒的是，打包Docker镜像的时候，PyECharts生成的图表文件路径要处理好，别让容器里找不到模板。

7.2 部署文档的标准结构与一套可复用的框架

好的部署文档不是“操作手册”，而是“从零到一的还原步骤”。建议按这个顺序写：

1. 项目背景与系统架构简介（让读者理解你在部署什么）
2. 环境准备清单（软件版本、硬件建议、端口占用检查）
3. 数据库初始化（建库SQL脚本路径、字符集设置）
4. 应用启动步骤（前端和后端如果有分开的，分别写清楚）
5. 配置项说明（数据库连接、Cookie、采集参数）
6. 常见问题排查（端口被占用、数据库乱码、依赖安装失败）

部署文档一定要自己照着走一遍，我就是吃过亏的。当年我给别人写部署文档，写完直接发出去，结果对方运行不起来，我远程一看，原来我没写“将.env.example复制为.env”。这种低级错误会让你的文档可信度大打折扣。

7.3 源码目录结构与代码规范

源码的目录结构建议按功能模块划分清晰：

project/ ├── app.py # Flask应用入口 ├── config.py # 全局配置 ├── requirements.txt # 依赖清单 ├── modules/ │ ├── crawler/ # 采集模块 │ ├── analyzer/ # 分析模块 │ ├── storage/ # 数据库操作 │ └── visualizer/ # 可视化生成 ├── templates/ # 前端模板 ├── static/ # 静态资源 ├── docs/ # 部署文档、接口说明 └── data/ # 原始数据与备份

代码命名方面没有硬性要求，但建议函数名用动词开头，fetch_video_list，save_to_db，generate_report，一眼就能看懂。论文附录里贴核心代码的时候，最好配上注释，导师一般都会翻附录，把注释写全了，印象分能高不少。

7.4 论文结构安排与摘要写作建议

最后提一下论文。毕业设计论文的结构，建议用经典七章式：

第一章 绪论（背景、意义、国内外研究现状） 第二章 相关技术介绍（B站开放接口、Flask、ECharts、MySQL等） 第三章 需求分析与系统设计（总体架构、功能模块、数据库设计） 第四章 系统实现（每个模块的关键代码与实现过程） 第五章 系统测试与结果分析（功能测试、数据采集结果展示、分析结果说明） 第六章 总结与展望

写论文的时候最容易犯的毛病是写成代码说明书，大段大段贴代码。正确的做法是：代码贴关键片段，然后用文字说明设计思想和实现逻辑。比如贴一段Pandas聚合代码，下面解释“这里用了groupby按分区聚合，计算每个分区的可见视频总量和可见率，为分区对比分析提供数据基础”——论文是要看你“为什么这样写”，不是看代码本身。

8. 常见问题与避坑指南

8.1 爬取阶段的高频问题

问题一：返回数据是重定向的HTML。这个基本是Cookie失效了。重新登录账号，把新Cookie更新到配置文件里就可以了。如果是接口要求WBI签名，就直接关掉这一层限制，调用基础接口别走带签名的接口。

问题二：采集过程中IP被临时限制。不用慌，一般等一段时间就解封了。建议采集脚本里加入钉钉/邮件通知机制，一旦触发限制立刻发通知，你就能及时调速，别把一个批次的采集任务跑废了。

8.2 数据入库的编码与连接问题

MySQL的字符集一定要在连接字符串里明确指定UTF-8：

DB_CONFIG = { "host": "localhost", "port": 3306, "user": "root", "password": "your_password", "database": "bilibili_project", "charset": "utf8mb4", }

另一个常见Bug是Pandas的DataFrame.to_sql写入MySQL时，如果主键冲突会导致整个事务终止。我的处理方法是先把新数据pandas.DataFrame写入临时表，然后用一条INSERT IGNORE完成去重写入。

8.3 可视化和前端展示的边界情况

最常出问题的环节是图表数据为空时报错。比如你筛选了某个日期范围，结果数据库里没有数据，ECharts会显示空白。这里建议在后端接口加一层默认值处理：

if df.empty: return {"status": "empty", "message": "该时间范围内暂无数据"} return {"status": "success", "data": json.loads(df.to_json(orient="records"))}

这样就算数据为空，前端也能弹出提示而不是白屏，演示的时候不会在大屏幕上露怯。

8.4 毕设答辩高频提问实录

提前准备一下这些问题的回答，答辩现场会从容很多：

• “你的系统数据量有多大？为什么不需要Hadoop？” 回答：数据量在十万级以下，单机MySQL完全能处理；Hadoop适合PB级数据，本项目重点在分析链路的完整性，不在于数据规模。
• “青少年模式的判定机制你是如何实现的？” 回答：通过对比两种模式的接口返回内容集合，生成可见性标签；具体逻辑是取并集和差集。
• “如果数据量翻倍，你的系统瓶颈在哪里，怎么优化？” 回答：瓶颈在爬虫请求等待时间和MySQL单表查询。优化方向是引入消息队列削峰、换用ClickHouse做列式存储、用Redis做缓存。
• “这个系统的社会价值是什么？” 回答：能够为平台治理提供数据参考，帮助了解青少年模式内容供给情况和潜在缺口，也能帮助家长和公众监督互联网平台的内容过滤质量。

9. 一点个人体会

做这个项目的过程中，我最深刻的感受是：大数据项目不是比谁工具用得高级，而是比谁能把一个真实场景里的问题拆解得足够清晰。B站青少年模式这个切口选下来，数据获取有难度但不至于做不动，分析维度有深度但不需要堆算法，展示效果天生输出视觉冲击力，我从选题到完成系统部署，前后大概花了五周，其中一半时间花在数据采集和清洗上，后两周基本就是流畅地出分析、出图表、写论文。

至于交付物，源码、论文、部署文档、讲解PPT这几样东西，最强的搭配组合是“源码能跑通+部署文档能复现+论文能自圆其说”。你不需要把系统做到生产级的完美，但至少自己要走通两遍全流程。我第一次部署到一台全新虚拟机上的时候，就发现漏了两个系统依赖，当场在部署文档里补上，这种自我校验的习惯，推荐你们也养成。

最后分享一个小技巧：做这种毕设项目，全程用Git管理自己的代码，每天提交一次。论文里的开发日志章节，直接把git log导出，比凭空回忆要准确得多。答辩的时候，你甚至可以翻出最早的一次提交，指给评委看“这个系统是从一条采集脚本，一步步长成现在这样的”——这种真实的项目演进过程，比任何包装出来的话术都更有说服力。