企业官网建设流程全解析

每年这个时候，我都会遇到一堆被毕业设计折磨得睡不着的学弟学妹。你说难吧，其实大部分选题翻来覆去就那么几个方向；你说容易吧，可真要动手做，光是"SpringBoot + Vue"这套组合怎么把前后端串起来，就够人折腾好几天的。今天想聊的，是我带过的一个非常有代表性的项目——基于SpringBoot + Vue的校园视频平台系统，这个选题几乎是计算机毕业设计里"性价比"最高的一类：需求好理解、技术栈主流、展示效果好，而且源码、数据库、文档这三件套都能完整落地。这篇文章我不会给你贴一整份代码，而是把我从选题、建表、写接口、搭前端、到最后整理文档和准备答辩的全过程拆开讲清楚，你参考着做，基本能把毕业设计这条路走顺。

1. 毕业设计选题背后的门道：为什么视频平台是个"稳妥又能出彩"的选择

1.1 "视频平台"这类项目的真实定位

先说实话，每年毕业设计题目里，视频类网站出现的频率非常高，学校老师也愿意接受，因为它天然是一个前后端分离的完整业务系统，包含用户、内容、交互、数据统计等要素，把你在学校学的Java、SpringBoot、Vue、MySQL几乎全串了一遍。

但这恰恰也是很多人做不好的原因。我见过太多同学上来就照着网上某个视频网站源码抄，功能倒是很多，弹幕、推荐算法、分布式文件存储全往里塞，结果论文写不明白、答辩被一问就卡壳，甚至数据库和代码对不上。你要明白一个原则：毕业设计的核心不是功能越多越好，而是每一块功能你都能讲清楚"为什么这样做"。

所以我做这个校园视频平台时，给自己的定位很明确：它要像一个"校园版B站"的简化体，核心是围绕视频的完整生命周期，从投稿、审核（可选）、浏览、播放，到评论互动和个人中心。这套需求覆盖了数据库设计的关联关系、文件上传处理、前端视频播放组件等关键考点，又不会复杂到失控。

1.2 把"做一个视频网站"翻译成功能清单

需求拆解是第一步，也是很多同学最偷懒的一步。你直接跟导师说"我要做一个视频平台"，导师只会觉得你没想清楚。但如果你拿出一份清晰的用户角色和功能清单，情况就完全不同。

这个系统我分成了两类角色：

• 普通用户（学生）：注册登录、浏览视频列表、按分类筛选、搜索视频、播放视频、点赞/评论/收藏视频、查看个人中心（我的发布、我的收藏、浏览历史）。
• 管理员：登录后台、用户管理（禁用/启用）、视频管理（审核、上下架、删除）、分类管理（增删改分类）、数据统计（视频总数、用户总数、播放量排行）。

你把这十几个功能点列给导师看，他基本就明白你做的是一个完整的管理系统，而不是一个单纯的展示页面。这种"角色 + 功能矩阵"的拆解方式，本身也是你论文里需求分析章节的雏形，一举两得。

1.3 功能范围的取舍：先学会做减法

一定要学会砍需求。我见过很多同学一开始想做"视频去重""个性化推荐"甚至"在线剪辑"，这些在毕设周期里基本都是坑。视频去重涉及特征提取算法，推荐系统需要相当的数据量支撑，在线剪辑更是前端大工程，任何一个都可能吃掉你两三个月。

我当时做的取舍是：核心必做功能12个左右，加分项只做了两个——一个是"播放量排行"，本质上是一条SQL分组统计，却能让首页看起来很有说服力；另一个是"用户浏览历史"，就是往一张表里插记录再按时间倒序查，代码量很小但很能体现"系统完整性"。至于弹幕、私信、消息通知，全部砍掉，答辩时如果老师问"为什么没有弹幕"，你可以理直气壮地说"这是后续可扩展方向"，这反而显得你有思考。

提示：拿到任何选题，第一件事不是找源码，而是列功能清单，给自己定一个"必做清单"和一个"砍掉清单"，后面所有工作都会快很多。

2. 技术选型不是越新越好：SpringBoot + Vue组合的硬道理

2.1 后端选型：SpringBoot为什么是毕业设计的最优解

我先说结论：如果你的毕业设计是这种业务管理系统，SpringBoot是当前最稳妥的选择，没有之一。

为什么？首先是生态成熟。网上关于SpringBoot的资料多到你看不完，任何报错基本都能搜到解决方案。其次是它和"前后端分离"这个架构天然契合，你用@RestController返回JSON，前端拿axios一接，逻辑非常直白。再有就是面试和答辩环节，SpringBoot几乎是Java岗位的基础门槛，你做这个项目顺带把Spring的IOC、AOP、自动装配这些概念也复习了。

我在搭建环境时用的是SpringBoot 2.7.x版本，没选3.x。原因很简单：很多教学资料、网上开源代码还停留在2.x，用3.x可能会遇到Servlet API变化、javax命名空间变成jakarta这些破事，纯属给自己增加麻烦。毕设不是追求最新，是追求顺利跑通。

2.2 前端选型：Vue的组件化在视频场景里的具体好处

前端选Vue，理由同样实在。Vue的学习曲线相对平缓，你只要理解了"数据驱动视图"——数据变、页面自动变——就已经能应付80%的页面场景。

在视频平台这个项目里，Vue组件化的优势体现得特别明显。你可以抽出几个通用组件：

• VideoCard.vue：视频封面卡片，带标题、播放量、作者头像，在首页、分类页、搜索页、个人中心里到处复用；
• VideoPlayer.vue：封装视频播放器，处理播放地址格式和封面显示；
• CommentList.vue：评论区组件，接收视频ID，加载评论列表。

这种组件化结构的好处，不仅是你写代码的时候少复制粘贴，更重要的是写论文系统设计章节的时候，你可以画一个组件树，描述"本系统采用了组件化开发思想"，这是很标准的得分点。

版本方面，我用的是Vue 2.6 + Element UI。我知道Vue 3 + Element Plus已经很普及了，但如果你的参考源码大多基于Vue 2，跟着走会更稳。说到底，毕设的评分标准里，"功能完整、能跑、能讲清楚"永远排在技术栈新旧前面。

2.3 存储与中间件选型：MySQL + 本地文件存储就够了吗

这可能是很多同学最纠结的一个问题：视频文件到底存哪里？

常见的方案有几种：存服务器本地磁盘、用FastDFS/MinIO搭分布式文件系统、用阿里云OSS。我在设计时选择了最朴素的方案——存本地磁盘，配合一个虚拟路径映射规则。原因也很现实：分布式文件系统本身就是一个独立的大课题，你的毕设是视频平台不是文件系统，引入MinIO意味着你还要维护一个新的服务端，部署和答辩的复杂度都上升了。

我的做法是在服务器上约定一个upload/video/目录，数据库里存相对路径/upload/video/20240501/xxx.mp4，前端播放时拼上服务器地址就能访问。SpringBoot配置了WebMvcConfigurer中的资源映射，把本机路径映射到/upload/**这个URL规则上，代码量也就十几行。

至于数据库，MySQL 8.0就够用了，MySQL 5.7也行，只要注意连接串里的serverTimezone=Asia/Shanghai这个参数，不然时间字段的时区能坑你一整天。

2.4 版本锁定与环境配置的坑

这部分我不说虚的，直接晒几个我实际踩过、也看着学生踩过的坑：

• JDK版本：SpringBoot 2.7建议用JDK 8或11，别用JDK 17。虽然17理论能跑，但某些依赖反射操作的库会报"cannot access class"之类的错误。
• Node版本：Vue 2项目建议Node 14~16，太高版本会碰到opensslErrorOptions错误，这是Vue 2老项目的经典问题。万一真遇到了，解决办法是在package.json的scripts里加上一句set NODE_OPTIONS=--openssl-legacy-provider（Windows）或NODE_OPTIONS=--openssl-legacy-provider（Mac/Linux）。
• 数据库编码：建库时统一用utf8mb4，不要用utf8。因为用户昵称、评论里很可能会有emoji，utf8存不下，插入时报错会让你排查很久。
• 端口冲突：前后端分离开发时，前端Vue默认8080端口，后端SpringBoot默认8080，肯定会冲突。我在application.yml里把后端改成server.port: 9090，并且在Vue的vue.config.js里配置了代理转发/api到localhost:9090，这样开发环境不用天天处理跨域。

提示：毕业设计环境配置的核心原则是"锁版本、统一编码、调端口"，这三个坑排完，你的环境就已经比大多数同学干净了。

3. 数据库设计：视频类系统的表结构到底该怎么画

3.1 核心表拆解

数据库设计是整个项目的地基，地基歪了，后面写什么代码都别扭。我按照"一个用户、一个视频、一个交互链"的思路，最后形成了6张核心表：

你会发现这套表结构没有太多花哨的东西，完全基于第一范式（字段不可再分）和第二范式（非主键字段依赖主键）来设计。论文里的数据库设计章节，你完全可以从范式角度去分析每张表的设计依据。

3.2 外键、索引与字段设计的实操考量

一个容易忽略的点是：物理外键到底要不要加？很多教学案例里用FOREIGN KEY把表关联起来，但实际项目里开发时我倾向于不加物理外键，而是用逻辑外键（也就是在Java代码里通过关联ID手动查询）。原因有两个：

第一，物理外键在删除时容易触发约束错误，比如你要删一个视频分类，但该分类下还有视频，外键约束会直接报错，你还得先写一堆"判断有没有子记录"的逻辑；第二，性能上外键会影响插入和删除的效率。当然，为了应付答辩检查，我会回答："表设计上存在外键关联关系，但在实现层面通过应用层逻辑维护，避免物理外键带来的耦合与性能损耗。"这个回答既懂行又不失分。

索引的设计我比较克制，只在高频查询字段上建立了索引：video表的category_id、user_id，comment表的video_id，favorite表的user_id + video_id联合索引（保证同一用户不会重复收藏同一视频，顺带实现了收藏的唯一性约束）。不过度建索引是因为视频表的数据量在毕设阶段最多几百条，索引太多了反而浪费空间和写入资源。

3.3 初始化数据与SQL脚本的准备

这部分我要特别强调，因为导师看源码时一定会打开数据库看你的数据。

你不可能让老师自己去注册几个账号、发几个视频来测试系统，所以一定要准备一份初始化SQL脚本，里面包含：

• 默认管理员账号：admin / 123456，角色是1（管理员）；
• 测试学生账号两三个；
• 5~8条分类数据，比如编程学习、校园生活、音乐舞蹈、游戏娱乐、考研考证等，一定要贴合校园场景；
• 每个分类下至少两条视频数据，视频URL和封面图可以先用占位地址，真实演示时再上传本地视频。

这套初始化数据就是你的"演示弹药"，它对答辩的意义甚至超过源码本身。我见过太多人演示时临时注册账号、发现数据库里空空如也、上传视频又卡住，场面非常尴尬。而这些初始化数据，也会在论文的"系统测试"章节里变成测试用例的数据基础。

4. 核心功能实现：从上传视频到播放页面的完整链路

4.1 视频上传接口：最容易被忽略的缓冲区问题

视频上传是整个项目里"看起来简单、实际坑不少"的环节。你写一个普通的MultipartFile接收上传接口不难，但有几个细节是必须处理的：

第一是文件类型与大小校验。不能只在前端限制，后端也必须兜底。我在后端做了两重校验：后缀名单（.mp4、.avi、.mov等）和大小限制（单个视频不超过500MB）。SpringBoot配置里有一个spring.servlet.multipart.max-file-size参数，默认才1MB，你不改的话，上传大一点的文件直接报MaxUploadSizeExceededException，这个错误极其经典，搜一下你就明白了。

第二是文件名的处理。我不用用户的原始文件名，而是用UUID + 时间戳重新生成，比如20240501120130-a1b2c3d4.mp4。原因很简单：中文文件名在不同系统间容易乱码，并且同名文件会互相覆盖。当你用UUID生成时，就彻底规避了这个隐患。

第三是目录按月分文件夹，比如/upload/video/202405/下存当前月份的视频。这不是什么高深技巧，纯粹是为了后期维护方便——你答辩时如果老师问"文件怎么管理"，你就可以说"采用时间维度分目录存储，便于归档和检索"，这就是工程化思维。

4.2 视频播放与封面展示

视频播放这块，前端我用的是原生<video>标签配合vue-video-player（其实就是一个封装好的播放器组件）。你只需要给它一个src地址，它就能播放，省去自己处理播放逻辑的麻烦。

这里有个关键点：视频的播放地址绝不能是本地文件路径，必须是后端能访问到的URL。我在上传时把文件存到本地磁盘，同时在数据库里存的是/upload/video/202405/xxx.mp4这样的相对路径，前端拿到这个路径后，拼上后端服务器地址（开发时是http://localhost:9090），就能得到完整播放地址。

封面的处理更简单粗暴：用户上传视频时可以同时上传一张封面图，如果没传，就默认用视频第一帧或者一张静态占位图。我做的方案是允许上传封面，同时在前端VideoCard组件里设置一个默认封面位，没传的用默认图，这样首页就不会出现一大片灰块。

4.3 评论、点赞、收藏：把"交互"做成一套清晰的数据流

这三个功能非常能体现你对"数据库关联查询"的掌握程度，也是答辩时老师最爱问的。我逐个说。

点赞：我用的是like_record表（id, user_id, video_id, create_time），点击点赞时先查有没有记录，有则取消（删除记录），没有则插入，这就是一个经典的反向操作。同时维护video表里的like_count字段，每次操作后update一下。你可能会问"为什么不直接count查询"，因为频繁查询实时count在高并发下性能不行，但对于毕设来说，直接count也是一样能跑的，我选择维护计数字段，是为了论文里可以写一句"通过冗余计数字段减少统计查询开销"，这个概念在真实项目里非常常见，属于加分点。

收藏：用favorite表，逻辑几乎和点赞一样，只是语义不同。收藏表现得更"业务化"一点，因为用户收藏的东西需要有一个列表页展示，所以个人中心里"我的收藏"就是一个简单的关联查询：根据用户ID查出收藏记录，再连带查出视频信息。

评论：这是三个功能里稍微复杂一点的。我支持一级评论，也留了parent_id字段支持嵌套回复，但在实现上我做了简化——新增评论时，如果parent_id为0就是顶级评论；不为0就是回复某条评论，展示时统一按create_time倒序拉下来，前端根据parent_id来渲染缩进。要说多好谈不上，但结构上"留了扩展口"，答辩时能自圆其说。

4.4 播放量、搜索与分类筛选

播放量计数看起来不值一提，但其实有个很重要的细节：**不能在播放器每次加载视频时都播放+1，否则用户刷新一下页面，播放量就虚高了。**我当时的方案是后端提供一个"播放上报"接口，前端只在用户实际点击播放按钮时调用一次，并且用sessionStorage做标记——同一个浏览器会话内同一视频只上报一次。这个设计虽然简单，但体现了你考虑到了"数据准确性"和"防刷"这两个真实系统里的常见诉求。

搜索这一块，我直接用了MySQL的LIKE '%关键字%'做模糊查询。毕设阶段页面访问量小，这完全够用。有同学想用全文索引或者Elasticsearch，我劝你冷静——那些是生产环境面对大数据量才需要的技术，引入一个ES意味着你得额外装一个服务、维护一套配置，对毕设来说纯属负担。分类筛选就更简单了，按category_id做条件查询就行，配合MyBatis-Plus的QueryWrapper，代码量很少。

这里补充一句：MyBatis-Plus是我强烈推荐引入的ORM框架——单表CRUD几乎不用写SQL，能省下大量的体力，而且它的Page分页插件让你做分页功能只需要一行配置。这在毕设这种时间紧张的项目里是实实在在的提效工具。

5. 前端工程化与联调：Vue项目从搭建到打通前后端

5.1 页面结构与路由设计

Vue项目讲究路由规划，页面结构先理顺，后面写组件才不会乱。我的前端路由设计如下：

• /login登录页
• /首页（视频推荐列表 + 分类导航）
• /video/detail/:id视频详情页（播放器、评论、点赞、收藏）
• /video/upload视频投稿页
• /category/:id分类筛选页
• /search?keyword=xx搜索结果页
• /user/profile个人中心（基本信息、我的视频、我的收藏、浏览历史）
• /admin管理员后台（用户管理、视频管理、分类管理、统计面板）

每个页面对应一个views文件，公共部分如顶部导航栏、侧边栏，抽成components里的layout组件。这套结构没什么新鲜的，但胜在清晰，你自己写起来不迷路，论文画系统功能结构图的时候也方便。

5.2 axios封装与请求拦截

前端接后端接口必须封装axios，不要在每个组件里裸写axios.get。我封装了一个request.js，统一做了三件事：

第一，baseURL统一。开发环境走代理，也就是请求/api开头；生产环境如果前后端打包在一起部署，直接走同域。这个配置切换用一个环境变量就能搞定。

第二，请求拦截器加token。用户登录成功后后端会返回一个token，存到localStorage，每次请求都在请求头里带上Authorization: Bearer xxx，后端用一个拦截器校验。这就是最基础的登录鉴权闭环，虽然不复杂，但"在拦截器里做token注入"这种规范化写法，比你在每个组件里手写请求头要专业得多。

第三，响应拦截器统一处理错误。比如后端返回401（未登录）时，前端统一跳转登录页，而不是在每一个请求里单独处理。这类代码网上非常多，但是你要理解它的逻辑，答辩时你能说清楚"为什么用拦截器"，老师就会觉得你确实写过项目，不只是抄的。

5.3 跨域问题：一次讲透

这是联调阶段最劝退新手的一关。现象很简单：前端在localhost:8080，后端在localhost:9090，前端发请求，浏览器报错No 'Access-Control-Allow-Origin' header is present。

处理方式有两种，我的建议是开发环境用代理，生产环境用同域部署。

开发环境下，在vue.config.js里配置：

module.exports = { devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

这么配置之后，前端所有请求都写/api/login，代理会自动转发到http://localhost:9090/login并去掉/api前缀，浏览器看到的请求是同源的，就不会有跨域问题了。

生产环境呢？我把前端npm run build生成的dist文件夹直接复制到SpringBoot的src/main/resources/static目录下，然后再在Controller里用forward转发路由，这样前端页面和后端接口就在同一个服务下，根本不存在跨域。这套"打包进SpringBoot"的部署方式，网上教程一大堆，操作也很简单，但非常实用，论文的部署章节可以用一张简单的结构图说明。

6. 项目文档与答辩：源码之外最值钱的两种产出

6.1 数据库脚本怎么给老师

源码交付时，数据库脚本不是随便丢一个SQL文件就完事的。我的规范做法是：

• 单独的sql/目录，里面放两个文件：schema.sql（建库建表语句）和data.sql（初始化数据）；
• 每个表都写清字段注释，表名和字段名严格用下划线命名法，符合开发规范；
• 脚本头部注明MySQL版本和字符集要求。

老师拿到你的项目后，第一步一定是恢复数据库。如果他的MySQL版本和你的有差异，你能保证他顺利恢复吗？所以脚本里尽量少用那些"独有特性"的语法，就规规矩矩的CREATE TABLE IF NOT EXISTS和INSERT INTO，这样兼容性最好。

6.2 论文/说明文档的结构要点

文档我按这个结构来组织，这也是比较符合学校模板的一套思路：

1. 绪论：背景与意义、国内外研究现状、主要工作；
2. 需求分析：可行性分析、用户角色分析、功能需求用例、非功能需求；
3. 系统设计：总体架构、功能模块设计、数据库设计（ER图 + 表结构）；
4. 系统实现：每个模块的核心代码片段和界面截图；
5. 系统测试：测试环境、功能测试用例、测试结果；
6. 总结与展望：项目成果、不足之处、后续改进方向。

写论文时有一个很实用的技巧：**每讲一个功能模块，先放界面截图，再放核心代码，然后写50~100字解释这段代码解决了什么问题。**老师翻论文时，最怕看到大段文字没有图和代码，有了截图和代码，你的论文"工作量"一目了然，查重也不会因为直接复制别人的文字而爆表。

6.3 答辩演示的脚本设计

很多人答辩翻车，不是系统有问题，而是演示顺序乱。提前规划一条"故事线"，你15分钟的演示下来，基本就是一路高光。

我的演示顺序是：

• 先用管理员登录，展示后台数据统计面板，说出"系统共管理XX个用户、XX个视频、XX条评论"，给老师一个"该系统有真实数据支撑"的第一印象；
• 切回普通用户视角，浏览首页分类，点开一个视频，正常播放，同时点一个赞，写一条评论，展示交互功能；
• 去个人中心，展示"我的收藏"和"浏览历史"——这两个页面能直观反映你数据库表关联设计得怎么样；
• 最后演示上传一个新视频，刷新列表页，确认新视频出现，并且数据库里能查到这条记录。

这个顺序的逻辑是：**从数据看全貌，到单点看功能，再到写操作看完整闭环，最后落回到数据库验证。**老师跟着你这个节奏走，基本会对你系统形成"功能完整、逻辑清晰、数据一致"的印象。

关于答辩提问，我把自己被问过、也看着别人被问过的问题整理了一下：为什么选SpringBoot不选SSH？为什么用Vue不用React？视频文件是怎么存储的？token的时效性怎么处理的？并发量大了会有什么问题？每个问题你其实都能在这篇文章里找到对应的回答思路——重点是"讲清楚取舍理由"，而不是背定义。

7. 一些补充的工程化细节：新手最容易在收尾阶段翻车的地方

7.1 异常处理与统一返回格式

你可能已经注意到了，后端接口如果每个都直接返回各种不同的数据结构，前端联调时就要写一堆判断。我统一封装了一个Result类：code（200成功，500失败）、message、data。所有Controller都返回Result对象，前端在响应拦截器里判断code === 200再放行，非200统一弹出message提示。

后端还需要一个全局异常处理器，用@ControllerAdvice捕获业务异常和未知异常，防止把堆栈信息直接暴露给前端。这个代码量不大（大概二三十行），但对系统健壮性的提升却很明显。毕设演示的时候万一某个操作报错了，前端弹个"系统繁忙"可比浏览器控制台一屏红色报错体面多了。

7.2 防御性编程：入参校验与非法操作

举个具体例子：删除视频接口。普通写法是拿到视频ID直接调用deleteById，但这样有个问题——任何登录用户只要猜到ID就能删别人的视频。正确的做法是，先根据ID查视频，判断video.getUserId()是否等于当前登录用户的ID，是才允许删除。这就是最常见的"越权操作"防护思路，千万不要省略。同理，修改资料、删除评论也要做归属校验。老师问"系统安全性怎么考虑的"时，这些就是你最真实的素材。

再比如用户注册时，前端要校验一遍密码格式和邮箱格式，但后端@Validated注解也要加一遍。JSR-303校验（@NotBlank、@Email、@Size这些注解）是SpringBoot内置能力，几乎不增加工作量，但它是你"做的是工程化系统而不是demo"的有力证据。

7.3 打包部署：从开发环境到服务器的一次"公开演练"

毕业设计验收前，最好做一次干净环境的部署演练。我的做法是：在一台只有JDK和MySQL的全新Linux服务器上，按顺序执行：导入数据库 → 上传后端jar包并nohup java -jar启动 → 用Nginx托管前端静态文件并代理后端接口。整个过程跑通后，我把操作步骤写成一份《部署文档》，这是除了论文之外最体现工程素养的一份交付物。

为什么强调"全新环境演练"？因为你的本地开发环境装了各种东西，很多问题都被"刚好有"掩盖了。一旦换到干净环境，你才会发现少了哪些依赖、配置里哪些路径写死了、哪些参数没调对。这些都是在答辩现场可能让你当场社死的隐患，提前排掉非常值得。

8. 时间规划：三个月完成毕设的节奏参考

这部分是给现在还一脸懵的学弟学妹的。很多人的毕设周期看起来有一学期，但实际上有效工作时间可能就是最后两三周。我给你一个亲测靠谱的排期方案，按三个月来算：

• 第1~3周：确认选题、功能清单、技术选型、搭建前后端骨架。这一阶段的目标是"登录注册页面能跑起来"，这会给你巨大的正反馈；
• 第4~7周：完成数据库建表和全部后端接口。核心是video相关的增删改查和文件上传，打通"上传 → 存储 → 播放"链路。中间穿插完成用户模块和管理员模块；
• 第8~10周：前端页面全部做完，前后端联调。所有功能走一遍，修掉明显BUG，并且把初始化数据准备充分；
• 第11~12周：写论文、整理部署文档、录演示视频（如果有要求）、准备答辩PPT和讲稿。最后一周只做一件事——反复按答辩脚本演示系统，直到每个步骤都肌肉记忆。

这个排期的核心思想是：**先有能跑的最小闭环，再逐步加功能，最后留足时间写文档。**最糟糕的情况是前面逼自己完美主义改样式改了一周，结果核心功能没做完，临近提交才发现前后端还没连上。做毕设不是做产品，完成比完美重要得多。

9. 我在实际带这个项目过程中的几句心里话

做了这么多年项目，有一点我体会特别深：毕业设计的本质不是"发明一个没人做过的东西"，而是证明你已经掌握了"如何用工程方法解决一个真实问题"。校园视频平台这个题目经久不衰，就是因为它在"复杂度适中"和"技术栈主流"之间找到了一个很舒服的点位。把这篇内容里提到的功能清单、数据库表、接口设计、联调方案、文档结构真正落地，你已经能交出远超平均水平的毕设了。

最后再分享一个收尾的小建议：所有代码写完后，花半天时间把项目从零到一重新部署一遍，同时截好每一张界面截图。这些截图不仅会进论文，也是你面试时作品集的素材。很多同学做完就扔，等到找工作时才发现连一个能完整展示的项目都拿不出手。一个好的毕业设计，其实是你在大学阶段最值得沉淀的作品。把握住这次机会，后面你会感谢现在认真做事的自己。