1. 选题定调：短视频分享网站为什么是Java毕设的"常青树"

每年带毕设，都有一批学生问我同一个问题：题目到底怎么选？我的回答一般很直接——选一个你能讲清楚、又能做完的题目。短视频分享网站能在众多选题里一直火，不是没有道理的。它不像电商系统那么重，也不像纯粹的管理系统那么轻，刚刚好踩在"有技术含量、有业务逻辑、有展示效果"这三者的交叉点上。用Java SpringBoot做后端、Vue做前端，再配上一篇结构完整的论文，整套东西做下来，技术栈覆盖全面，演示起来又很有说服力。

先说清楚这篇博文要解决什么问题。如果你正在准备毕业设计，或者想跟着做一个完整的SpringBoot+Vue项目练手，标题里的方向——短视频分享网站——就是一个很好的载体。接下来我会把从选题、数据库设计、后端接口、前端页面，到最后论文写作和答辩准备的完整链路串一遍，把那些"文档里不写、只有真正做过才懂"的细节一起讲透。

为什么说短视频分享网站是"常青树"？拆开看其实很朴素：第一，它自带一个相对完整的用户行为闭环，注册登录、上传视频、刷视频、点赞评论关注，这些都是面试和答辩时容易讲清楚的业务点；第二，它有明确的难点可以深挖，比如文件上传、视频流播放、接口鉴权、分页加载；第三，它做得好看，Vue前端随便排版一下，演示效果就比纯表格类的管理系统强一个档次。这三个点叠加在一起，论文能写满，代码能写完，答辩能讲清，这就够了。

1.1 功能边界：做"什么都有"还是"什么都精致"

很多同学拿到题目后，第一反应是堆功能：要评论、要弹幕、要私信、要直播、要推荐算法。我每次都劝他们刹车。毕设项目的目标不是做张小龙，而是证明你具备独立完成一个完整系统的能力。功能清单一旦膨胀，论文写的全是流水账，答辩时一问细节就露馅。

我建议把功能收敛在三到四个核心模块上：

• 用户模块：注册、登录、个人信息、关注列表。这里可以挂JWT鉴权，也可以做简单的验证码校验，作为论文的技术亮点。
• 视频模块：视频的上传、审核（可选）、发布、播放、删除。上传是硬骨头，视频文件有大有小，直接决定你要不要写分片上传、要不要处理转码。
• 互动模块：点赞、收藏、评论、关注。这四个动作是短视频网站"互动感"的来源，实现不难，但表关系需要提前理清。
• 浏览模块：推荐流、按分类浏览、搜索。做不了复杂的协同过滤推荐，就做简单的热度排序、分类筛选和关键词搜索，论文里写"基于标签/播放量的相似推荐"也是成立的。

这个边界的好处是：每一个模块都能在论文里独立成章，前后端代码量适中，工作量看起来完整，又不至于一个学期全耗进去。记住一个原则：毕设是证明你及格，不是证明你封神。做完做稳，比做多做强更重要。

1.2 技术栈取舍：SpringBoot + Vue在这个场景里为什么顺手

技术选型这块，SpringBoot做后端接口服务在Java生态里几乎是没有争议的。内置Tomcat，配置简单，起步依赖一拉就能跑，对毕设来说省去大量环境折腾的时间。Spring Data JPA或者MyBatis-Plus二选一，我更偏向MyBatis-Plus，因为它的CRUD封装和分页插件真的是为"快速开发"设计的，论文里也能顺带提一句"使用MyBatis-Plus简化数据访问层开发"。

Vue这边，Vue 2还是Vue 3需要自己掂量。如果你接触Vue不多，而且学校教材和往年代码大多还是Vue 2，那我建议别在这个节骨眼上挑战生态迁移，老老实实用Vue 2 + Element UI。反过来，如果你对组合式API已经熟手，上手Vue 3 + Element Plus也没问题。关键是"能跑通"，不是"版本新"。

前后端分离的结构本身就是一个论文亮点：RESTful API + JSON交互，前端独立部署，后端只提供接口。这个架构一写清楚，论文的"系统设计"章节就立住了一半。我见过不少学生在这里纠结要不要用Spring Cloud，统一答复：不要。单体应用足够，引入微服务只会让你的论文和答辩都变成灾难。

2. 需求分析与数据库设计：先把表结构定明白再写代码

我最怕的程序员是什么样的？打开IDE就开始写实体类，写到一半发现缺字段，返回去改表。短视频网站看起来模块不多，表结构真设计起来还是有几个容易踩坑的地方。我的习惯是，先花一个晚上把数据表全部设计好，后面写代码就是按表填肉，顺很多。

2.1 模块拆解：用户、视频、互动、分类的边界怎么划

在动手建表之前，先画一张系统的功能脑图。不用多正式，你自己能看懂就行。用户模块负责账号相关，视频模块负责视频资源和元数据，互动模块负责点赞评论关注，分类模块负责内容组织。这几个模块之间的实体关系，其实就是E-R图的基础。

我可以分享一个我在设计时反复调整过的结论：**点赞、评论、关注这些互动行为，尽量设计成独立的表，而不是在用户表或视频表里塞一个计数字段了事。**比如视频表里有like_count字段，点赞时用SQL原子自增，这样列表展示很方便。但你不能不记"谁给哪个视频点了赞"，否则用户取消点赞、重复点赞这些问题根本处理不了。所以互动记录是"底账"，计数器字段是"缓存"，底账必须完整，缓存可以异步刷。

2.2 核心表结构：从用户表到视频表到互动表的字段设计

下面这套表结构，是我在实际项目里打磨过的版本，不是教科书级别的规范答案，但绝对够用、好扩展：

用户表（user）：

• id：主键，自增
• username：唯一，登录名
• password：加密后存储，别存明文
• nickname：昵称，允许重复
• avatar：头像URL
• bio：个人简介
• create_time：注册时间

视频表（video）：

• id：主键
• user_id：发布者ID，外键逻辑关联，不建物理外键也行
• title：标题
• cover_url：封面图URL
• video_url：视频文件URL
• category_id：分类ID
• like_count：点赞数
• favorite_count：收藏数
• comment_count：评论数
• play_count：播放数
• status：0待审核/1已发布/2下架
• create_time：发布时间

互动表可以拆成三张：like_record（点赞记录）、favorite_record（收藏记录）、comment（评论）加上follow（关注关系）。这些表的共同点是都带user_id和目标业务ID，再加一个create_time。评论表额外需要content字段，关注表则需要关注者ID和被关注者ID。

分类表（category）很简单：id、name、sort。可以预置"美食""旅行""游戏""科技"这类常见分类，演示的时候视频一进来就分好了类，不用临时造数据。

2.3 容易忽略的字段与设计经验

字段设计里有几个点是新手特别容易漏的，我单独拎出来讲。

第一个是视频的status状态字段。很多同学做完发布功能就直接给status写死成"已发布"，结果论文里写"系统包含内容审核机制"，代码里完全没有。哪怕你的审核是"上传即通过"，也建议保留这个字段，后面论文写审核流程、答辩讲功能扩展，都有东西可说。

第二个是逻辑删除。用户删掉了一个视频，你到底是物理删除文件，还是只把status改成2？我的经验是：数据库记录做逻辑删除，文件是否物理删除看你的存储空间。如果视频存在本机目录，空间吃紧就删文件，空间不紧张就保留。这个选择可以在论文里写明白，属于"系统设计决策"的一部分。

第三个是时间字段统一用datetime或者timestamp，前端拿到后直接格式化就行。别用字符串存时间，排序、区间查询全都别扭。

第四个，上传的文件名一定要处理。用户上传的文件名五花八门，含中文、含空格、含特殊字符的都有，直接拿来当存储路径十有八九要出问题。建议服务端生成UUID或者用时间戳+随机数重命名，扩展名保留原样的后缀。

3. 后端实现：SpringBoot如何把核心接口串起来

表结构定好之后，后端开发的节奏就非常快了。SpringBoot项目用IDEA的Spring Initializr一分钟就能初始化，勾上Web、MySQL Driver、MyBatis-Plus依赖，一个能跑的项目骨架就有了。这一节我不贴完整代码，重点讲"每一层该干什么、为什么这么干、有哪些坑"。

3.1 项目分层：controller-service-mapper的职责边界

分层这个事，很多教程讲得很玄，我一句话说清楚：controller收参数、校验参数、调service；service做业务逻辑、事务控制；mapper只管数据库操作。这条线一旦乱了，后期改一个需求就要牵一发动全身。

举一个实际例子。视频上传接口的完整链路是这样的：

1. controller接收MultipartFile文件流和视频信息参数
2. 把文件保存到服务端指定目录，生成访问URL
3. 将视频元数据写入video表
4. 返回发布成功的视频信息

这个链路里，文件存储和数据库写入都算业务逻辑，该放在service层。controller如果写了文件存储逻辑，后面想换成OSS云存储，就要大改；放在service里，controller的代码基本不用动。这就是分层的价值。

实体类和DTO（数据传输对象）也别混着用。视频表单提交的数据、数据库存的记录、接口返回的JSON，三者字段其实不完全一样。你用同一个对象从controller传到mapper，短期省事，后期前端要一个字段、后端的返回结构就得改一遍，连锁反应特别大。建议至少保留VO（视图对象）这一层，专门定义返回给前端的结构。但是注意，也别过度设计——每层都搞一套对象，毕设代码会膨胀到你自己都看不懂。

3.2 登录鉴权：JWT这套方案为什么适合前后端分离

短视频网站肯定要有用户体系，有用户体系就绕不开登录状态这个问题。传统Session方案在前后端分离架构里不够方便，跨端口、跨域名时Cookie处理很麻烦，所以JWT（JSON Web Token）成了这类项目的主流选择。

JWT的思路特别直白：用户登录成功后，后端签发一个包含用户ID、过期时间的加密令牌返回给前端。前端把它存在localStorage里，每次请求带上Authorization请求头，后端拦截器校验令牌、解析出用户信息，就知道"你是谁"了。

我这里提醒几个实操细节。第一，token里只放必要信息，用户ID和用户名就够了，千万别把密码扔进去。第二，token一定要设置过期时间，建议2小时，前端配合"token过期自动跳转登录页"的逻辑。第三，拦截器要做"白名单"放行，登录接口、注册接口、视频列表接口、视频播放接口都不需要鉴权，否则前端一刷新页面就全被拦住了。

简单贴一个拦截器的核心思路：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } // 解析token，把userId放进取request attribute Long userId = JwtUtil.getUserId(token); request.setAttribute("userId", userId); return true; } }

这套方案在论文里写"基于JWT的无状态认证机制"，答辩时也能继续往深了讲，比如token过期刷新，算是一个合格的技术亮点。

3.3 视频上传与播放：从本地上传到分片上传再到m3u8

视频上传是整个项目里技术含量最高、也最容易出问题的地方。我先说一个最简方案：后端直接接收MultipartFile，用transferTo保存到本地目录，然后把静态资源映射配置好，前端就能通过URL直接访问视频文件了。

这个方案够不够用？如果视频文件只有几MB、十几MB，完全够用。如果你打算在演示时上传一个几百MB的视频，那你会发现前端请求超时、后端内存吃紧。所以有两种进阶方案：一是分片上传，前端把文件切成几MB一块，逐块上传，后端按顺序合并；二是直接用MinIO或阿里云OSS存储，彻底绕开服务器磁盘压力。

分片上传的核心逻辑不复杂，但细节很多：

• 前端用File.slice()切分文件，给每个分片编号
• 后端先初始化一个uploadId，创建一个临时目录
• 分片逐个上传，存到uploadId对应的目录里
• 全部传完后，后端按序号合并分片，删除临时目录，生成最终文件

这套流程我强烈建议做进毕设里，因为它既是实操难点，又是论文亮点。答辩时被问"视频大文件怎么处理"，你能讲出分片上传和断点续传的思路，比只会回答"放在本地目录"高出一个层次。

再说视频播放。现在的短视频网站用mp4直出其实也能看，但真正讲究的做法是把视频转成HLS流（m3u8）。HLS的好处是天然支持拖动进度、码率自适应、可以边下边播。转码工具用FFmpeg，SpringBoot里可以用ProcessBuilder调用FFmpeg命令行：

ffmpeg -i input.mp4 -codec copy -start_number 0 -hls_time 10 -hls_list_size 0 output.m3u8

这里-hls_time 10表示每个切片10秒左右，-hls_list_size 0表示生成完整播放列表。转出来的m3u8文件和ts切片放在某个目录下，前端播放器直接拉m3u8地址就能播。如果你不想引入转码复杂度，也有一个折中方案：视频直接存mp4，前端用原生video标签播放，论文里把"m3u8转码"写成系统优化方向。这个取舍，取决于你剩下多少时间。

3.4 接口设计清单：短视频网站最少需要哪些接口

我建议在开始写controller之前，先在纸上列一个接口清单，把URL、请求方式、参数、返回结构定好。下面是我这个项目里的接口列表，照着开发不会乱：

统一返回值这一点很多人不重视，但我觉得特别值得强调。我习惯定义一个Result<T>通用返回类，里面就三个字段：code（200成功/500失败）、message、data。所有接口都返回这个结构，前端axios拦截器统一处理code，不用每个接口单独判断，开发效率高很多，论文里也好解释。

4. 前端实现：Vue如何做出可演示的短视频体验

后端接口就位之后，前端开发就是"搭页面+对接接口"。前端这块我重点讲几个"做得不好会翻车"的地方：路由配置、请求封装、视频播放、页面展示。

4.1 路由与页面骨架：前端页面最少要建哪几个

Vue项目的页面骨架，跟后端的接口清单是对应的。我的建议是至少包含这些页面：登录/注册页、首页（视频瀑布流）、视频详情页、个人中心、视频上传页。

路由这块有两个实操点要讲。第一，路由守卫必须做——判断localStorage里有没有token，没有就重定向到登录页。不然一个未登录用户直接手动输入/upload地址就能进上传页，这是明显漏洞。第二，动态路由和懒加载尽量用上，routes里按import()方式引入组件，首屏加载会快很多，论文里可以写"采用路由懒加载优化首屏性能"。

下面是一个最小可用路由配置的骨架：

const routes = [ { path: '/', component: () => import('../views/Home.vue') }, { path: '/login', component: () => import('../views/Login.vue') }, { path: '/video/:id', component: () => import('../views/VideoDetail.vue') }, { path: '/upload', component: () => import('../views/Upload.vue'), meta: { requiresAuth: true } }, { path: '/user/:id', component: () => import('../views/UserProfile.vue') } ]

4.2 axios封装：请求拦截、响应拦截、错误处理一次讲清

前后端分离的项目里，axios封装是每个页面都要用到的地基。很多同学一张页面里写一个axios.get，写到后来重复代码一堆，改接口地址要全项目搜索，体验极差。

我的封装思路是这样的：创建一个request.js，导出统一的axios实例，在请求拦截器里自动带上token，在响应拦截器里统一处理业务错误和HTTP错误。比如后端返回code 401，前端自动清除token并跳转登录页；网络错误则弹出统一提示。这样每个业务页面只管调用接口、拉数据、渲染页面，异常的响应全部集中在拦截器里消化。

贴一个拦截器的关键片段：

request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error('网络异常，请稍后重试') return Promise.reject(error) } )

4.3 视频播放方案：mp4直出和m3u8播放的前端处理

前端播放视频这个点，是最容易在演示时出状况的地方。我先说最省事的方案：后端传mp4地址，前端用<video>标签，控制条用原生controls属性，手机电脑都能放。这个方案我的评价是"稳，但也平淡"。

如果你做了m3u8转码，前端播放就需要HLS库了。浏览器原生不支持m3u8（Safari是个例外），所以必须引入hls.js或者video.js。这里我推荐hls.js，轻量、兼容性好。关键代码逻辑如下：先判断当前浏览器是否支持HLS原生播放，不支持就用hls.js去拉流并绑定到video元素。

import Hls from 'hls.js' function playM3u8(videoEl, url) { if (videoEl.canPlayType('application/vnd.apple.mpegurl')) { videoEl.src = url } else if (Hls.isSupported()) { const hls = new Hls() hls.loadSource(url) hls.attachMedia(videoEl) } }

我实测下来的经验是：m3u8播放首屏速度和拖拽流畅度都优于大体积mp4直出。代价是后端要跑FFmpeg转码，会多花时间和磁盘空间。我的建议还是那句话——如果时间紧，mp4直接播；如果想在论文里多写一个技术点，就做m3u8。两条路都走得通，但别在最后两周临时加转码功能，那个坑填不完。

4.4 首页与详情页的展示逻辑

短视频网站的首页和详情页，是演示效果的重头戏。首页我用的是卡片瀑布流布局：视频封面+标题+播放量，点击卡片跳转详情页。这里要重点处理分页加载，不然视频一多，首页首屏就加载几十条大图，用户体验非常差。

我的做法是：首页用Element UI的infinite-scroll指令配合前端滚动加载，每页12条，滚动到底部自动请求下一页，接口返回的records数组追加到列表。这个交互在演示时非常抢眼——面试官/答辩老师看着你不停往下滑，页面数据一直在加载，直观感受就是"这系统是活的"。

视频详情页的布局是：左边播放器，右边视频信息和评论区。播放量可以在进入详情页时调用一个/api/video/play/{id}接口，后端做播放量+1。评论区的数据量不大，直接一个v-for渲染列表即可。这里的小细节是：评论发布成功后，清空输入框、重新拉取评论列表、视频的comment_count要自动更新，这三个动作要在一个回调里完成，不然前端数据和后端数据就对不上。

5. 论文写作：从开题到答辩的节奏与干货

代码写完只是完成了一半，论文才是很多同学的噩梦。其实毕业论文的写作是有章法的，掌握好结构，写起来远没有想象中痛苦。

5.1 论文章节结构与每章该写什么

目前高校计算机类毕业设计论文的主流结构基本趋同，大体是这样：

• 绪论（约2000字）：背景、意义、国内外现状、文章结构
• 相关技术介绍（约3000字）：SpringBoot、Vue、MyBatis-Plus、JWT、FFmpeg等
• 系统需求分析（约2000字）：可行性分析、功能需求、非功能需求、用例图
• 系统设计（约4000字）：架构设计、功能模块设计、数据库设计
• 系统实现（约5000字）：核心模块的代码逻辑、截图展示、关键代码
• 系统测试（约2000字）：测试用例、测试环境、测试结果分析
• 总结与展望（约1000字）

这种结构的核心逻辑是：先告诉读者你要做什么，再告诉读者你用什么做，然后告诉读者你怎么设计，最后告诉读者你做出来的东西是什么样的。按"需求分析→概要设计→详细设计→实现→测试"这条软件工程的线组织，既符合规范，写起来也不容易乱。

很多学生有个误解，觉得"相关技术介绍"随便网上抄一段就行。这里我要说句实话：导师最烦的就是把百度百科搬进论文。正确写法是结合你的项目来写，比如介绍SpringBoot时，就写"本系统的用户登录模块基于SpringBoot的拦截器机制实现JWT鉴权"，把技术描述和项目场景绑定起来，这样既避免了单纯堆概念，又让老师觉得你真的理解了这些技术。

5.2 论文中最值得花时间做的三样东西

第一是E-R图。数据库设计章节必须有E-R图，这是展示你实体关系设计能力的重要载体。有的同学用Visio画，有的用PowerDesigner，有的直接draw.io，工具不限，关键是实体、属性、联系的表达要规范。实体用矩形、属性用椭圆、联系用菱形，这几个基本符号别搞错。图别画得太大，一张图放不下就拆成几个局部E-R图。

第二是系统架构图。前后端分离架构用一张简单的分层图就能说清楚：展示层（Vue）、接口层（SpringBoot Controller）、业务层（Service）、数据访问层（Mapper）、数据库（MySQL）。这张图放在"系统设计"章节，配合一段200字左右的说明，整个系统的全貌就出来了。

第三是核心功能的截图和代码片段。系统实现章节不要干巴巴地贴代码，我的写法是"功能描述 + 页面截图 + 核心代码 + 代码说明"四件套。截图用系统的实际运行界面，代码选最能代表该模块核心逻辑的一段，代码底下用2到3句话解释这段代码在做什么。这个模式写起来快，导师看着也直观。

5.3 答辩前必须准备的问题清单

答辩不是考察你写了多少代码，而是考察你有没有真的理解自己写的东西。我把自己被问过、以及帮学生模拟问到的高频问题整理如下：

• 为什么选择SpringBoot而不是SSH/SSM？——答：SpringBoot简化配置、内嵌容器、生态成熟，并且能与Vue更好地实现前后端分离。
• JWT和Session有什么区别？为什么选JWT？——答：JWT无状态、适合跨域和前后端分离，Session依赖服务端存储。
• 文件上传怎么处理大文件？——答：前端切片、后端合并，或者用OSS对象存储。
• 视频播放为什么用m3u8/为什么直接用mp4？——答：结合自己项目的实际情况讲清楚取舍逻辑。
• 数据库有哪些表？表之间的关系是什么？——答：把这个当成送分题，对着E-R图大声背。
• 项目有什么可以改进的地方？——答：别真说自己项目没缺点，可以讲分布式部署、推荐算法、视频审核接入内容安全服务等扩展方向。

准备答辩的基本策略：把你在论文里每一个"技术选择"都准备成一个"为什么"。为什么用它、不用它行不行、它解决了什么问题。把这套话术准备好，答辩基本上就稳了大半。

6. 实操中的避坑清单与时间投入建议

最后一块内容，我把自己在这个项目实操中踩过的坑整理成清单，没有顺序之分，遇到一个解决一个，希望能让你的毕设之路稍微平顺一点。

今年做这个项目容易翻车的地方，我一一列出来：

1. 环境版本不匹配。JDK 8对应SpringBoot 2.x，JDK 17对应SpringBoot 3.x；Vue 2对应Element UI，Vue 3对应Element Plus。这些版本链别混着装，不然各种奇怪报错会让你怀疑人生。我的建议是照着网上教程的版本组合来，别追求最新版。

2. transferTo保存文件时路径不存在。后端保存上传文件的目录如果还没创建，transferTo会直接报IOException。解决方式是先FileUtil.createIfAbsent或者手动mkdirs()。

3. 拦截器放行了预检请求还是报跨域。前后端分离开发时，前端端口和后端端口不同，跨域是必现问题。用@CrossOrigin或者配置WebMvcConfigurer里的CORS映射都行，但是注意addMapping要写/**，allowedOriginPatterns别写*，否则带token的请求会出问题。

4. 视频列表接口数据量一多就卡。这通常是没用分页导致的，加一个MyBatis-Plus的分页插件，前端滚动加载，问题立即解决。

5. 论文查重。技术描述部分真心建议自己重组语言，多结合自己项目中的实际业务来表述。格式细节提前对着学校模板调，别等终稿再统一调格式，那个工作量会在最后一周内爆炸。

时间投入上，我给一个相对保守的估计：数据库设计1周，后端接口开发2周，前端页面开发2周，联调修Bug1周，论文写作2周，答辩PPT和准备1周。满打满算大概9周，留出缓冲。算法基础薄弱的同学，上传、播放这部分可能要多留几天。总的来说，这个项目的难度分布是比较均匀的，没有哪个环节会单独卡死你，但每个环节都需要认真对待。

短视频分享网站这个选题，我希望你能把它当成一个真正能"为简历加分、为面试攒素材"的完整项目来做，而不是糊弄毕业了事。SpringBoot和Vue这条线，在中小企业开发岗里仍然是主流配置，把它做透了，你收获的绝不仅仅是一篇论文。写到这里，我最后再分享一个小体会：把项目做完的那天，回头再看一遍自己写的代码，那些当时觉得很头痛的问题，都会变成你脑子里最牢靠的经验。