每年毕业季我都会被同一个问题反复轰炸Java Web 毕设到底选什么题才能既过得了查重又扛得住答辩我的建议始终没变——找一个需求真实、技术栈主流、业务逻辑好讲清楚的网站平台类项目比盲目追新框架或者堆砌一堆用不上的中间件靠谱得多。这次要拆解的国产动漫网站平台就是一个非常典型的 SpringBoot Vue 前后端分离毕设项目完整源码、SQL 脚本、接口文档三件套都齐了。下文我会把选题逻辑、数据库建模、后端接口设计、前端页面组织、接口文档写法、部署答辩注意事项全部过一遍争取给你一份能直接照着做、照着讲的完整参考。1. 毕设选题逻辑与业务边界为什么国产动漫网站是好靶子1.1 选题的底层逻辑需求真实但复杂度可控毕设选题最容易犯的错是需求膨胀。上来就做电商平台、社交平台、在线教育平台听起来很唬人但到了写代码阶段你会发现权限、支付、IM、订单状态机这些旁支功能会把你的精力全部拖垮最后连核心闭环都没做完。而“动漫网站平台”这个选题的精妙之处在于它有一个非常清晰的用户心智——用户上来就是逛、搜、看详情、收藏、评论管理员就是维护内容、管用户、管评论。整个业务链路不需要“教育用户”也不需要你解释为什么要这么做。选国产动漫这个细分方向还有一层现实的考量内容素材好准备、好演示。相比于做一个空壳商城还要自己编商品数据动漫网站的封面图、简介、剧集列表在A站、B站、萌娘百科都是现成的整理筛选几十条高质量数据做成种子数据演示效果和真实产品几乎没差别。评委老师看到的是完整的内容生态而不是几张假得离谱的测试数据。另外一个隐形的加分项是查重和辨识度。做烂了的“学生信息管理系统”“图书管理系统”每年重复率惊人而动漫这个垂类有明确的差异化标签开题报告、任务书都好写得多。从导师角度看选题有明确受众和行业背景天然比“超市管理系统”有讨论空间。1.2 功能边界的划分最小闭环比大而全更重要我始终认为毕设项目的功能设计要遵循一条原则把一个核心闭环做穿而不是做一堆蜻蜓点水的功能。这个国产动漫网站平台最终敲定的功能边界是这样的前台用户端用户注册、登录密码 BCrypt 加密存储首页轮播图展示、热门榜单、最新更新、分类导航动漫列表页按分类筛选、按年份/地区筛选、分页展示动漫详情页封面、简介、剧集列表、评分展示、收藏、评论个人中心我的收藏列表、我的评论记录关键词搜索按动漫名称模糊搜索后台管理端管理员单独入口登录动漫信息管理新增、编辑、上下架、删除分类管理新增分类、编辑分类名用户管理查看用户列表、禁用账号评论管理查看评论、删除不当评论注意这里的管理端刻意没有做复杂的角色权限分级如超级管理员、运营、审核员因为毕设阶段把 RBAC 做完整是需要额外时间去堆的收益却很低。如果你有富余精力可以用一张 role 字段配合拦截器实现「普通用户」和「管理员」两级权限这已经足够覆盖绝大多数答辩老师的追问了。1.3 技术选型为什么是 SpringBoot Vue 这对黄金组合从前端到后端这套选型基本上是目前国内 Java Web 毕设的“标准答案”但我会告诉你为什么它值得选SpringBoot自动配置让项目在几分钟内起得来不需要像 SSM 时代那样写一堆 XML。Java 技术栈的市场存量摆在那里企业真实项目大量在用答辩时讲“为什么选 SpringBoot”可以说“生态成熟、快速构建、内嵌 Tomcat 简化部署”每一个理由都有实际依据支撑。Vue在国内前端框架里是绝对的普及率第一梯队。Vue 3 Vite Element Plus 的组合不仅开发体验轻快而且市面上能找到的海量组件和教程能帮你兜底。前后端分离架构本身就是答辩的技术亮点之一。MySQL MyBatis-PlusMySQL 最通用MyBatis-Plus 能帮你把单表 CRUD 的重复劳动降到最低。很多学生纠结要不要用 JPA我的看法是毕设用 MyBatis-Plus 更容易讲清楚 SQL 逻辑尤其是分页和条件查询。一句话总结这套选型全是主流全是常识没有冷门技术给自己挖坑。2. 数据库设计与 SQL 脚本核心思路从表结构到索引策略2.1 五张核心表的建模逻辑这个项目的数据库设计是整个 SQL 脚本里最重要的部分。先看核心的用户表和动漫表用户表设计CREATE TABLE user ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT 主键, username VARCHAR(50) NOT NULL UNIQUE COMMENT 用户名, password VARCHAR(255) NOT NULL COMMENT 加密密码, nickname VARCHAR(50) DEFAULT COMMENT 昵称, avatar VARCHAR(255) DEFAULT COMMENT 头像地址, role TINYINT NOT NULL DEFAULT 0 COMMENT 角色 0-普通用户 1-管理员, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态 0-正常 1-禁用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, KEY idx_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;动漫表设计CREATE TABLE anime ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT 主键, title VARCHAR(100) NOT NULL COMMENT 标题, cover_url VARCHAR(255) NOT NULL COMMENT 封面图, description TEXT COMMENT 简介, category_id INT UNSIGNED NOT NULL COMMENT 分类ID, region VARCHAR(30) DEFAULT 国产 COMMENT 地区, year SMALLINT NULL COMMENT 上映年份, status TINYINT NOT NULL DEFAULT 1 COMMENT 更新状态 0-完结 1-连载, rating DECIMAL(3,1) NOT NULL DEFAULT 0.0 COMMENT 评分, click_count INT NOT NULL DEFAULT 0 COMMENT 浏览量, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, KEY idx_category (category_id), KEY idx_year (year) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT动漫信息表;剧集表、评论表、收藏表CREATE TABLE episode ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT 主键, anime_id INT UNSIGNED NOT NULL COMMENT 动漫ID, episode_no INT NOT NULL COMMENT 集数, title VARCHAR(100) DEFAULT COMMENT 分集标题, video_url VARCHAR(255) DEFAULT COMMENT 播放地址, duration VARCHAR(20) DEFAULT COMMENT 时长, KEY idx_anime (anime_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT剧集表; CREATE TABLE comment ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT 主键, anime_id INT UNSIGNED NOT NULL COMMENT 动漫ID, user_id INT UNSIGNED NOT NULL COMMENT 用户ID, content VARCHAR(1000) NOT NULL COMMENT 评论内容, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 评论时间, KEY idx_anime (anime_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT评论表; CREATE TABLE favorite ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT 主键, user_id INT UNSIGNED NOT NULL COMMENT 用户ID, anime_id INT UNSIGNED NOT NULL COMMENT 动漫ID, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 收藏时间, UNIQUE KEY uk_user_anime (user_id, anime_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT收藏表;这几张表的关联关系非常直观用户和动漫之间通过收藏表建立多对多关系动漫和剧集是一对多动漫和评论是一对多用户和评论是一对多。整个 ER 图拢共五个实体刚好是“多但不多、深但不深”的完美结构。2.2 建模中的几个关键取舍第一剧集为什么单独建表而不塞在动漫表里有人图省事会把所有剧集拼成一个长字符串存到 anime 表里查询时再 split。这个做法在数据量小的时候够用但一旦想做分集播放、续播进度、剧集数统计字符串解析就会让你想砸键盘。单独建 episode 表每一集是独立行排序、筛选、未来对接播放器都顺理成章。第二字段类型抠门一点。评分为 DECIMAL(3,1) 而不是 FLOAT是因为浮点数在排序时会遇到精度问题9.5 和 9.45 排序容易出幺蛾子日期时间统一 DATETIME 而不是 VARCHAR因为后面要按时间倒序展示。这些都是面试时随口能讲的细节平时不注意、答辩被问住就很尴尬。第三索引策略要匹配查询模式。这个系统的高频查询有按分类刷列表、按年份筛选、查剧集、查收藏记录。所以 category_id、year、anime_id、user_id 这些字段都值得建索引。收藏表上的 UNIQUE KEY (user_id, anime_id) 一举两得——既能加速“某个用户是否收藏了某个动漫”的查询又能利用数据库约束防止重复收藏代码里连判断都不用写直接捕获 DuplicateKeyException 即可。实操下来还有一个必须强调的坑建库时一定指定 utf8mb4 字符集。很多 SQL 脚本默认继承 MySQL 的 latin1 或 utf8mb3会导致动漫标题里的特殊字符存入时报错或变问号。执行脚本前先跑一句CREATE DATABASE IF NOT EXISTS anime_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;种子数据的质量直接决定项目演示效果。我给脚本里预置了二十来个分类热血、恋爱、搞笑、悬疑、科幻、日常等、十条左右首页轮播位推荐、四十多条动漫主数据、每个动漫对应多集剧集、几十条模拟评论算下来整个 SQL 脚本大约几百条 INSERT。千万别让评审打开系统看到空空如也。3. 后端接口如何拆SpringBoot 分层架构与核心接口实现3.1 工程分层与统一响应体的设计后端工程我按标准的三层架构来组织Controller 只负责参数接收和路由分发Service 层写业务逻辑Mapper 层对接数据库。接口层的第一个统一设计是返回值规范化所有接口统一返回 Result 结构体Data public class ResultT { private Integer code; private String msg; private T data; public static T ResultT ok(T data) { ResultT result new Result(); result.setCode(200); result.setMsg(success); result.setData(data); return result; } public static T ResultT error(Integer code, String msg) { ResultT result new Result(); result.setCode(code); result.setMsg(msg); return result; } }统一响应体的价值在前后端联调时才会充分体现前端拿到任何响应先看 code 再读 data一个 axios 响应拦截器就能把所有成功和失败的逻辑统一处理掉而不是每个接口各写一套判断代码的整洁度立刻上一个档次。同理全局异常处理器也要配好不然 SQL 报错直接往页面上甩堆栈信息既危险又难看。3.2 登录鉴权JWT 拦截器够用且好讲登录模块是这个项目里绕不开的技术话题。我不建议毕设阶段上 Spring Security OAuth2 那一整套全家桶学习成本高、配置管线长答辩时一旦被追问内部原理很容易翻车。更务实的方案是JWT 自定义拦截器用户提交用户名密码Service 层用 BCrypt 校验密码注意项目里永远不要明文存储密码。登录成功后生成 JWT 令牌payload 里携带 userId 和 role设置合理过期时间比如 24 小时。前端把 token 存到 localStorage每次请求在 Authorization 请求头里带上。后端用 HandlerInterceptor 拦截需要鉴权的接口路径解析并校验 token失败统一返回 401。核心拦截器长这样Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (!StringUtils.hasText(token)) { response.setStatus(401); response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:401,\msg\:\未登录\}); return false; } try { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { response.setStatus(401); response.getWriter().write({\code\:401,\msg\:\登录已过期\}); return false; } } }这里有个细节值得在答辩时主动提除了登录、注册、首页、动漫列表、详情等公开接口收藏和评论等敏感操作的路径要单独走鉴权拦截。管理员的接口再额外判断 role 是否为 1形成两级权限控制。整体体量不大但把一个系统的权限模型讲得很完整。3.3 核心接口清单与实现要点整个后端接口罗列出来大概是以下这些模块接口地址请求方式说明用户/api/user/registerPOST注册用户/api/user/loginPOST登录返回 token 和用户信息用户/api/user/infoGET获取当前用户信息动漫/api/anime/listGET分页列表支持分类/年份筛选动漫/api/anime/searchGET按关键词搜索动漫/api/anime/detail/{id}GET详情聚合剧集列表动漫/api/anime/hotGET热门榜按浏览量倒序收藏/api/favorite/add/{animeId}POST添加收藏收藏/api/favorite/remove/{animeId}DELETE取消收藏收藏/api/favorite/listGET我的收藏评论/api/comment/list/{animeId}GET评论列表评论/api/comment/addPOST发表评论管理/api/admin/anime/savePOST新增/编辑动漫管理/api/admin/anime/delete/{id}DELETE删除动漫管理/api/admin/user/listGET用户列表管理/api/admin/comment/delete/{id}DELETE删除评论接口拆分的要点是“粒度适中”拆得太细会让前端一个页面发十几次请求拆得太粗则会导致接口职责混乱、复用性差。详情页我是刻意做了一个聚合接口一次返回动漫基本信息 剧集列表 评论数前端只需要调一次就能渲染整个详情页这个设计在答辩时是可以主动打出来的亮点。实现层面上MyBatis-Plus 的条件构造器非常省力。比如分页筛选接口用 LambdaQueryWrapper 动态拼接条件代码短且可读性好Override public PageAnime getAnimeList(AnimeQueryVO query) { LambdaQueryWrapperAnime wrapper new LambdaQueryWrapper(); wrapper.eq(query.getCategoryId() ! null, Anime::getCategoryId, query.getCategoryId()) .eq(query.getYear() ! null, Anime::getYear, query.getYear()) .eq(query.getStatus() ! null, Anime::getStatus, query.getStatus()) .like(StringUtils.hasText(query.getKeyword()), Anime::getTitle, query.getKeyword()) .orderByDesc(Anime::getCreateTime); return animeMapper.selectPage(new Page(query.getPageNum(), query.getPageSize()), wrapper); }热门榜更简单按 click_count 倒序取十条就行。每次访问详情页给 click_count 加一排行榜就自然有了数据来源。3.4 一个值得注意的 bug 经验时间字段序列化这类项目在联调时最容易出现的一个怪问题是接口返回的时间字段格式变成了Sep 29, 2025 3:22:03 PM这种英文格式或者干脆是一长串时间戳。原因是 Jackson 默认序列化方式跟本地格式不一致。我在项目里加了统一配置把日期格式钉死为yyyy-MM-dd HH:mm:ssspring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这事属于“不配不算错配了是亮点”的典型对线上的展示效果影响极大建议拿到任何源码后第一时间检查这一项。4. 前端 Vue 项目组织与联调中的高频翻车点4.1 工程结构与路由设计前端用 Vite 创建 Vue 3 工程配套 Vue Router 4、Pinia、Axios、Element Plus。目录结构建议拆成下面这样前后端联调时你会感谢当初结构分得清楚src/ ├── api/ # 按模块封装的接口请求 │ ├── anime.js │ ├── user.js │ ├── comment.js │ └── favorite.js ├── router/ # 路由配置与守卫 ├── store/ # Pinia 用户状态 ├── utils/request.js # axios 实例封装 ├── views/ │ ├── Home.vue # 首页 │ ├── AnimeList.vue # 列表页 │ ├── AnimeDetail.vue # 详情页 │ ├── Login.vue # 登录注册 │ ├── Profile.vue # 个人中心 │ └── admin/ │ ├── AnimeManage.vue │ ├── UserManage.vue │ └── CommentManage.vue └── components/ # 通用组件路由使用懒加载方式引入页面组件配合前置守卫做登录态检查——这个细节做与不做系统在评委眼里完全是两个档次。// router/index.js const routes [ { path: /, component: () import(../views/Home.vue) }, { path: /list, component: () import(../views/AnimeList.vue) }, { path: /detail/:id, component: () import(../views/AnimeDetail.vue) }, { path: /login, component: () import(../views/Login.vue) }, { path: /admin, component: () import(../views/admin/AnimeManage.vue), meta: { requireAuth: true, role: 1 } } ] router.beforeEach((to, from, next) { const userStore useUserStore() if (to.meta.requireAuth !userStore.isLogin) { next(/login) return } if (to.meta.role ! undefined userStore.role ! to.meta.role) { next(/) return } next() })4.2 Axios 封装拦截器里藏着联调的命根子前后端分离项目联调出问题十有八九出在请求封装不规范。我的做法是把 axios 实例的创建、请求拦截、响应拦截统一收敛到一个文件里这样任何页面都只需要import request from /utils/request然后调方法错误弹窗和登录超时跳转都不用每个页面重复写。// utils/request.js import axios from axios import { ElMessage } from element-plus import router from /router import { useUserStore } from /store/user const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization userStore.token } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg)) } return res }, error { if (error.response error.response.status 401) { ElMessage.error(登录已过期请重新登录) const userStore useUserStore() userStore.clearUser() router.push(/login) } else { ElMessage.error(网络异常请稍后重试) } return Promise.reject(error) } ) export default request单独把 401 的全局处理拎出来是因为 JWT 过期后如果每个页面各处理一遍代码会重复到怀疑人生。在这个拦截器里统一处理token 失效的体验立刻变成“弹个提示、清空状态、踢回登录页”非常顺滑。4.3 跨域与代理配置开发环境最常见的拦路虎前端工程默认跑在 5173 端口后端 SpringBoot 跑在 8080跨域问题躲不掉。解决跨域的方式有三种后端加 CORS 配置、前端 Vite 开发代理、生产环境 Nginx 反向代理。我推荐前后端分离项目用“开发代理 生产 Nginx”的组合拳而不是在后端硬开 CORS——因为生产环境里 Nginx 代理后根本不存在跨域后端开 CORS 反而是多余的暴露。Vite 代理配置非常简洁// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })注意这里有个坑代理路径的 target 不能带/api前缀否则会把路径改写成http://localhost:8080/api/api/...接口直接 404。这个错误我见过不止一两次每次联调无头绪时先检查代理配置。生产环境的 Nginx 配置片段参考server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080; } }try_files那行是为了支持 Vue Router 的 history 模式否则刷新详情页路由地址时会直接 404这又是另一个不容易被想到的小坑。4.4 页面交互的设计细节收藏、评论、搜索首页和详情页是最先被评委看到的部分交互顺手度直接拉高印象分。我重点打磨了这么几个点收藏按钮进入详情页时先调一个“是否已收藏”的校验接口按钮呈现两种状态。未登录时点击收藏不报错而是跳转登录页让引导自然发生。评论区的输入状态先判断是否登录已登录直接给输入框未登录在输入框位置放一个“登录后参与讨论”的提示按钮。这个设计避免了大量“评论报 401”的尴尬。搜索搜索输入框放到导航栏里敲回车跳转到列表页并带上 keyword 参数列表页初始化时读取路由参数填充搜索框。这样搜索和筛选是同一套列表页逻辑代码复用率高。还有一个很实际的要点图片资源不要全部丢在项目本地。毕设项目换电脑演示时本地路径一旦变化封面图全裂。更好的选择是把封面图统一传到图床或者对象存储数据库里存完整 URL。你用现成的免费图床也好用阿里云 OSS 的临时测试 bucket 也行总之不要用本地相对路径。这也是我在演示现场踩过最尴尬的坑。5. 接口文档的写法让答辩老师一眼看懂你的系统5.1 接口文档不是写给机器的是写给人看的很多同学认为接口文档可有可无反正前端都是自己写的。这是严重的认知偏差。接口文档是毕设交付物里最能体现工程素养的一项答辩老师翻源码可能没耐心但翻接口文档是可以快速建立“这人有工程习惯”印象的路径。规范的做法是每个接口包含接口地址、请求方式、是否需要登录、请求参数表、响应示例、错误码说明几个部分。我提供一个标准接口文档的片段样例你可以直接参考这个格式### 5.1.1 动漫分页列表 - 接口地址GET /api/anime/list - 是否需要登录否 - 请求参数 | 参数名 | 类型 | 必填 | 说明 | |--------|------|------|------| | categoryId | Integer | 否 | 分类ID不传查全部 | | year | Integer | 否 | 年份不传查全部 | | status | Integer | 否 | 1-连载 0-完结不传查全部 | | keyword | String | 否 | 关键词模糊搜索 | | pageNum | Integer | 是 | 页码从1开始 | | pageSize | Integer | 是 | 每页条数建议最大50 | - 响应示例 json { code: 200, msg: success, data: { total: 23, list: [ { id: 1, title: 雾山五行·犀川幻紫林, coverUrl: https://example.com/cover.jpg, categoryId: 3, status: 1, rating: 9.5, year: 2023 } ] } }错误码说明401-未登录400-参数错误500-服务器内部错误这样的文档写出来之后不但答辩老师看得舒服你写前端时自己也看得很舒服——不用靠记忆力回顾字段命名顺手查一下就明白了。 ### 5.2 用 Apifox/Postman 把调试过程沉淀成文档 写接口文档最经济的路径不是事后手动整理而是边开发边在 Apifox 或 Postman 里调接口调通之后直接把请求保存到集合。Apifox 的优势在于它同时具备接口文档、调试、Mock 数据三个能力特别适合前后端分离的开发节奏。后端同学定义好接口并导出文档前端同学可以立即打开 Mock 模式开始写页面不需要等后端全部写完。 我自己在这个项目里的做法是后端每写完一个 Controller 的接口关联到 Apifox 里标注好参数和响应示例最终交付时直接从 Apifox 导出一份 Markdown 格式的接口文档放进项目。整个过程不到半小时但交付清单里凭空多了一份“工程交付物”答辩时这句话可以大方的讲出来“接口文档是联调过程中同步维护的前后端都能基于同一份文档协作。” ### 5.3 文档之外数据库脚本和启动说明也要写清楚 除了接口文档配一份 README 启动说明是成本极低、收益极高的动作。里面至少要写清楚环境要求JDK 版本、Maven 版本、Node 版本、数据库初始化步骤执行 SQL 脚本的顺序和注意事项、后端启动命令、前端启动命令、默认管理员账号密码。 默认账号这一点容易被人忽略。很多学生交付源码时压根不交代管理员账号评审老师说“我登进去看看管理后台”结果你不知道账号密码场面一度非常尴尬。我在种子数据里固定了管理员admin / admin123 测试用户user / user123并且密码是 BCrypt 加密后的密文脚本里直接插入密文。这样既不暴露明文风险又能让别人用统一演示账号顺利进入系统。 ## 6. 源码到手之后启动部署与答辩准备的实战清单 ### 6.1 Windows 本机部署的完整步骤 不管你是自己从头写还是拿到一套完整源码第一步都是把项目在本机跑起来。这个国产动漫网站平台的启动流程其实很常规但越常规越容易在细节上卡半小时我把每一步的关键动作列出来 1. 环境准备JDK 8 或 JDK 17注意 SpringBoot 2.x 用 JDK8 没问题SpringBoot 3.x 必须 JDK17、Maven 3.6、Node 16、MySQL 5.7 或 8.x。 2. 初始化数据库在 MySQL 里执行 CREATE DATABASE anime_db DEFAULT CHARACTER SET utf8mb4;然后导入项目的 anime_db.sql 脚本。如果是用 Navicat 导入记得先切到目标库再执行不然会报 No database selected。 3. 改后端配置打开 application.yml核对数据库地址、账号、密码还有端口是否被占用。默认 8080 常见冲突源是本地其他服务占了端口换个 8081 就完事。 4. 启动后端IDEA 打开工程后等 Maven 依赖下载完成直接运行 Application 启动类。看到 Tomcat started 字样就算成功。 5. 启动前端在 frontend 目录执行 npm install然后 npm run dev。如果 node_modules 安装很慢可以先换成国内镜像源再装。 6. 浏览器访问 http://localhost:5173用 admin/admin123 登录后台试试新增一篇动漫验证前后端联通。 ### 6.2 常见启动报错的定位思路与修复方案 部署过程里最容易让新手崩溃的问题基本都是环境层面的我把高频问题整理成一张排查表 | 报错现象 | 根因 | 处理办法 | |---------|------|---------| | com.mysql.cj.jdbc.exceptions.CommunicationsExpection | MySQL 服务未启动或端口非 3306 | 启动 MySQL 服务核对 yml 端口 | | Access denied for user rootlocalhost | 数据库账号或密码错误 | 改 application.yml 中账号密码 | | java.lang.NoClassDefFoundError | Maven 依赖未完整下载或版本冲突 | 执行 mvn clean重新 Import 工程 | | npm ERR! code ERESOLVE | Node 版本偏高或依赖锁冲突 | 删 node_modules 和 package-lock.json 重装 | | 前端请求接口返回 404 | 后端接口前缀与前端代理不一致 | 检查 vite proxy 的 /api 路径和后端 context-path | | CORS 跨域报错 | 代理没生效或后端缺 CORS | 开发环境优先检查代理配置 | | 插入数据中文全部是问号 | 数据库字符集不是 utf8mb4 | 重建库并指定 utf8mb4 | 其中印象最深的一次鸡飞狗跳同学的后端用的 JDK17SpringBoot 版本还是 2.4.3启动直接报 Unsupported class file major version 61其实就是 SpringBoot 版本太老不认识新 JDK 编译出的字节码。解法很粗暴——要么把 JDK 换成 8要么把 SpringBoot 升到 2.7 以上没有第三种魔法。 ### 6.3 答辩时怎么讲这个项目三个技术亮点 源码跑通只是第一步答辩的核心是把你做的东西讲出亮点。我从这个系统里提炼出三个任何评委追问都有话可说的技术点 - **统一响应体 全局异常处理**所有接口返回结构一致前端一个拦截器处理全部业务状态全局异常处理器把系统异常和业务异常分开处理不会出现堆栈信息泄露。 - **JWT 无状态鉴权 两级权限**公开接口、用户接口、管理员接口三层路径分割登录鉴权全部收敛在拦截器里完成新增受保护接口只需要改一行业务代码不用重复写鉴权逻辑。 - **详情页聚合接口设计**一个接口返回动漫信息、剧集列表、评论数减少前端请求次数也是前后端分离架构下接口粒度设计的一个真实思考。 准备几个可能的追问方向为什么用 MySQL 不用 Oracle——轻量、免费、生态成熟毕设体量完全够用。为什么用 JWT 不用 Session——前后端分离场景下 Session 天然跨域受限JWT 把状态写在令牌里后端不需要维护会话集群部署也更友好。搜索为什么不用 Elasticsearch——数据量级在这个系统里只有几十条数据库 LIKE 查询已足够引入 ES 属于过度设计。 ### 6.4 后续扩展方向从毕设到个人项目的进阶路径 如果答辩后你还想继续打磨这个项目我建议从这几个方向里选一个深入评论审核机制加入敏感词过滤和人工审核、弹幕功能WebSocket 实现实时消息、新番更新提醒定时任务抓取更新并推送通知、个人推荐基于收藏和浏览记录做简单的协同过滤。这些方向都能让项目从“课程设计水平”跳到“接近生产环境”的水平写在简历里也更具备说服力。 拿源码之后最该做的一件事不是什么高深操作——给自己做一次全流程演示彩排。用三十分钟把游客浏览首页、注册登录、搜索动漫、查看详情、收藏、评论、切换管理员、修改动漫信息、删除违规评论从头到尾走一遍同时想清楚每一步点击背后调用了哪个接口、经过了哪些表。能把这条链路行云流水地讲下来比熟背一百个八股文都管用。