最近一段时间，前后有好几个准备做毕业设计或者课程设计的同学来找我看代码，问的最多的就是同一个方向：基于SpringBoot+Vue的电影评论网站管理系统。这东西乍一听感觉很常规，但真正从头到尾完整做一遍，你会发现它把Java后端、MySQL数据库建模、MyBatis持久层映射、Vue前端交互这几块硬通货全占了，而且每一块都能深挖不少细节。这篇文章我就把这个项目从选型思考、数据库设计、后端接口落地、前端页面编写，到最后部署踩坑的完整过程梳理一遍，适合正在做课设、毕设，或者想系统上手SpringBoot+Vue这套组合的读者参考。项目技术栈就是标题里写的那套：Java + SpringBoot + MySQL + MyBatis，前端用Vue全家桶。我会尽量把每个阶段的“为什么这么做”也讲清楚，而不是只贴代码。
先交代一下背景：我做的这套系统主要围绕“看电影、找电影、评电影”三个核心场景来设计。用户可以注册登录、浏览电影列表、查看电影详情、搜索自己感兴趣的电影，并对电影发表评论和回复，也可以收藏喜欢的电影。管理员可以维护电影信息、管理分类和用户。整个系统采用前后端分离架构，后端只提供RESTful JSON接口，前端用Vue做单页面应用，最后通过打包部署把两部分合并到一个SpringBoot进程中跑起来。
下面我会按照实际开发的顺序，把整个项目拆开来讲。这里面的不少细节，是常规文档里不会写出来的，但恰恰是你在自己动手做的时候一定会遇到的事情。
1. 为什么选这套组合：一个老项目党的选型思考
1.1 这套技术栈到底解决了什么核心问题
先说后端。很多教程还在用JSP + Servlet，或者SSH组合，不是说不能做，但那种模式的痛点太明显了：配置XML能写一大堆，启动一个Tomcat还要手动部署war包，开发的时候前后端代码全堆在一起，改个页面样式都得重启服务器。SpringBoot最直接的价值就是把“让项目能跑起来”这件事的成本大幅降低。内嵌Tomcat，自动配置数据源，引入一个spring-boot-starter-web依赖就能提供HTTP服务，配置项集中在application.yml里，这是它成为主流的原因。
再说前端。Vue的核心优势是组件化和响应式。电影评论网站这种系统，页面结构虽然不算特别复杂，但有大量列表展示、表单交互、状态切换的场景。如果用传统的jQuery操作DOM，你会发现点赞、评论、加载状态这些交互写起来很别扭，数据一变就要手动找到对应的DOM节点去改。而在Vue里，你只需要维护一个个数据对象，页面会自动跟着变，开发效率完全是另一个量级。
最后是MyBatis。Java操作MySQL这块，MyBatis被称为半自动ORM，它不会像JPA那样帮你把SQL全部生成好，而是让你自己写SQL，然后帮你完成参数映射和结果集映射。这一点在电影评论这种业务中非常友好，因为评论列表、电影列表这种查询往往涉及多表关联、动态条件、分页排序，自己掌控SQL写起来更直接，一看到SQL就知道性能瓶颈在哪。
1.2 课设、毕设和入门项目选它的真实理由
我自己做过不少这类咨询，来问这个项目的人通常看中的是三件事。
第一，技术栈覆盖面广。前端有Vue路由、组件通信、拦截器封装，后端有SpringBoot自动配置、拦截器、事务管理，再往下有MySQL表设计和MyBatis动态SQL。这一套走下来，等于把Java Web开发的主干技术都过了一遍，面试聊项目的时候不愁没东西讲。
第二，业务需求足够典型。电影评论网站里的“用户管理”“内容展示”“评论互动”“后台维护”几乎是所有管理系统项目的通用模板，你把电影换成图书、商品、课程，这套骨架依然成立。
第三，部署简单。SpringBoot打出一个Jar包，前端打包成静态文件放到后端static目录，一条java -jar命令就能起服务，不用单独配Nginx，对于毕设验收、课程报告演示来说非常友好。
1.3 版本选择：提前定好，后面省事很多
版本这块我必须重点说，因为版本选得不对，后面每一步都在填坑。如果是自己练手学习，我建议直接用相对成熟的组合，不要一上来就追最新版。
| 组件 | 推荐版本组合（稳妥型） | 说明 |
|---|---|---|
| JDK | 1.8 或 11 | SpringBoot 2.x 配套没问题 |
| SpringBoot | 2.7.x | 资料多、兼容性最好、坑最少 |
| MyBatis Starter | 2.3.x | 与SpringBoot 2.x搭配 |
| MySQL | 5.7 或 8.0 | 注意连接驱动和SSL配置 |
| Vue | 3.x + Vite | 现在新项目直接用Vue3 |
| Node | 16.x 以上 | Vite构建需要 |
如果你非要用SpringBoot 3.x，那就要接受两个变化：一是JDK必须升级到17及以上，二是原来的javax.包名全部换成了jakarta.，而且MyBatis的Starter版本也要换成对应的新版本。很多同学说“我按照网上的教程敲，怎么写完就是启动报错”，八成就是版本混搭造成的。先想清楚你要走哪条路线，再动手。
2. 数据库设计：先把表建明白，后面少写一半烂代码
2.1 核心表设计清单
电影评论网站，最简单也最合理的表结构至少需要这五张表：用户表、电影表、分类表、评论表、收藏表。我先把核心字段列出来，再说明哪些地方容易踩坑。
| 表名 | 核心字段 | 说明 |
|---|---|---|
| user | id, username, password, nickname, avatar, role, create_time | role区分普通用户和管理员 |
| category | id, name, sort | 电影分类，动作、科幻、剧情等 |
| movie | id, title, poster, director, actors, genre, summary, release_date, duration, rating, rating_count, category_id, status | rating是平均分，status控制上下架 |
| comment | id, movie_id, user_id, content, parent_id, like_count, status, create_time | parent_id实现楼中楼回复 |
| favorite | id, user_id, movie_id, create_time | 用户收藏关系表 |
设计user表的时候，password字段不要设计成varchar(50)这么抠的长度。因为你大概率会用BCrypt加密存储密码，BCrypt生成结果的长度是60位，长度不够后面做注册功能时就得回来改表结构。我当时第一次设计就犯了这个问题，结果一半的密码都存不进去，白白排查了很久。
movie表的rating字段，建议直接冗余一个平均分在电影表里，不要每次通过实时计算评论表里的评分来展示。原因很简单：MVP阶段评论量不大，实时聚合可能看不出性能问题，但电影列表页要展示几十部电影，每个都要查一次评论表求平均分，再加上排序分页，数据库压力会成倍增加。冗余评分字段，评论新增或者被删除时更新一下movie表的总分，成本非常小。
2.2 评论表设计的关键：parent_id 实现楼中楼
评论功能是这个系统最核心的部分，设计上有一个地方需要想清楚，就是评论和回复的关系。我采用的是单表自关联方案：每条评论都记录movie_id，如果它是对某条评论的回复，就通过parent_id指向被回复的评论id，顶层评论的parent_id为0或NULL。
这样做的好处是查询简单，我需要一个电影的评论墙时，直接查这个电影下的所有评论记录，然后按parent_id把它们排列成树状结构就行。从存储角度看也不需要单独建回复表，整棵评论树只用一张表维护。
但这里有个隐藏的坑：评论列表分页时，分页的是“顶级评论”，不是所有评论。如果你简单地把所有评论（包括回复）一起分页，就会出现顶层评论被拆散、回复显示不全的情况。我的处理方式是先分页查询parent_id为0的顶层评论，再把每页内被回复过的子评论查出来，按parent_id组装。如果还有嵌套回复的深度需求，通常做法是限定最多两层或者打平展示“共n条回复”，不会无限递归展示，这也是豆瓣、知乎这类产品常用的交互逻辑。
2.3 索引和MyBatis映射细节
一张表建好索引，查询性能完全是两个级别。评论表里最频繁的查询条件是movie_id，所以必须给movie_id加普通索引；收藏表里经常按user_id查收藏列表，也要建索引。不建议一开始就在联合索引上做太多文章，先把单列索引加好，等数据量真大了再根据explain结果优化。
MyBatis这边有两个配置项千万记得。第一个是settings里的mapUnderscoreToCamelCase，开启后数据库的create_time才能自动映射到Java实体的createTime。第二个是实体类里的时间字段类型，用java.time.LocalDateTime，配合MyBatis可以直接映射，不要再手动转格式。如果遇到字段名对不上，可以在XML中用resultMap显式指定映射关系，这个比在Java代码里做字段映射要清晰得多。
3. 后端落地：SpringBoot + MyBatis的核心接口拆解
3.1 分层目录结构
后端项目我习惯分成这几个包：controller、service、mapper、entity、config、common。每个包职责很明确，controller只做参数接收和结果返回，service写业务逻辑，mapper是MyBatis接口与数据库打交道，entity放实体类，config放配置类，common统一存放Result返回体和异常定义。
为什么坚持分层？因为评论网站这类系统业务不算特别复杂，但不分层的话，你会不由自主把SQL写在Controller里，后面加一个功能就要改一堆地方。分层之后，接口的职责清晰，测试也好写，就算你只是做毕设，答辩时老师问起“代码结构怎么设计的”，也能拿出一套说得过去的理由。
3.2 用户注册登录与JWT认证
用户模块的核心点有两个：密码安全存储和登录状态管理。
密码存储我用的是Spring Security里的BCryptPasswordEncoder，注意这里不是把整个Spring Security引进来做权限框架，只引入spring-security-crypto这一个工具类就行。用BCrypt是因为它自带加盐机制，相同密码每次生成的哈希值都不一样，数据库泄露也无法通过彩虹表反查明文。注册逻辑就是校验两次密码是否一致、用户名是否重复，然后加密写入。登录成功后，我生成一个JWT token返回给前端，前端后续请求在Header里带上Authorization。
JWT的拦截校验用的是SpringMVC的HandlerInterceptor。重写preHandle方法，放行登录、注册以及电影列表等公开接口，其余接口都尝试解析token，解析失败直接返回401状态码和统一错误信息。这一步做完，用户模块的状态管理就闭环了。
3.3 电影列表的模糊搜索与分页
电影模块的接口通常包括：分页列表、关键字搜索、分类筛选、详情查询。这个接口非常适合演示MyBatis的动态SQL。
<select id="selectMoviePage" resultMap="MovieResultMap"> select * from movie <where> <if test="keyword != null and keyword != ''"> and (title like concat('%', #{keyword}, '%') or actors like concat('%', #{keyword}, '%') or director like concat('%', #{keyword}, '%')) </if> <if test="categoryId != null"> and category_id = #{categoryId} </if> and status = 1 </where> order by rating desc, rating_count desc limit #{offset}, #{pageSize} </select>注意这里我没有用PageHelper插件，而是手写limit分页。原因是这个项目的查询条件不复杂，手写分页已经足够，还少了解一个第三方插件的坑。但如果你想要更标准的分页返回格式，PageHelper本身是好用的，需要注意它和动态SQL组合时Page对象的作用范围，以及count查询的性能问题。
3.4 评论模块：这个项目的灵魂
评论模块至少要提供四个接口：发表评论、回复评论、评论列表、点赞/取消点赞。
发表评论时的逻辑没有想象的那么复杂，但有两个校验必须做：一是用户是否登录，二是评论内容不能为空且不能超过合理长度。比较容易被忽略的是对电影状态的校验，已下架的电影应禁止新增评论。
评论列表接口是重点。我写的SQL是把评论表和用户表关联，一次性查出评论内容、用户名、头像、点赞数，避免在前端多处调用接口组装数据。
<select id="selectTopComments" resultMap="CommentVOResultMap"> select c.*, u.username, u.avatar from comment c left join user u on c.user_id = u.id where c.movie_id = #{movieId} and c.parent_id = 0 and c.status = 1 order by c.like_count desc, c.create_time desc limit #{offset}, #{pageSize} </select>点赞功能的难点是防重复。最简单可靠的方式是在评论表里维护like_count，并在点赞接口里加一个幂等校验：先查点赞记录是否存在，存在就提示“已点赞”，不存在才插入。如果想做得更好一点，可以单独建一张comment_like表，记录userId和commentId的唯一组合，通过数据库唯一索引来保证一个用户对一条评论只能点赞一次。这个方案可以延伸到“点踩”“收藏”等所有一对多互动场景。
3.5 统一返回体和异常处理
前后端分离项目里，接口返回格式必须统一。我定义了一个Result类，包含code、message、data三个字段。code为200表示成功，401表示未登录，500表示服务器异常。所有Controller的返回值都是Result类型，前端就能在响应拦截器里对code做统一判断，不用每个接口单独处理错误。
全局异常处理用@RestControllerAdvice加@ExceptionHandler实现。最直接的收益是，不管代码哪一层抛出异常，框架都会统一转换成Result格式返回，不会把一堆堆栈信息直接暴露给前端，既安全又省了前端对接时的麻烦。
4. 前端Vue：从路由到组件，把评论交互做出来
4.1 项目初始化与环境准备
前端我使用的是Vue 3 + Vite的组合。相比Vue CLI，Vite的冷启动速度和热更新体验快很多，而且Vite官方模板已经内置了vue-router和pinia的脚手架选项，初始化的时候顺手选上就行。Node版本建议16以上，不然Vite构建可能会提示环境不支持。
项目目录结构按功能划分：views存放页面级组件，components存放业务组件，router里配置路由，api目录统一放接口请求方法，utils里放工具函数。这个结构跟后端的分层思想是一样的，本质就是按“职责”把代码归类，避免每个人凭感觉乱放文件。
4.2 路由设计和登录守卫
页面级路由我设计如下：/代表首页，/movies是电影列表页，/movie/:id是电影详情页，/login和/register是登录注册页，/user/profile是个人中心，/admin是后台管理。列表页和详情页是公开访问的，个人中心和后台管理需要登录后进入。
vue-router的登录守卫写在路由配置文件里。给需要登录的路由加上meta: { requiresAuth: true }，然后在beforeEach里统一判断。没有token就跳转到登录页，并带上redirect参数，登录成功后自动回到原来想访问的页面。这样用户跳转体验会顺滑很多，而不是登录完还得自己重新找入口。
4.3 封装axios和接口层
所有接口请求我都走一个统一的axios实例，把baseURL设成后端的接口前缀，然后在请求拦截器里从localStorage取token塞进Header。响应拦截器里判断Result的code，如果返回401就清除本地登录信息并跳转登录页，其他错误码统一抛出提示信息。
axios封装完成之后，api目录里每个模块导出对应的方法。比如comment.js里就有getCommentList、submitComment、likeComment三个方法。页面组件里只管调用方法拿数据，完全不关心HTTP细节。这层抽象非常重要，后期如果接口路径变了，只需要改api目录里的方法，不用满页面搜索。
4.4 电影详情页和评论区的实现
电影详情页是前端开发工作量最集中的页面。上部是电影信息展示区和收藏按钮，下方分成两块：主演简介和评论区。评论区我会拆成独立的CommentSection组件，这个组件内部维护评论列表、加载状态、分页参数、输入框内容。
评论输入区域，用户输入内容后点击发布，调submitComment接口，成功后刷新评论列表。这里有一个小交互细节：发布成功后清空输入框时，要同时重置输入框的高度和placeholder状态，不然Vue复用DOM节点时可能出现样式残留。
点赞交互要注意接口的幂等性。用户点击一次点赞之后，前端立即把按钮状态置为已点赞，并调用点赞接口，后端返回普通成功信息就行。这样即使用户快速点击了两次，第二个请求也会被后端的幂等校验拦截。页面上的点赞数变化，用后端返回的最新点赞数重新赋值，而不是前端简单加一，防止数据不一致。
4.5 跨域问题和打包部署
开发模式下，Vite默认端口是5173，后端是8080，前端请求后端必然遇到跨域。我建议用Vite的proxy代理解决，在vite.config.js里配置：
server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }用了代理之后，前端请求的baseURL就写'/api'，开发时由Vite转发，部署时由后端自己处理，不用改任何一行业务代码。这种方式比后端开启CORS配置要干净，也不需要后端把允许来源写死。
部署阶段，前端执行npm run build，把生成的dist目录里的内容拷贝到SpringBoot的src/main/resources/static目录下，重新打包后端即可。这一步要特别注意路由模式的问题：Vue Router的history模式在刷新二级页面时会出现404，因为后端没有对应的路径处理。解决办法是后端写一个简单的路由转发，把除了/api之外的请求都转发到index.html。如果你不想处理这个逻辑，最简单就是用hash模式，URL里会多一个#号，功能不受影响。
5. 遇到过的坑：版本、配置、打包，三次真实排错经历
5.1 SpringBoot 3.x升级带来的“连锁反应”
有一段时间我图新鲜，把项目骨架建成了SpringBoot 3.2，结果项目里引入MyBatis和MySQL驱动的时候踩了一连串坑。SpringBoot 3.x强制要求JDK 17，如果本机还是JDK 8，项目根本编译不了。然后原来的spring-boot-starter-web里涉及javax.servlet的地方全部变成了jakarta.servlet，一些老教程里自定义拦截器方式的代码直接编译报错。
最关键的是，MyBatis的Start包当时很多版本没有跟上SpringBoot 3的依赖管理体系，直到2.3.2之后才全面兼容。如果用了旧版本starter，启动时可能报NoClassDefFoundError一类的问题。我的建议是：如果你不是非要研究新特性，做这个电影评论系统用SpringBoot 2.7.x就够了，等熟悉整套流程之后再升级也不迟。
5.2 MySQL连接的三连坑：SSL、时区、驱动类
MySQL 8.0之后，连接配置写不对，启动报错一个接一个。
第一个常见报错是java.sql.SQLException: The server time zone value '�й���ʱ��' is unrecognized。这是时报错意味着MySQL返回的服务器时区中文信息在驱动解析时乱码了。解决方案在连接串上强制指定时区：
jdbc:mysql://localhost:3306/movie_comment?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai第二个常见的报错是关于SSL的，控制台会提示Establishing SSL connection without server's identity verification is not recommended。如果只是本地开发，直接加useSSL=false关闭SSL校验就行。如果是线上生产环境，建议正确配置证书，不要盲目关闭。
第三个坑是驱动类名。MySQL 5.7时代用com.mysql.jdbc.Driver，MySQL 8.0之后改成com.mysql.cj.jdbc.Driver。很多老资料还写着旧类名，用新驱动时启动就会提示加载不了类。
5.3 MyBatis报错：Invalid bound statement
这个错误非常经典。代码没有报编译错误，但一调用Mapper接口就提示Invalid bound statement (not found)，原因是Mapper接口的XML文件没有和接口正确绑定。常见的解决办法有两步：
第一步，检查MyBatis的mapper-locations配置。在application.yml里设置：
mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.movie.entity第二步，检查XML文件中的namespace是否指向了Mapper接口的全限定名。这一步经常被忽略，namespace写错一个字母，启动不报错，运行时就是找不到。
如果以上配置都对，还要确保target/classes目录下真的编译出了对应的XML文件。有时候IDEA会默认不把src/main/java下的XML打包，你需要把这类型文件也标记成资源目录，或者统一放到resources/mapper目录下。
5.4 Vue打包放进SpringBoot后刷新404
这个问题是部署阶段的“最后一公里”。前后端整合完成后，首页正常打开，但一旦用户停留在某个详情页按F5刷新，后端就会返回404。
原因前面已经提到，Vue Router的history模式依赖前端路由布局，后端没有对应路径的处理器。我的解决办法是在SpringBoot中加一个最简单的转发Controller，把没有匹配到API的请求转发到index.html。也可以用实现WebMvcConfigurer的方式，写一个视图映射规则，把非/api路径统一forward到/index.html。这个坑排查起来不复杂，但很多同学部署时第一次遇到会一头雾水，我特意把它写出来，希望看到这篇文章的人能少走这一步。
6. 系统做完了，怎么扩展才值回票价
6.1 值得尝试的扩展方向
电影评论系统做完基础功能之后，有很多方向发展，我挑几个性价比高的说一下。
第一个方向是加Redis缓存。评论排行榜、热门电影列表、电影详情这类数据读多写少，非常适合放到Redis。把热点数据缓存之后，数据库的压力会明显下降。顺带还能把评论的点赞做异步化，先更新Redis的计数，再定时批量回写数据库。
第二个方向是文件上传。电影海报目前如果是用静态URL写死，可以扩展成集成MinIO或阿里云OSS。MinIO的好处是私有化部署，跟SpringBoot集成很直接，上传接口的逻辑就是用客户端SDK拿一个上传凭证，然后把文件流交给存储服务，数据库里只存返回的文件路径。
第三个方向是视频预告片。如果网站想加入预告片播放功能，可以用M3U8切片方案，后端把视频转码切片之后通过流媒体服务输出，前端用支持M3U8的Web播放器直接播放，不需要额外安装浏览器插件。加上弹幕功能的话，这个项目就会更有看点。
第四个方向是内容分词和标签推荐。利用HanLP分词对电影剧情简介做关键词提取，把提取出的标签和用户历史评论、收藏行为做简单匹配，就能实现一个基于内容的推荐雏形。这个扩展写进论文里会很出彩，因为已经带上了简单的算法成分。
6.2 面试时怎么把这个项目讲出彩
项目做完不只是为了应付答辩，面试时它就是你最有分量的谈资。我建议准备两套讲法。
第一套面向技术细节。重点讲数据库表设计时为什么用parent_id做评论回复、点赞功能如何利用唯一索引防重、MyBatis的动态SQL如何保证搜索条件灵活组合、JWT拦截器和Vue路由守卫如何配合完成登录态控制，以及前端刷新404问题是怎么解决的。这些都是面试官真正关心的细节。
第二套面向系统思考。你可以聊一聊数据量大之后怎么优化：评论表可以按movie_id做水平分表，电影列表页的热点数据可以加缓存，图片和视频考虑迁移到对象存储，前后端分离架构下怎么做接口版本管理。哪怕只是概念层面的理解，也能让面试官觉得你不只是会调接口，而是真的在思考一个系统从0到1再到100的过程。
从技术栈的选择，到数据库的表结构，再到前后端联调和部署排错，整套流程走下来，我对SpringBoot + Vue这套组合的理解比光看教程要深入很多。很多报错网上查的时候觉得烦，但正是这些报错把框架背后的原理一点点带了出来。如果你也在做类似的系统，建议别只满足于“跑通了就交差”，把每一步为什么这样做想明白，收获会大得多。最后再分享一个小技巧：这个项目里所有涉及时间展示的地方，前后端最好统一用时间戳或者标准字符串传输，前端再统一格式化，不要一会儿传Date一会儿传String，不然到联调阶段你会多花很多时间处理时间偏移的bug。
