用一句话来概括这个项目：它是一个基于 Spring Boot 后端框架、面向计算机专业毕业设计场景的视频点播网站，源码编号 16970，整体采用前后端分离思路，覆盖用户、视频、分类、评论、收藏、后台管理等核心业务。很多同学一听到“毕设源码”四个字，第一反应就是“拿过来跑起来就行”，但以我接触过大量同类型项目的经验来看，真正能让你在答辩现场游刃有余的，是你能把这个项目的架构为什么这么设计、表为什么这么建、接口为什么这么写讲清楚。这篇博文就围绕这个视频点播项目的完整链路展开，从前端选型、后端分层、数据库设计，到视频上传、JWT 登录、文件映射这些具体实现，再到环境配置、部署打包、常见排错，全部梳理一遍。无论是你拿到源码后无从下手，还是想自己照着做一个类似的毕设，这篇内容都能当一份落地参考。
1. 项目概述与选题拆解
1.1 视频点播网站到底要做哪些事
视频点播网站这个选题，在计算机毕业设计里属于“看起来不复杂、做起来有内容”的经典类型。它不像电商系统那样需要处理订单、库存、支付等一大堆强业务逻辑，也不像纯粹的图书管理系统那样过于单薄。它天然自带上传、播放、搜索、互动、管理这几个维度的功能，每一个维度都能单独展开讲出技术细节，非常适合用来体现一个学生的全栈开发能力。
从用户角色的角度去拆解，这个系统至少要有三类使用场景。游客场景下，访客能浏览首页推荐视频、按分类查看视频列表、搜索关键词，但想看完整视频或者做互动操作，就必须先注册登录。登录用户场景下，用户可以上传自己的视频、观看视频、点赞收藏、发表评论、管理个人资料。管理员场景下，则需要一个独立后台，能够对用户进行禁用或启用操作，对视频进行上下架和审核，对分类进行管理，甚至看一些简单的播放量统计。这些需求加在一起，就构成了一个完整的业务闭环。
从技术实现的角度去拆解，核心难点集中在几个地方：一是大文件上传和存储资源的处理；二是视频播放兼容性和访问权限的控制；三是 JWT 无状态登录在整个前后端项目里的贯穿；四是后台管理和前台展示在同一个后端服务里的权限区分。能把这些点真正实现出来，并且能在答辩时把原理讲清楚，这个毕设的质量就已经超过了大多数“只跑通一个 CRUD”的项目。
1.2 为什么 Spring Boot 是这类项目的默认选择
视频点播网站这类 JavaWeb 形态的项目，用 Spring Boot 做后端框架，基本已经成了毕业设计方案的默认选项。原因并不复杂。第一，Spring Boot 把原先 SSM 整合时最繁琐的配置工作自动化了，你不需要再手写一堆 XML 配置文件，一个启动类加上若干注解，就能得到一个可运行的 Web 服务，这对学生党来说实在太友好了。第二，Spring Boot 生态里的配套方案极其成熟，访问数据库有 MyBatis-Plus、Spring Data JPA，权限控制有 Spring Security、Sa-Token、JWT 拦截器，参数校验有 Validation 注解，这些组件不仅都有中文文档，网上的疑难解答也特别全，遇到问题搜一下基本都有答案。
更重要的一点是，Spring Boot 本身就是一个很好的答辩话题点。“自动配置原理”“starter 机制”“内嵌 Tomcat 的原理”这些都是面试官和答辩老师非常喜欢追问的考点。你哪怕只是把 Spring Boot 的自动配置大致讲明白，比如解释一下@SpringBootApplication里的@EnableAutoConfiguration是如何通过META-INF/spring.factories加载一堆xxxAutoConfiguration类的，评委就会觉得这个学生不是只会用框架，而是真的理解框架。所以从这个角度看，用 Spring Boot 做毕设，不只是技术选型合理，更是答辩策略上的明智选择。
2. 整体架构设计与数据库规划
2.1 前后端分离，还是服务端渲染
视频点播网站在做技术选型时，第一个要定的问题就是：前端页面到底怎么组织。目前这类项目里，最常见的做法是 Vue 全家桶加 Spring Boot 前后端分离。后端只负责提供 RESTful 接口，前端通过 Axios 请求这些接口，拿到 JSON 数据后再渲染页面。这样做的原因是三方面的。
第一是贴近企业真实开发模式。现在你去任何一家公司实习，遇到的新项目基本都不是用 Thymeleaf 这种模板引擎在服务端渲染页面，而是前端一套工程、后端一套工程，两边通过接口联调。如果你毕业设计就采用这套模式，将来入职适应期会短很多。第二是答辩有东西可讲。前后端分离以后，你可以讲跨域问题的产生和解决，可以讲 Vue Router 路由守卫如何控制页面访问权限，可以讲 Axios 拦截器如何统一处理 token 和异常。这些知识点比单纯在 Controller 里返回一个页面要有讨论价值得多。第三是前后端分离并不牺牲部署便利性。开发阶段前端独立跑开发服务器，部署阶段把前端打包后的 dist 目录放到 Spring Boot 的静态资源目录里（或者打成单个 Jar 包），仍然可以用一个 Java 进程把整个系统带起来。
有一个常见的误区是，很多同学觉得前后端分离就必须部署在两台服务器上。其实完全不是。实际毕设里最常见的做法是最终把 Vue 打包后的文件放进 Spring Boot 的src/main/resources/static目录下，打成一个 Jar，一个进程全部搞定。这样既保留了开发阶段的分离体验，又让演示环境变得极其简单。论文里写“项目采用前后端分离架构”，同时又说“可一体化打包部署”，这两句话完全不矛盾，反而让方案显得更完整。
2.2 项目模块划分与后端分层结构
从源码的工程结构上看，视频点播网站后端通常会按照经典的三层架构来组织：Controller 层负责接收请求和参数校验，Service 层负责业务逻辑和事务控制，Mapper 层负责数据库操作。很多用 MyBatis-Plus 快速搭建的项目，还会在 Entity、VO 或 DTO 这几个概念上做文章，这个点答辩时也值得重点说一下。
一个比较规范的后端包结构至少应该是这样的：
com.example.vod ├── controller // 前端接口入口 ├── service // 业务逻辑层，接口+实现类 ├── mapper // 数据库访问层，继承 BaseMapper ├── entity // 数据库实体类 ├── dto // 接收参数的中间对象 ├── vo // 返回给前端的视图对象 ├── config // 配置类，如 WebMvcConfig、CorsConfig ├── interceptor // 登录拦截器，JWT 校验逻辑 ├── utils // 工具类，如 JwtUtil、Result 包装类 └── VodApplication.java // 启动类Controller 层里千万不要堆业务代码，一个接口方法里应只做三件事：接收参数、调用 Service、返回 Result 包装结果。Service 层里再处理真正的业务判断，比如上传视频时校验文件是否为空、用户是否登录、分类是否存在。这样的分层不仅看起来清爽，更重要的是答辩时能很自然地讲出“高内聚、低耦合”的设计思想。
前端部分一般是 Vue 工程，典型的视图页面包括首页、视频列表页、视频详情播放页、上传页、登录注册页、个人中心、后台管理页。前端路由、组件、状态管理的组织方式，通常在源码里的router/、views/、components/这几个目录下都能看得到。你拿到源码后第一件事，其实不是急着跑，而是先把前后端这份目录结构浏览一遍，建立对整体代码地图的认知。
2.3 数据库表设计：一个视频项目藏了多少细节
数据库是整个系统中最体现设计功底的地方。视频点播网站的表数量一般不会太多，但每一张表的字段设计都有讲究。我列一个最常见的表结构清单，你可以对照着源码里的 SQL 脚本看：
| 表名 | 核心字段 | 说明 |
|---|---|---|
| user | id, username, password, nickname, avatar, role, status, create_time | 用户表，role 区分普通用户和管理员 |
| category | id, parent_id, name, sort | 分类表，支持多级分类 |
| video | id, title, desc, cover_url, video_url, category_id, user_id, play_count, status, create_time | 视频表，视频元信息统一存在这里 |
| comment | id, user_id, video_id, content, parent_id, create_time | 评论表，parent_id 用于回复评论 |
| favorite | id, user_id, video_id, create_time | 收藏表，联合唯一约束避免重复收藏 |
| operation_log | id, user_id, action, target, create_time | 操作日志表，后台审计用 |
有几个字段设计上的细节我特别想提醒一下。第一，几乎所有表都要有一个status字段，视频表用它来区分“公开、下架、待审核”，用户表用它来区分“启用、禁用”。这个字段看着简单，但它会让后台管理的实现变得很灵活，也解决了演示时不想删除数据的问题，比如你可以只把一条视频状态改成下架，而不是真的删掉它，这样数据就保留了。第二，create_time这种公共字段建议用 MyBatis-Plus 的自动填充功能统一处理，比如在实体类字段上加上@TableField(fill = FieldFill.INSERT)，然后写一个 MetaObjectHandler 实现类。这样所有插入操作都不用手动 set 时间，代码会干净很多，答辩时也可以单独讲这个细节。第三，外键尽量避免在数据库层面强关联，使用逻辑外键（也就是代码中维护关联的 id 字段）更灵活。比如删除用户时，如果把视频表的外键也连带删，容易引发误删；而逻辑外键只需要在代码中考虑是否要清理关联数据即可。
视频表里的play_count字段，最简单的实现就是每播放一次执行一次 update 加一操作，对毕设来说足够了。如果你的论文想引入一点高并发的处理思想，可以在设计说明里写“生产环境下播放量计数可通过 Redis 的 INCR 命令异步累加，再定期批量写入数据库”，这句话本身就是一个加分项，而且不需要真的去实现 Redis，在系统设计章节里讲清楚思路就行。
3. 核心功能实现与实操要点
3.1 视频上传：本地存储方案怎么落地
视频上传是这类项目的灵魂功能，也是最容易踩坑的地方。从纯后端实现来看，Spring Boot 接收文件用的是MultipartFile，Controller 里写一个@RequestParam("file") MultipartFile file就能拿到上传的文件对象。拿到文件之后，最常见、也最适合毕设演示的方案是存入本地磁盘，再把访问路径保存到数据库。
上传的代码逻辑并不复杂，但有几个细节非常影响最终效果。首先是文件重命名。如果前端传来的文件名是“毕业答辩视频.mp4”，直接存储的话，一方面可能因为文件名里的中文、空格导致 URL 访问出问题，另一方面容易发生文件名冲突。所以常规做法是用 UUID 生成新文件名，保留原文件扩展名即可。代码大致如下：
String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID().toString().replace("-", "") + ext;其次是按日期分目录存储。把所有视频无脑堆在一个文件夹里，文件一多就会非常混乱，而且将来做文件清理时也很麻烦。按日期目录落盘的做法是，在保存文件的路径中拼接一个yyyy/MM/dd格式的日期目录：
String dateDir = new SimpleDateFormat("yyyy/MM/dd").format(new Date()); File dir = new File(uploadPath + dateDir); if (!dir.exists()) { dir.mkdirs(); }每次上传都新建目录虽然会多几条文件系统操作，但换来的结构清晰度是非常值得的。实践中你也可以用 userId 作为目录维度，比如upload/用户id/日期/文件名，这样还能方便地按上传者来定位文件。最后是把可变的路径单独放到配置文件中，通过@Value注入到 Service 里。我见过太多把绝对路径硬编码在代码里的毕设项目，换成一台电脑就程序崩溃，这真的很冤枉。把uploadPath放到application.yml的file.upload-dir配置里，项目可移植性一下子就上来了。
上传接口的完整代码会包含文件非空校验、扩展名校验、保存文件、写入数据库这四个步骤。数据库里保存的视频 URL 不要直接存成完整 URL，而是存相对路径，例如/upload/2025/03/18/xxxx.mp4。这样前后端都只用相对路径，换域名、换端口都不会造成数据库中 URL 全部失效。
3.2 视频文件的访问路径映射
文件保存到本地磁盘后，浏览器并不会自动访问到这个路径，因为 Tomcat 默认只处理静态资源目录里的内容。你需要在 Spring Boot 里配置一个资源映射，把本地磁盘的物理路径映射为一个可访问的 URL 前缀。这里的核心配置类如下：
@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-dir}") private String uploadDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadDir); } }注意 Windows 和 Linux 路径差异。在 Windows 下如果你配置D:/vod-upload/，代码里最终拼接出来就是file:D:/vod-upload/；在 Linux 下要写/usr/local/vod-upload/，也就是file:/usr/local/vod-upload/。这是一个非常容易踩的坑，很多同学在自己的 Windows 电脑上运行正常，把 Jar 包扔到服务器上就全部 404，多半就是这个路径的问题。
另一个非常容易忽略的坑是拦截器和跨域配置对静态资源的影响。如果登录拦截器拦截了所有路径，而没有把/upload/**放行，那么前端的<video>标签请求视频文件时会因为 token 校验失败返回 401，看起来就是视频无法播放。在我经手的项目里，这个问题出现频率极高。所以拦截器配置时一定要记得放行/upload/**、/api/login、/api/register这类不需要登录就能访问的路径。
3.3 视频播放器选型与前端展示
文件路径配好了，接下来就是前端怎么播放。原生<video>标签当然可以直接放出 mp4，但用户体验比较粗糙，而且对不同编码格式的视频支持度不统一。更推荐的做法是引入一个开源播放器，比如 video.js 或者西瓜播放器。这类播放器自带控制条、播放进度记忆、多清晰度切换（如果你有多码率文件的话）等能力，视觉上比原生标签好很多，演示效果也更像一个“正规”的视频网站。
播放器壳子只是第一步，真正决定播放体验的是视频源格式。对于毕设来说，最稳妥的视频格式就是 H.264 编码的 MP4 文件。你可以在上传接口里设置一个简单的扩展名校验，只允许.mp4、.webm文件上传。如果用户想上传其他格式，可以提示他先转换格式。这个限制写在项目需求文档里，完全合情合理。
有些做得更完善的项目会在上传接口上集成 FFmpeg，自动把上传视频转码成统一规格的 MP4。但如果你拿到的源码并没有集成这个能力，我不建议你在答辩前临时加，因为 FFmpeg 的环境部署在校内演示机上非常不可控。你可以把这个方案放在论文的“系统改进与展望”里写，比如“未来可通过 JavaCV 或 FFmpeg 实现上传视频的分辨率统一和多码率切片”，这就已经达到体现思考深度的效果了。答辩老师不会因为一个毕设没做转码就扣分，相反，“我清楚这个短板并提出改进方案”反而是一个加分点。
3.4 用户认证与 JWT 登录鉴权
登录模块是答辩时会被追问较多的环节，因为登录实现方案直接体现你对前后端交互和无状态协议的理解水平。现在主流毕设项目都用 JWT 加拦截器的组合，而不是传统的 Session。原因是前后端分离后，前端部署的域名或端口和后端往往不同，如果用 Session 就必须处理跨域携带 Cookie 的问题，而 JWT 把用户信息加密生成字符串放在请求头里，天然就适合跨域场景。
JWT 流程并不复杂：用户登录成功后，后端把 userId、用户名、角色封装进 token 并签名返回给前端；前端把 token 存到 localStorage 或 Pinia/Vuex 中，每次请求时在请求拦截器里把 token 加到 header 里；后端写一个 HandlerInterceptor，在每次请求进入 Controller 前解析 token，如果 token 合法就放行并解析出当前用户信息，放在 ThreadLocal 或请求域里供后续操作使用。
数据库中的用户密码记得存加密后的结果，最简单的方案是用 MD5 加盐或 BCrypt。毕设答辩时讲到密码安全，你说“我使用了 BCrypt 加密存储”，这个提法本身就是专业性的体现，而且 Spring Boot 的spring-security-crypto依赖只需要两句配置就能用。JWT 生成时尽量把过期时间设置得合理一些，比如 24 小时，同时在前端 Axios 响应拦截器里判断 token 过期后的跳转登录逻辑。只要把这些点串起来，整个登录模块就问不倒。
3.5 首页列表、搜索与分页接口设计
首页推荐视频、分类列表、关键词搜索，这些功能的本质都是“带条件的分页查询”。如果你用 MyBatis-Plus，这个环节的代码会非常简洁。典型写法如下：
Page<Video> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Video> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Video::getStatus, 1) .eq(categoryId != null, Video::getCategoryId, categoryId) .like(StringUtils.isNotBlank(keyword), Video::getTitle, keyword) .orderByDesc(Video::getCreateTime); IPage<Video> result = videoMapper.selectPage(page, wrapper);这里的eq(condition, column, value)与like(condition, column, value)写法妙处在于，当条件参数为 null 或空字符串时，MyBatis-Plus 会自动忽略这个查询条件，不需要手动拼接 SQL。这样既保证了代码可读性，也避免了字符串拼接 SQL 带来的注入风险。前端拿到返回的分页对象后，把 total、records 对应到分页组件上，就能实现标准的列表页效果。
接口返回的数据结构建议统一封装成一个Result对象。比如：
public class Result<T> { private Integer code; private String message; private T data; // 静态方法 success() / error() }code=200表示成功，其他值表示不同类型的错误。前端 Axios 拦截器里判断响应体的 code，统一弹出错误提示，不需要每个页面都写一堆重复的错误处理逻辑。这个统一封装在答辩时也是可以展开讲的“规范设计”细节。
4. 从源码到可运行：环境配置与部署实操
4.1 环境准备与版本选择
拿到源码之后，第一件事不是急着双击启动，而是核对环境版本。视频点播项目常见的技术栈组合是 Spring Boot 2.7.x + JDK 8 或 JDK 11 + MySQL 5.7/8.0 + Maven 3.6+，前端则是 Vue 2 或 Vue 3 + Element UI 或 Element Plus。
这里最要命的一个问题是 Spring Boot 2.x 和 3.x 的不兼容。如果你拿到的源码是 Spring Boot 2.x 体系，却用 JDK 17 打开然后强行把版本改到 3.x，你会遇到成片的编译错误，因为 Spring Boot 3 从javax.*包迁移到了jakarta.*，很多第三方包的兼容版本也完全不同。我的建议是，源码里 pom.xml 写的是什么 Spring Boot 版本，你就尽量用对应时代的 JDK。判断逻辑非常简单：javax.servlet用的是 Spring Boot 2.x，jakarta.servlet用的是 Spring Boot 3.x。
MySQL 方面，5.7 和 8.0 的差异主要集中在连接驱动。8.0 的驱动类名是com.mysql.cj.jdbc.Driver，且连接 URL 里建议加上serverTimezone=Asia/Shanghai，否则时间字段容易报错。如果你本机只有 MySQL 5.7，但源码里的驱动配置是 8.0 的类名，启动阶段就会直接报错找不到驱动类，这时候只需要把 driver-class-name 和数据库连接依赖版本统一到本机环境即可。
4.2 核心配置文件解读
项目里最重要的一个文件就是application.yml。我把它最常见的生产可运行配置列出来，配合注释看会更清晰：
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/vod_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 你自己的密码 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 500MB max-request-size: 500MB jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 file: upload-dir: D:/vod-upload/注意max-file-size和max-request-size这两项，它们决定了上传单文件的大小上限。假设max-file-size配了 500MB 而max-request-size没配，那么只有一个文件时请求体大小一般没问题，但如果你将来做多文件批量上传、或者请求里外加了 JSON 数据导致整体请求体变大，就会触发超限错误。两个值建议同时设置，并且保持一致。
Tomcat 处理 multipart 请求时还有一个隐含限制是连接超时时间。如果上传一个几百 MB 的视频文件，HTTP 请求一直处于 writing 状态，很容易超过 Tomcat 默认的 connection-timeout。这个问题在本地启动时不一定会暴露，因为本地网络快、文件写到磁盘速度也快；但如果你在远程服务器上演示，上传速度受带宽影响，很容易出现“传着传着就报连接重置”的现象。如果遇到，可以在server.tomcat.connection-timeout里适当调大，同时前端 Axios 的超时时间也要同步调大，默认的十几秒往往不够。
4.3 初始化数据库与导入准备
数据库脚本一般在源码的sql/或db/目录里，文件名多半是init.sql或vod_db.sql。导入之前先新建一个独立的数据库，命名建议和项目名一致。导入时如果本机 MySQL 版本偏高，偶尔会遇到max_allowed_packet不够导致的导入失败，这种问题只要在 mysql 客户端里临时执行一次SET GLOBAL max_allowed_packet = 1024*1024*100;一般就能解决。导入完成后，不要急着直接启动后端，先直接用 Navicat 或命令行查一下video表里有没有现成的数据，如果没有，就说明前台是空状态，需要你自己准备测试视频并上传。
这里我要重点建议：演示之前，一定要先上传两三条有代表性的视频，并且把标题取得和你的项目主题相关。很多同学答辩时因为前台页面空白，只能现教老师“你可以上传一个视频试试”，这是非常被动的。先造好数据，打开网站就有视频在首页轮播，第一印象完全不一样。
4.4 启动顺序与整体联调
整个项目的前后端联调流程，可以按下面的顺序走一遍：
第一步，启动 MySQL 服务，确认数据库可以正常连接。第二步，启动后端项目，在 IDEA 里直接运行启动类，看到日志输出 “Started VodApplication” 以及 Tomcat started on port 8080 后，后端就就绪了。第三步，打开前端工程目录，执行 npm install 安装依赖，然后执行 npm run dev 启动前端开发服务器。第四步，打开前端页面，先用注册功能创建一个账号，然后体验上传视频、观看视频、评论收藏的管理流程。
如果你拿到的源码是“前后端合并部署”的结构，也就是前端源码放在 Spring Boot 的 src/main/resources/static 下，那么你跑后端之前要去检查一下 static 目录里的文件是否已经是最新打包产物。如果是旧的前端代码，需要先npm run build把 dist 内容更新进去，再启动后端。还有一个大量项目会遇到的问题是 axios 请求的 baseURL 配置。开发阶段通常配成http://localhost:8080/api，上线后走同源路径/api。如果前后端分离启动时接口全 404，基本就是 baseURL 或者跨域配置没对上。
5. 常见问题排查与源码使用心得
5.1 版本不匹配导致编译失败
这是源码复现时出现频率最高的问题。Spring Boot 2.x 项目遇到 JDK 17 或 Spring Boot 3.x 依赖，最常见的报错是Cannot resolve javax.servlet或java: package javax.servlet does not exist。解决方案不是硬着头皮改代码，而是把编译环境降回与源码匹配的版本：Spring Boot 2.5~2.7 用 JDK 8 或 11 都能编译，Spring Boot 3.x 才需要 JDK 17。
还有一个容易被忽略的点是 Maven 镜像仓库配置。如果你在国内网络环境下直接用默认中央仓库拉依赖，下载速度可能慢到让你以为项目卡死了。最稳妥的方式是在 settings.xml 里配置阿里云 Maven 镜像。依赖下载完成后，Maven 窗口里的依赖列表就不会再报红色了。这里的核心排查思路是：先确认 JDK 版本兼容，再确认 Maven 依赖解析成功，最后才去看业务代码报错，顺序反了会浪费大量时间。
5.2 上传视频报错或超时
上传失败这类问题，排查时先看后端日志。如果日志里出现MaxUploadSizeExceededException，说明上传文件大小超过了 multipart 限制，需要先确认是不是只修改了max-file-size而忘了max-request-size。如果日志里报的是连接重置或超时异常，则优先检查前后端连接超时时间和 Tomcat connection-timeout。
如果上传接口返回 404，多半是前端把请求地址拼错了。很多项目接口前缀是/api/upload，但前端 axios 的 baseURL 已经包含了/api，结果实际请求变成/api/api/upload，后端不匹配就返回 404。这类问题用浏览器开发者工具看网络请求的完整 URL 就能立刻发现。上传成功之后，通过资源映射访问视频如果 404，那就走 3.2 节里说的资源映射路径排查，确认 Windows 和 Linux 路径差异是不是被忽略了。
5.3 视频有地址但播放不出来
视频文件能下载或者能打开 200 响应，但前端就是不播，这种情况对毕设演示来说杀伤力最强。常见的三个原因，我分别说一下典型的判断方法。
第一是拦截器把视频请求拦了。你在浏览器里直接访问视频 URL，如果返回的是 JSON 格式的提示信息而不是视频流，基本就是这个原因。解决方案是放行/upload/**路径，或者在拦截器里对 GET 请求的视频资源 URL 做白名单处理。第二是资源映射的 mime type 不对。虽然 Tomcat 默认能根据扩展名返回正确的 Content-Type，但如果资源映射配置里用了奇怪的路径转换，底层可能把它当普通二进制流返回，浏览器拿到application/octet-stream就不会直接播放。大多数开源项目不会出这个问题，但你一旦在集成一些文件服务中间件时误配了静态资源，就要回头检查响应头里的 Content-Type。第三是视频本身编码格式浏览器不支持。最简单的验证方式是换一个标准 H.264 编码的 MP4 试播，如果换了就正常，说明不是网站问题而是视频源格式问题。
前端播放器的对比和选择也值得提前测一下。有些播放器对 IE 内核、对老旧浏览器兼容性不好，在答辩电脑上可能白屏。建议提前在答辩用的那台电脑上把所有页面都过一遍，尤其是视频播放页。之前就有人因为答辩电脑浏览器太旧，播放器组件报错导致整个页面打不开，最后只能临时开无痕模式补救。这种事提前半天去排查，就完全能避免。
5.4 源码到手后，如何提升到答辩优秀水平
源码是一个及格线，把源码吃透并把项目讲活，才是拿优秀的关键。我建议你拿到源码后做这么几件事。
第一，用数据库工具把所有表都翻一遍，画一张表关系图。只要你能在答辩时画出用户表、视频表、分类表、评论表之间的关联，你就已经领先大多数只背代码的同学了。第二，找到三个最核心的代码片段，逐行研究，保证能回答出“为什么这么写”。比如登录接口里密码如何加密、JWT 如何生成、视频上传后路径如何封装，这三段代码是答辩提问的高频区。第三，准备一套固定的演示流程，并练习至少两遍。一个比较推荐的顺序是：先展示首页的效果，再演示注册登录，然后演示上传视频，接着展示视频播放和评论收藏，最后切换管理员账号，演示视频上下架和用户管理。这套流程走下来，系统功能基本都能覆盖。
如果你想让项目更有个人特色，还可以在源码基础上做一个小而低风险的扩展。比如给评论模块加一个点赞数统计，或者在后台增加一个简单的折线图展示近七天的视频新增量。这些扩展功能实现难度不大，但论文里能新增一章“系统功能扩展”，答辩时也能讲得更主动。当然，扩展的前提是不破坏原有模块的稳定性，且时间充裕。如果时间紧，老老实实把现有代码研究透彻，也完全够用。
就我个人的体会上，视频点播类毕设项目拿高分的关键，从来不在于功能有多炫酷，而在于你能不能把每个普通功能背后的方案选择讲清楚：为什么用本地存储而不是对象存储、为什么用 JWT 而不是 Session、为什么数据库不做强外键、为什么播放器不直接用原生 video。这些价值判断的表述，远比代码数量更能让评委信服。把这个思路理通，源码 16970 就不仅仅是一个能跑起来的项目，而是一套完整的、有讲述逻辑的作品。
