企业官网建设流程全解析

每年毕设季，我都能在各大平台看到大量《基于SpringBoot+Vue的XX网站设计与实现》这类题目，国产动漫网站平台就是其中出现频率非常高的一种。老实说，这个题目乍一看平平无奇——无非是前台展示番剧、后台管理数据那一套，但真正动手做下来你会发现，它几乎串联了Java Web后端就业市场上所有高频考点：前后端分离架构、RESTful接口设计、JWT登录鉴权、数据库表关系设计、文件上传、视频播放、搜索排序、评论回复。

我最近刚好完整梳理了一个基于SpringBoot+Vue的国产动漫网站平台项目，从数据库建模到接口文档编写、从后端分层到前端组件化、从本地联调到答辩演示，把整个流程重新走了一遍。这篇文章就把全过程拆开讲透，哪些表必须建、哪些代码必须先写、哪些坑会在半夜让你抓狂，都一并交代清楚。无论你是正在做这个毕设题目的在校生，还是想拿前后端分离项目练手的自学者，按这条路线走完，你得到的绝不是一个"能跑"的Demo，而是一套能讲清楚、禁得起追问的完整工程。

1. 这个题目考的是"工程能力"：国产动漫网站的真实拆解与选型逻辑

1.1 题目背后的考点：你做的不是一个"网站"，而是一整套业务闭环

很多同学拿到这个题目，第一反应是"做个展示页面嘛，放几张动漫海报，点进去能看简介就行了"。如果真这么想，那答辩的时候大概率会被问到哑口无言。国产动漫网站平台这个题目之所以被大量高校选为毕设选题，不是因为"国产动漫"这个题材本身，而是因为它天然覆盖了一个完整业务系统需要的所有模块。

拆开来看，一个合格的动漫网站至少需要三端业务闭环：C端用户端、B端管理后台、以及连接二者的服务端接口。用户端要做的是游客浏览、用户注册登录、番剧列表与详情、搜索、筛选分类、追番收藏、发表评论、播放视频；管理端要做的是管理员登录、番剧信息CRUD、分类管理、用户管理、评论审核、轮播图配置；服务端则要承担所有数据的读写、鉴权校验、文件存储、异常处理。这三块全部做完，你的项目才真正算得上"完整项目源码"。

从这个角度看，这个题目实际上是在考察你是不是具备独立完成一个中小型业务系统的工程能力。技术点反而比业务点更集中：SpringBoot做后端接口、Vue做前端页面、MySQL存数据、Redis做缓存（可选加分项）、JWT做无状态登录、Maven做依赖管理。把这些串起来，你就已经把一个典型的Java Web商用项目的工作流程完整走了一遍。

1.2 技术选型：版本、脚手架、ORM框架怎么定

版本选择是第一个容易踩坑的地方。SpringBoot 2.x和3.x之间有比较大的差异，尤其是3.x把javax.servlet换成了jakarta.servlet，很多老教程里的代码直接复制过来会报包不存在。对于毕设项目，我的建议是优先选SpringBoot 2.7.x，原因有三个：一是网上能找到的参考资料最多，遇到问题一搜就有答案；二是与MyBatis-Plus、Swagger等周边工具的兼容性最好；三是大部分学校的Java课程还停留在JDK 8，SpringBoot 2.7配合JDK 8完全够用，不会出现编译环境不一致的尴尬。

ORM框架我推荐MyBatis-Plus而不是原生MyBatis，更不是JPA。原因很简单：MyBatis-Plus提供内置的BaseMapper，单表CRUD不用写SQL，你只需要在Mapper接口里继承BaseMapper 就能拿到insert、deleteById、selectPage这些现成方法，可以把精力集中在业务逻辑而不是重复的SQL上。对于联表查询和复杂搜索，再在XML文件里手写SQL，两种方式结合，既有开发效率又不失灵活性。

构建工具选Maven，前端脚手架选Vue CLI 4或者Vite都可以。区别在于Vite启动速度确实快很多，但Vue CLI的生态和插件更成熟。如果对前端不太熟悉，建议Vue CLI，因为Element UI这类组件库的资料大多基于Vue CLI项目给出示例，照搬不容易出错。前端环境还要注意Node版本，Vue CLI 5要求Node 12以上，Vite 4要求Node 14.18以上，先把node -v看清楚再动手。

1.3 项目整体架构：前后端分离的目录规划与协作方式

目录规划决定了后续开发是顺风顺水还是处处打架。我的习惯是建一个根目录，下面分server和web两个子目录，前者放SpringBoot后端，后者放Vue前端。后端按controller、service、mapper、entity、config、common六个包来组织；前端按views、components、router、store、utils、api六个目录来组织。这种结构最大的好处是职责清晰，后端业务代码不会和配置类混在一起，前端页面组件不会和工具函数混在一起，答辩时标书翻起来也好看。

前后端协作的核心是接口约定。在实际开发中，我强烈建议先定好统一的返回格式再做具体业务。比如后端所有接口都返回一个Result 类，结构固定为code、message、data三个字段：200表示成功，401表示未登录，500表示服务器异常。前端axios在响应拦截器里统一判断code字段，而不是依赖HTTP状态码。这样前后端各做各的，只要接口文档里写清楚了请求路径、请求方式、入参和返回结构，两边可以并行开发互不阻塞。

提示：前后端分离不是把代码分成两个文件夹就完事了，真正的分离是"数据交换通过接口完成"。页面跳转不经过Controller返回的视图，而是由Vue Router控制；数据获取全部走axios调RESTful接口。如果你发现代码里有"前端跳转后端模板渲染"的混合写法，那说明分离还不够彻底。

2. 数据模型先行：从番剧到弹幕，MySQL表设计怎么做才禁得起答辩追问

2.1 核心实体梳理：用户、番剧、分类、评论的关系模型

数据库是整个项目的根基，表设计做得烂，后面写代码的时候处处别扭。国产动漫网站的核心实体有四个：用户（user）、番剧（anime）、分类（category）、评论（comment）。这四个实体的关系是：一个用户可以对多个番剧发表评论，一条评论属于一个用户和一个番剧；一个番剧属于一个分类，一个分类下可以挂多个番剧。通过外键把这几层关系串起来，业务数据就形成了基本的闭环。

用户表的核心字段包括id、username、password、nickname、avatar、email、role、status、create_time。这里要注意：password字段存的是BCrypt加密后的密文，绝对不能明文存储；role字段区分普通用户和管理员，建议用tinyint存0和1而不是字符串，方便判断；status字段控制账号是否被封禁，前端登录时后端要校验这个字段。

番剧表是内容核心，字段至少需要id、title、cover、category_id、description、director、status、rating、view_count、publish_time。其中cover存的是封面图片的URL路径，status表示连载状态（1连载中/2已完结），rating存的是综合评分（可以后续用点赞或打分计算得出）。category_id建立外键关联到分类表，方便按分类检索。还有一个容易忽略的字段是is_recommended，标记是否在首页轮播或推荐位展示。

分类表相对简单：id、name、sort。sort用来控制前端分类标签的展示顺序。评论表则要记录id、user_id、anime_id、content、parent_id、like_count、create_time。parent_id这个字段很有讲究，它支持楼中楼回复：如果为0表示一级评论，如果指向某个评论的id则表示回复。这种设计比单独搞一张回复表更轻量，也更容易实现。

2.2 扩展表设计：收藏、追番、播放记录、弹幕表的取舍

除了四个核心表，还有几张扩展表直接决定了项目的"完整度"。收藏表（favorite）记录用户的追番行为，结构很简单：id、user_id、anime_id、create_time，联合唯一索引（user_id, anime_id）防止重复收藏。播放记录表（play_history）记录每个用户看过哪些番剧，字段包括id、user_id、anime_id、episode、progress、update_time，作用是个人中心的"最近在看"模块。

弹幕表做不做是另一个取舍点。如果做了，字段包括id、anime_id、episode、user_id、content、time_point、color；time_point记录弹幕出现在视频第几秒，前端用弹幕库渲染。我个人的建议是：如果总工期还有两周以上，就做上，弹幕的实时交互效果在答辩演示时非常加分；如果时间紧张，可以不做或者只做静态展示。答辩老师往往更看重你"有没有考虑到"？而不是"功能多不多"。

这几张表都是在"基础CRUD做完之后"才需要考虑的事情。我的经验是：先把核心四张表建好、代码跑通，再回头加扩展表。因为扩展表给项目加的是宽度而不是深度，如果在初期就被扩展表分散精力，很可能连核心功能都做不完整。数据库的表数量控制在8到10张之间对毕设来说是比较合适的体量——太少显得单薄，太多管理和维护都是负担。

2.3 建库脚本的关键细节：utf8mb4、索引、初始化数据

SQL脚本是交付物的一部分，老师拿到你的项目第一件事就是执行脚本建库。如果脚本里没有初始化数据，前端页面打开是一片空白，第一印象就崩了。所以SQL脚本里必须包含三部分：建库语句、建表语句、初始数据INSERT语句。初始数据至少要准备10部以上国产动漫作品、5个以上的分类、1个管理员账号和1个普通用户账号，这些数据能让项目一启动就能完整演示。

字符集选择utf8mb4而不是utf8。很多同学在这里踩过坑：用户昵称里输入一个emoji表情，数据库直接报错无法存储。原因是utf8最多存3字节，而emoji是4字节，utf8mb4才是真正的全量支持。建表时统一写CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，所有表都用这个，一劳永逸。

索引设计是答辩可能会追问的点。番剧表上给category_id建普通索引，因为按分类查询的频率很高；评论表上给anime_id建索引，因为评论列表是按番剧维度获取的；user表上的username字段建唯一索引，保证用户名不重复。索引不是越多越好，每多一个索引，插入和更新就要多维护一份数据结构，所以只给高频查询的字段加索引才是合理的。

3. 后端骨架：SpringBoot的分层实现、JWT鉴权与那些"看似简单"的坑

3.1 三层架构与统一返回格式：先搭骨架再写业务

SpringBoot后端的核心是三层架构：Controller负责接收入参和返回结果，Service负责业务逻辑，Mapper负责数据库操作。很多初学者喜欢把业务逻辑写在Controller里，图省事，但一旦项目变大就会失控。正确做法是Controller只做三件事：接收参数、调用Service、返回Result；Service里写判断逻辑和事务控制；Mapper只做数据访问。这样每一层都好测、好改、好复用。

统一返回格式我在前面提到过，这里具体说实现。新建一个Result类，字段是code、message、data，提供静态方法success(data)和error(code, message)。Controller每个方法的返回值都写成Result类型，即使查询失败也返回结构体而不是直接抛异常。前端拿到响应后，不管成功还是失败都能用同一套逻辑处理，不需要在axios层做太多分支判断。

关于参数校验，SpringBoot有spring-boot-starter-validation依赖，可以在实体类字段上加@NotBlank、@Email、@Size等注解，Controller的入参加@Validated注解就能自动校验。比如用户注册时username不能为空、password长度至少6位、email格式要合法，这些校验不用手写if语句，注解一行就能搞定。答辩时可以顺带提一句"参数校验在Controller入口由注解驱动处理"，比说"我写了很多if判断"专业得多。

3.2 JWT登录鉴权：前后端分离项目的第一道门槛

登录鉴权是前后端分离项目绕不开的环节。传统Session方案在前后端分离下有个问题：跨域请求携带Cookie需要额外配置，而且Session存在服务器内存里，多个实例无法共享。JWT方案把用户信息加密成token字符串返回给前端，前端每次请求在Header里带上Authorization字段，后端通过拦截器解析校验，天然适合前后端分离架构。

实现逻辑拆开来就三步：登录成功后用JWT工具类生成token，把用户id、用户名、角色等非敏感信息放进claims里，签名密钥用一个固定字符串（生产环境会放到配置文件中）；前端把token存到localStorage，axios请求拦截器统一在Header中加入；后端写一个拦截器或者过滤器，对除登录注册外的所有接口执行token解析，解析失败返回401。

拦截器里要注意白名单配置：/api/user/login和/api/user/register不需要token就能访问，但首页的番剧列表是游客也能看的，所以需要区分"登录才能访问的接口"和"公开接口"。我的做法是定义两个拦截器或者一个拦截器加白名单集合，让公开接口直接放行。管理员接口再额外校验role字段是否为管理员。这里建议写一个自定义注解@RequireAdmin标注在管理端Controller上，拦截器里判断方法或类上是否有这个注解来做权限控制。

注意：JWT的密钥不要硬编码写在代码里，放到application.yml中通过@Value注入。密钥字符串至少32位，否则JJWT库启动时会报错。生成token时设置过期时间，比如24小时，前端在axios响应拦截器里捕获401后跳转到登录页并清除本地token。

3.3 文件上传：封面图和视频流的处理方案

动漫网站必然涉及封面图片上传和视频文件管理。SpringBoot默认支持文件上传，在application.yml里配置spring.servlet.multipart.max-file-size和max-request-size即可，比如分别设为50MB和100MB。Controller接收MultipartFile参数，把文件写入本地磁盘的指定目录，然后把磁盘路径拼成URL返回给前端。注意本地存储的目录是相对路径的话，要获取项目的绝对路径再拼接，否则在不同环境下启动时目录会漂移。

最容易踩的坑是上传时间长了之后，磁盘空间被占满。我见过有同学的毕设项目把整个视频文件直接存在项目目录下，演示的时候没问题，但老师问"如果上线怎么办"就答不上来了。这里我建议在答辩时主动说明：本地文件存储在毕设环境中是可接受的，生产环境一般会对接OSS或MinIO这类对象存储服务，项目里预留了存储接口的抽象层，替换实现类即可。这样既诚实又展示了你有工程化思维。

视频播放的处理也有讲究。番剧视频和普通图片不同，网页里播放MP4通常用HTML5的video标签就能搞定，但如果你拿到的是m3u8格式的流媒体切片，就需要借助hls.js或者在Vue中使用带HLS支持的前端播放器组件来处理。后端接口如果用普通文件流的方式返回视频，拖拽进度条会不流畅。最简单的方案是在后端写一个Range请求支持的下载接口，读取视频文件的字节范围返回指定片段，这样浏览器才能支持拖拽播放。

3.4 后端开发中的高频问题：跨域、事务、路径参数编码

跨域是前后端分离一定会遇到的问题。浏览器同源策略会拦截前端域名（如localhost:8080）访问后端域名（如localhost:9090）的请求。解决办法：在后端写一个CorsConfig配置类，注册CorsFilter或者实现WebMvcConfigurer的addCorsMappings方法，允许所有来源、所有方法、允许携带凭证。这里注意的是allowCredentials和allowedOriginPatterns要配合使用，allowCredentials(true)时allowedOrigins("")会被浏览器拒绝，需要用allowedOriginPatterns("")代替。

事务问题集中在评论删除和用户信息更新这类"多个表同时变更"的场景。以删除单个番剧为例，除了删除anime表里的记录，还要删除该番剧下的所有评论以及收藏记录，三条DELETE语句必须在一个事务里，任何一条失败都要全部回滚。在Service方法上加@Transactional注解就能实现声明式事务。有次我排查了一个多小时"评论删了又出现"的问题，最后发现是Service层没加事务，番剧删了但评论没删干净，重新查详情时数据又被带出来了。

路径参数编码是个很隐蔽的坑。番剧标题如果包含中文、空格或者URL特殊字符，直接拼在URL里请求会报400错误。前端在调用接口时需要用encodeURIComponent对参数编码，后端在Controller接收时用@PathVariable String title接收后，实际上SpringBoot大部分场景会自动解码，但如果你用Request的参数做精确匹配查询，最好确认一下编码和解码的一致性。我在实际项目中遇到过用户在搜索框输入"灵笼: 特别篇"带冒号导致查询无结果的情况，后来统一在搜索接口改为POST请求、参数放请求体里，才彻底避开URL编码问题。

4. 前端实战：Vue组件划分、路由守卫与播放器选型的完整思路

4.1 从页面布局反推组件设计：首页、列表页、详情页、播放页

Vue前端开发不要把每个页面都写成一个巨大的.vue文件，那样后期维护是灾难。正确做法是先画页面结构，再按功能区域拆组件。以首页为例，从上到下可以拆成NavBar导航栏、Banner轮播图、AnimeCardList番剧卡片列表、Footer底部栏；番剧详情页可以拆成InfoPanel信息面板、EpisodeList剧集列表、CommentSection评论区；播放页则拆成PlayerArea播放器区域和DanmakuPanel弹幕面板（如果做的话）。

AnimeCard是复用率最高的组件，首页推荐位、分类列表页、搜索结果显示都可以用同一套卡片组件，只需要传入一个anime对象，组件内部负责渲染封面、标题、评分、连载状态。如果出现了两个页面长得差不多但代码写了两遍的情况，说明组件拆得不够细。把公共部分抽出来，用props传参控制差异，是Vue组件化的核心思想。

视图层再往上，用Vue Router管理路由。路由表的设计要注意静态路由与动态路由的结合：首页、分类页、详情页、登录注册页这些所有人能访问的页面配置为静态路由；个人中心、播放页这些需要登录的页面通过路由守卫验证token的存在性；管理后台的页面则要额外校验用户角色。路由懒加载要用上，component写成() => import('@/views/Detail.vue')的形式，按需加载能明显减少首屏加载时间。

4.2 axios封装与拦截器：请求层必须有的统一处理

axios不能直接在每个组件里散着用，一定要封装。在utils目录下创建request.js，用axios.create()生成一个实例，设置baseURL指向后端接口地址（开发环境用Vite或Vue CLI的proxy代理，生产环境用完整URL），然后注册请求拦截器和响应拦截器。

请求拦截器里做两件事：从localStorage取出token，如果存在就在config.headers里写入Authorization: Bearer {token}；如果不存在，对于需要登录的接口可以在拦截器里直接跳转登录页。响应拦截器里判断返回的Result对象的code字段：为200则返回data部分给业务代码；为401则清除本地token并跳转登录页；为500则用Element UI的Message组件弹出错误提示。这样业务层只需要关心成功的数据流，出错逻辑全部收敛在拦截器里。

API层对应api目录下的模块文件。比如anime.js文件里导出getAnimeList(params)、getAnimeDetail(id)、searchAnime(params)等方法，每个方法内部调用封装的request实例，把HTTP请求细节藏起来。页面组件里只调用"fetchAnimeList()"这样的语义化方法，不直接面对axios——这个设计让代码可读性大幅提升，答辩演示时也能很清晰地说明"我把所有后端接口调用按模块进行了统一封装"。

4.3 登录态与权限控制：路由守卫和白名单

路由守卫是前端权限控制的第一道关。Vue Router提供了beforeEach全局前置守卫，在跳转前判断to.meta是否需要登录。我的习惯是在路由meta字段里配两个属性：requiresAuth（是否需要登录）和requiresAdmin（是否需要管理员权限）。守卫里依次判断：如果to.path是公开页面就直接放行；如果requiresAuth且没有token，跳转登录页并带上redirect参数指向原始目标；如果requiresAdmin且当前用户不是管理员，跳转首页并提示无权限。

这里有个容易疏漏的地方：用户信息除了token，还需要角色信息才能判断管理员权限。我的做法是登录成功后后端返回token和userInfo，前端把userInfo里的role存入Vuex或Pinia；刷新页面后store里的数据会丢失，所以还需要在App.vue的created生命周期里调用一次获取当前用户信息的接口（后端根据token解析用户信息）来恢复登录态。如果没有这一步，刷新页面后路由守卫会认为用户未登录，明明有token却跳回登录页，非常影响体验。

关于状态管理选Vuex还是Pinia，Vue3项目直接Pinia，Vue2项目选Vuex。其实毕设项目的状态量不大，无非是用户信息和一些全局配置，用哪个都能驾驭，但选跟当前Vue大版本匹配的方案更稳妥。Element UI（Vue2）和Element Plus（Vue3）的组件用法有细微差异，下载依赖时一定要看清版本对应关系。

4.4 播放器选型与弹幕方案：决定演示环节的上限

播放器是动漫网站的门面。原生HTML5 video标签能播MP4，但界面朴素、没有好看的进度条和音量控件。我建议直接用现成的播放器组件：Vue2生态里比较成熟的是vue-video-player，基于video.js二次封装，支持播放MP4、HLS（m3u8）、FLV等格式，进度条、倍速、全屏都内置好了。Vue3项目可以考虑DPlayer或者西瓜播放器（xgplayer），西瓜播放器的文档是中文的，接入比较简单。

弹幕功能如果要做，前端方案一般是在视频上层叠加一个canvas画布，通过定时器把弹幕渲染到canvas上。发送弹幕时调用后端接口把弹幕文本和时间点存到数据库，播放器播放到对应时间点时从本地缓存列表里取弹幕渲染。如果不想从零写弹幕渲染逻辑，B站开源的DanmakuFlameMaster在Github上有人封装过Vue版本，可以直接引用。不过以毕设的体量来说，自己写一个简单的canvas弹幕效果也是可控的，复杂度并没有想象中那么高。

播放页还有一个细节：播放进度记忆。用vue-video-player的timeupdate事件监听当前播放时间，节流后传给后端play_record接口保存；下次打开播放页时按时间戳恢复进度，并弹出"上次观看至05：23，是否继续播放"的确认按钮。这个功能不强但很显眼，演示时一下子就能让老师看出项目是完整的、深思熟虑过用户体验的。

5. 接口文档与SQL脚本：毕设包里最容易被低估的两个交付物

5.1 接口文档怎么写：不仅仅是一份Swagger注解列表

毕设题目里专门写"含接口文档"，说明接口文档被当作了独立交付物。很多同学的接口文档就是把Swagger自动生成的JSON导出来交差，但真正专业的做法是让文档可以被另一个前端开发者直接调用、不需要你口头解释任何一句。我推荐用Knife4j（Swagger的增强UI）自动生成在线文档，同时导出一份Markdown或Word版本的离线文档随项目交付。

一份合格的接口文档至少需要包含以下内容：每个接口的请求路径、请求方式、请求参数（名称、类型、是否必填、示例值）、响应结构体示例。以登录接口为例：POST /api/user/login，入参是JSON对象{username, password}，响应是{code, message, data:{token, userInfo}}；注册接口类似，但入参多一个email字段。把每个接口的请求和响应写成JSON示例，比你在答辩现场用Postman现测快得多，老师也能直观看到你设计的接口是清晰规范的。

除了自动生成，文档里还要补充一部分"设计约定"：统一返回码的含义、分页参数pageNum和pageSize的规范、时间格式统一为yyyy-MM-dd HH:mm:ss、文件上传的接口大小限制。这些约定在多人协作时尤其重要。你写文档时把它们写清楚，答辩时面试官问"前后端怎么协作"，你就可以回答"我们以接口文档为契约，后端按照约定的返回格式开发，前端根据文档mock数据进行页面开发，最后联调阶段再拉通真实接口"，这才是标准的工程化协作流程。

5.2 SQL脚本交付规范：让别人拿到就能跑

SQL脚本的交付标准是"任何一台装了MySQL的电脑双击执行就能跑起来"。第一，脚本开头要有DROP DATABASE IF EXISTS语句和CREATE DATABASE语句，避免别人库名冲突；第二，每一个CREATE TABLE语句前都有DROP TABLE IF EXISTS，保证脚本可重复执行；第三，所有表都要在末尾加上注释，字段尽量也有COMMENT注释，这是很多同学忽略的加分点；第四，初始数据的INSERT语句按依赖顺序排列，先插入分类表，再插入番剧表，最后插入评论等依赖用户和番剧的表，否则外键约束会让脚本报错。

数据初始化时还有一些细节。密码字段必须用BCrypt加密后的密文，不能直接写"123456"，否则管理员登录时后端用BCrypt校验永远对不上。你可以在SpringBoot项目的test目录里写一个临时测试类，用BCryptPasswordEncoder生成指定密码的密文，然后粘贴到SQL脚本里。番剧封面图片可以先用网络图片链接填充，比如一些公开的动漫海报URL，这样不依赖本地文件路径，前端一启动就有图可看。

提示：SQL脚本里不要写外键约束。你没看错，在DBA圈子里"外键"本身有争议，而在毕设项目里我强烈建议逻辑外键优先（程序代码里维护关联关系），物理外键不做。原因是物理外键在插入、删除时会影响性能，而且你用MyBatis-Plus做CRUD时，外键约束的存在会让一些批量操作变得麻烦。表之间有关联关系，但关联逻辑在Service层保证，这是当前主流的互联网公司做法，讲出来老师反而会觉得你了解业界实践。

5.3 数据显示与搜索优化：用现有数据讲出一个好故事

SQL脚本里初始化的数据不只是用来"让页面不空"，更是答辩时的叙事素材。我的建议是让初始数据具备"可讲性"：分类包含热血、恋爱、悬疑、搞笑、日常、科幻等六类，每类下面放两三部作品；其中至少有三部设置is_recommended为1，让首页轮播有内容；有一部作品的评论不少于五条，且包含至少一条二级回复，这样评论区功能可以直接展示完整交互效果。

搜索功能的实现也不能只是SQL的like模糊查询。前端搜索框输入关键词后，调用后端搜索接口，后端在番剧表的title和description字段上做多字段模糊匹配，按点击量排序返回。如果想加分，可以用MySQL的全文索引（ngram解析器）替代like，这样对于中文搜索的效果和性能都有提升。答辩时如果要讲"搜索优化"，就从like讲到全文索引的原理，再对比一下效果，这就是一个很扎实的技术亮点。

6. 联调、部署与答辩：把"能跑"变成"能讲清楚"

6.1 跨域联调的完整排查链路：从报错到跑通的思路

到了联调阶段，最常见的问题是前端一打开页面就报跨域错误：No 'Access-Control-Allow-Origin' header is present。这时候先别急着加各种乱改，按下面的顺序排查：

1. 先确认后端是否已配置CORS。如果没有，在后端增加CorsConfig配置类，明确允许的来源地址（如http://localhost:8080）、请求方法、请求头、是否允许携带凭证。我用到的配置是allowedOriginPatterns("http://localhost:*")加allowCredentials(true)，这样本地开发无论前端占用哪个端口都能通过。

2. 确认前端请求的baseURL是否正确。如果后端端口是9090，前端页面跑在8080，那baseURL要指向http://localhost:9090/api，注意别漏了/api前缀。一个端口错的报错和不配置CORS的报错在浏览器控制台上长得几乎一样，先排除再动配置。

3. 如果后端配了CORS还报错，把后端配置里的允许请求头加上Authorization、Content-Type，允许方法加上OPTIONS。因为浏览器跨域请求在正式请求前会先发一次OPTIONS预检，后端如果没放行OPTIONS方法，请求照样失败。

4. 还有一个备选方案：前端开发时用代理转发。Vite和Vue CLI都支持配置proxy，把 /api 前缀的请求代理到后端地址，这样浏览器访问的是同源地址，不存在跨域问题。这个方案在开发环境很舒服，生产环境也可以配合Nginx做类似的反向代理。对毕设来说，做好后端CORS加前端代理两个方案都验证过，联调时无论哪个环节出问题，你都有思路去切换。

6.2 本地部署与演示环境准备：提前把最容易翻车的环节跑一遍

答辩演示翻车大多发生在环境不一致上。你在自己电脑上跑得好好的，到答辩教室换了台机器就各种报错。提前准备好的演示环境包括：确保本机安装的JDK和项目要求版本一致，MySQL的root账号密码与项目配置文件一致，Node版本足够新可以运行前端开发环境。如果想减少现场搭建的不确定性，可以考虑打包成Jar文件后端直接java -jar运行，前端build后用Nginx或live-server静态托管，整个系统只需要一个后端进程加一个静态文件目录。

打包部署这里有个关键点：前端bundle后，请求的接口地址如果要写死为http://localhost:9090，必须在打包前修改环境变量文件。如果前后端部署在同一台机器的同一个服务下（比如后端Jar包内嵌Servlet容器同时托管前端静态资源），那前端请求用相对路径/api即可，不需要跨域。这种单服务部署模式对于毕设演示是最稳妥的，因为不依赖CORS，也不依赖多个端口同时可用。

演示时还要提前准备好几组演示账号：一个管理员账号，能展示后台管理操作；一个普通用户，能展示登录、收藏、评论、个人中心流程；再准备一个游客视角，展示未登录时能访问的页面。实际演示的操作路径要提前走三遍以上，特别是"修改番剧信息后去前端刷新看效果"这种联动操作，一旦接口某处有缓存或异步延迟，现场就会卡住几秒，很影响节奏。

6.3 答辩时项目亮点怎么讲：从功能罗列升级到"决策叙述"

答辩被追问得最频繁的问题是"你这个项目有什么亮点"。很多同学回答的是"我这个项目有登录注册、有评论、有搜索"，这只是功能罗列，没有说服力。亮的讲法是把技术决策和业务场景绑在一起叙述。比如讲登录鉴权时，说"因为采用前后端分离架构，传统Session方案跨域体验不好，而且无状态服务很难水平扩展，所以我选用了JWT方案，把用户信息编码进token，在后端拦截器统一校验"——这段话同时展示了你理解了前后端分离的痛点、理解了JWT的原理、理解了拦截器的用法。

再比如讲评论功能时，说"我设计了parent_id字段支持楼中楼回复，查询时根据是否为空判断层级，前端递归渲染评论树"。讲搜索时，说"我先用MySQL的like做模糊匹配，后来发现中文搜索效率和准确性都不够，所以调研了全文索引的方案，虽然最终项目里保留的还是接口层逻辑，但这让我理解了搜索引擎的基本原理"。即使有些优化没有彻底实现，你展现出"我思考过、我尝试过"的过程，远比"我照着教程敲了一遍"更有含金量。

还有一个加分策略：主动展示你遇到坑是怎么解决的。老师问"遇到过什么难点"时，可以讲我前面提到的两个真实经历——删番剧时评论没删干净的脏数据问题，和跨域预检请求没放行导致的联调失败。这两件事证明你是真的独立完成了整个项目，而不是从网上down了源码糊弄过关。

7. 从"复制粘贴"到"消化重构"：拿到源码后应该怎样收为己用

最后分享一点个人的真实感受。网上能搜到大量SpringBoot+Vue动漫网站的毕设源码，这是事实。但直接下载下来改个标题交上去，答辩时老师多问几个细节就会露馅。正确使用源码的方式是"消化重构"：第一遍通读代码，理清表结构、接口列表、页面跳转逻辑；第二遍挑一个自己最有兴趣的模块（比如评论或者视频播放）自己重写一遍；第三遍给项目加一个源码里没有的功能，比如个人中心里加"最近观看记录"，或者后台加一个公告发布模块。

你自己动手改过、加过代码之后，整个项目才真正变成了"你的项目"。答辩的时候你能清晰地讲出"这个模块最初是怎么实现的、我为什么觉得不够好、我是怎么改掉的"，这种话术比任何照本宣科都更有说服力。真实做过一遍的项目里，那些你踩过坑、熬夜排查过的问题，全会转化为你表述中的从容和细节——老师问什么你都能接得住，还能顺手带出几个"当时我注意到一个小细节"的加分叙事情节。

做毕设最不划算的方式是把答案背熟练去应付答辩，最划算的方式是趁这段时间把前后端分离项目里所有经典技术点亲手过一遍。国产动漫网站这个题目刚好是一个体量适中的载体，做完它，你对SpringBoot自动配置、MyBatis-Plus的使用、Vue组件通信、跨域和鉴权的理解会比看一百篇教程都深刻。希望这篇拆解能给你一条少走弯路的完整路线，等你的项目跑通的那一刻，你会觉得这段时间熬得值。