简介：一份面向计算机及相关专业学生的动漫网站毕业设计论文文档，整体定位于网站制作方向。内容系统梳理了动漫类网站从需求分析、可行性分析到系统设计、数据库设计、总体设计及最终实现与测试的完整流程，并依次介绍了MyEclipse、Tomcat、B/S结构、Oracle、Dreamweaver、JavaScript和JSP等开发工具与技术，适合正在筹备网站类毕业设计或课程设计的读者作为框架参考和写作范本。压缩包内为1个doc格式文档，整体大小约569KB，目录结构完整覆盖引言、系统概述、系统的工具选择、需求分析、可行性分析、系统设计、数据库设计、总体设计、前台页面与后台登录实现、系统测试等章节，便于快速定位论文各部分。文档采用章节式编排，方便按索引查阅各技术点和实现细节。已有2169人学习下载，对需要撰写同类论文或搭建动漫主题网站的人群具有较高的借鉴价值。
1. 动漫网站的设计与实现：毕业论文该有的技术含量
把“动漫网站的设计与实现”当毕业论文题目的人不少，但答辩现场最常见的翻车姿势是：页面能打开，数据是写死的，图片一清空就裂，评论提交直接报错，搜索框一输入中文就白屏。原因很简单——只做了“展示”，没做“实现”。这里说的实现，是从数据库表设计、后端接口、前端页面到部署联调的一条完整链路。这篇文章按我实际做过的方案，把一套能写进论文、能现场演示的动漫网站拆开讲：技术栈怎么选、表怎么建、接口怎么写、页面怎么接、哪些坑必须在答辩前踩完。适合正在准备毕业设计，或者想独立完成一个全栈项目的人读，新手能照步骤走，熟手直接看参数和边界。
2. 先定架子再写代码：技术选型与系统架构
毕设网站和企业项目的诉求不太一样：它不需要高并发，不需要微服务，但要求你自己讲得清、现场跑得动、论文里有东西可写。所以技术选型的原则不是“追新”，而是“追稳”——选你最能解释清楚的那套方案。
2.1 前后端分离为什么成为默认答案：Spring Boot + Vue 的分工
当前最常见的做法是前后端分离：后端用 Spring Boot 提供 JSON 接口，前端用 Vue 管页面交互，数据库用 MySQL。开发时两边可以并行推进，演示时只需要开一个后端服务加一个前端页面；写论文时能自然拆成“后端接口设计”和“前端页面实现”两个章节，篇幅和深度都好控制。
为什么不建议用 JSP 服务端渲染？因为当答辩老师问“前端怎么处理用户登录状态”时，JSP 方案很难把逻辑讲出层次。前后端分离后，token 存哪里、路由守卫拦哪里、接口返回 401 怎么处理，这些都能在论文里写出独立小节。另一个常见误区是做成纯静态展示站：页面再好看，数据库设计那一章没有实体可写，系统测试也没有真实请求可测，论文就成了“网页设计说明”。
我的习惯是后端框架选 Spring Boot，前端用 Vue 3 搭配 Vue Router 和 axios，不额外引重型 UI 库。原因很朴素：组件自己写才有东西写进附录，也给答辩留了提问空间。数据库连接层用 Spring Boot 自带的 JdbcTemplate 或 MyBatis 都可以，哪个熟用哪个。
2.2 从论文章节反推功能模块：功能树与数据流
写论文时最怕“系统功能”一章憋不出内容。所以动手前先反推功能模块，把整个网站拆成五个大块：用户模块、动漫模块、播放模块、互动模块、后台管理模块。用户模块管注册登录和个人中心；动漫模块管列表、详情、分类筛选和搜索；播放模块管剧集列表和播放页；互动模块管收藏、评论和评分；后台管理简化为一个数据维护页，用于添加或下架动漫条目。
这五个模块对应论文的需求分析、概要设计、详细设计、系统测试四章，每个模块都能独立描述，现场演示也能按模块逐个走。数据流主线是：用户在浏览器发起请求，前端路由判断页面，axios 把请求发到后端 Controller，Service 做业务处理，Mapper 访问 MySQL，结果再一层层返回。副线是登录后的用户态：前端把 token 存在 localStorage，每次请求带上，后端拦截器校验。这条数据流在论文里画出来，比贴十页代码更有说服力。
建议后台管理不要做太重。很多毕设把后台做成权限细分、多角色、操作日志，看着唬人，实际时间和精力都不够。后台只保留“动漫增删改查”和“评论删除”两个功能，演示时能证明“有管理能力”即可。把省下来的时间放在主流程的健壮性上。
2.3 开发顺序与目录规范：先打通哪一条链路
初次做全栈最容易犯的错是先把前端页面全部写完，再开始写后端，最后联调时发现数据结构对不上，返工量很大。正确的顺序是：先建数据库表，再写后端接口，再写前端页面，最后联调。后端的接口返回格式最好统一封装，我一般用{ code, message, data }这种结构，前端判断 code 为 0 才取数据，写起来省事，论文里也能当“统一响应设计”讲。
目录结构可以提前固定，建议直接参考下面这套：
ct-anime/ ├── backend/ │ ├── src/main/java/com/example/anime/ │ │ ├── controller/ # 接收请求，返回 JSON │ │ ├── service/ # 业务逻辑 │ │ ├── mapper/ # 数据库操作 │ │ ├── config/ # 跨域配置、拦截器注册 │ │ └── utils/ # JWT 工具、统一返回封装 │ └── src/main/resources/ │ ├── application.yml │ └── schema.sql ├── frontend/ │ ├── src/ │ │ ├── api/ # axios 请求封装 │ │ ├── router/ # 路由配置 │ │ ├── views/ # 页面组件 │ │ └── components/ # 复用组件 │ └── vite.config.js # 开发环境接口转发 └── README.md这个目录结构可以直接挪到论文的“系统实现”章节。每个 controller 对应一个模块，类和文件名能让答辩老师一眼看出分层是否清楚。开发顺序上，我建议先打通“首页列表 → 详情页 → 播放页”这条最短链路，数据用写死的模拟数据都行，链路通后再接入数据库和登录鉴权。这样每一天都有可运行的东西，情绪上不会崩。
3. 数据层与核心接口：让动漫数据有处安放
数据层是论文里最实的一部分。表设计直接写进“数据库设计”章节，接口实现对应“详细设计”章节。这一章做完，论文的核心素材就攒下一大半了。
3.1 六张核心表与主外键关系：用户、动漫、剧集、收藏、评论、评分
动漫网站的表不需要很多，核心是六张：用户表、动漫表、剧集表、收藏表、评论表、评分表。这样一个网站的闭环就完整了。下面把建表 SQL 按模块拆开，每张表字段尽量精简，够用就好。
-- 用户表 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, avatar VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 动漫主表 CREATE TABLE t_anime ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL, cover VARCHAR(255) COMMENT '封面图路径', description TEXT, category VARCHAR(50), status TINYINT DEFAULT 1 COMMENT '1连载 0完结', created_at DATETIME DEFAULT CURRENT_TIMESTAMP );上面的 SQL 里，用户表加了唯一索引防止重复注册，密码字段定长 100，因为后面要用 BCrypt 加密，加密后的字符串长度接近 60，留足余量。动漫表的 cover 字段建议存本地相对路径，不要存外站完整 URL，后面图片坑会少很多。这里先埋个伏笔，第 5 章会细讲。
-- 剧集表 CREATE TABLE t_episode ( id INT PRIMARY KEY AUTO_INCREMENT, anime_id INT NOT NULL, title VARCHAR(100) NOT NULL, video_url VARCHAR(255), sort_order INT DEFAULT 1 COMMENT '第几集', FOREIGN KEY (anime_id) REFERENCES t_anime(id) ); -- 收藏表 CREATE TABLE t_favorite ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, anime_id INT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_anime (user_id, anime_id), FOREIGN KEY (user_id) REFERENCES t_user(id), FOREIGN KEY (anime_id) REFERENCES t_anime(id) );剧集表通过 anime_id 挂到动漫主表下，一集一条记录，sort_order 控制播放顺序。收藏表用唯一约束(user_id, anime_id)防止同一个用户重复收藏，这是论文里值得写一句的设计点：联合唯一索引能直接在数据库层挡住脏数据，而不是靠业务代码判断。
评论表和评分表单独建：
-- 评论表 CREATE TABLE t_comment ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, anime_id INT NOT NULL, content VARCHAR(500) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES t_user(id), FOREIGN KEY (anime_id) REFERENCES t_anime(id) ); -- 评分表 CREATE TABLE t_rating ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, anime_id INT NOT NULL, score TINYINT NOT NULL COMMENT '1-10', UNIQUE KEY uk_user_anime (user_id, anime_id), FOREIGN KEY (user_id) REFERENCES t_user(id), FOREIGN KEY (anime_id) REFERENCES t_anime(id) );逻辑说明：评论表和评分表都保留用户和动漫两个外键。评论表不要加ON DELETE CASCADE，因为评论内容是用户产生的数据，动漫被删除时评论也应该被保留到日志里，这个设计可以在答辩时拿出来讲。评分表用 TINYINT 存 1 到 10 分，比用小数更简单，展示时再除以 2 转成 5 星制。t_anime 表里那个 rating 字段是冗余聚合值，可以在每次评分后重新计算一次，避免详情页每次都要做 AVG 聚合。
参数说明：所有时间字段统一用 DATETIME，不要用 TIMESTAMP，不然 2038 年问题在论文里说不清；字符集在创建数据库时指定 utf8mb4，因为动漫简介里常会出现特殊符号和日文假名，utf8mb4 才存得下。
3.2 初始化数据的三条路：脚本、后台、模拟组装
表建好后，第一步是往里塞数据。常见做法有三条：直接写 SQL 脚本插入、通过后台管理页录入、写一段初始化代码在项目启动时自动填充。对于毕设，我的建议是三条结合：SQL 脚本保证演示数据能被重复还原，后台录入用来证明管理功能可用，启动初始化适合生成大量模拟评论。
SQL 脚本插入最直接，适合放一批动漫基础数据：
INSERT INTO t_anime (title, cover, description, category, status) VALUES ('演示作品A', '/images/anime/a.jpg', '这是一个用于演示的动漫条目。', '热血', 1), ('演示作品B', '/images/anime/b.jpg', '这是一个日常题材的演示条目。', '日常', 0), ('演示作品C', '/images/anime/c.jpg', '这是科幻题材的演示条目。', '科幻', 1); INSERT INTO t_episode (anime_id, title, video_url, sort_order) VALUES (1, '第1集', '/videos/a_01.mp4', 1), (1, '第2集', '/videos/a_02.mp4', 2), (2, '第1集', '/videos/b_01.mp4', 1);逻辑说明：动漫表和剧集表分开插入，主键通过顺序对应，脚本简单粗暴但有效。字段注释已经写清含义。注意这里的封面和视频路径都是本地相对路径，不是外站地址，这样换机器演示时才不会因为链接失效变成裂图。
参数说明：description 不要写太长，500 字以内足够展示；category 用中文短词“热血、日常、科幻”便于分类筛选；status 用 TINYINT 不用字符串，查询效率高一点，代码里再用枚举转换显示。
如果嫌 SQL 写起来手酸，也可以用 Java 的启动初始化方式。在 Spring Boot 里实现CommandLineRunner，启动时检查 t_anime 表有没有数据，没有就插入默认记录。这个做法的好处是：演示前不用手动执行 SQL，对答辩现场更友好。需要注意的是，必须加一个“表里无数据才插入”的判断，否则每次启动都会重复写数据。
后台录入这条路主要为了演示管理功能：在管理页面上传封面、填写简介、添加剧集。它依赖前端表单和后端上传接口，工作量不大，但建议放在主流程跑通之后再补，不要一上来就做。
3.3 登录鉴权与用户态：JWT 拦截器的实现细节
登录鉴权是答辩必问点。用 Session 也行，但前后端分离场景下 JWT 更好讲：无状态、跨域友好、前端存 token。实现分三块：生成 token 的工具类、校验 token 的拦截器、把拦截器注册进 Spring MVC 配置。
先写 JWT 工具类，这段代码可以完整放进论文附录：
public class JwtUtil { private static final String SECRET = "your-32-byte-secret-key-change-me"; private static final long EXPIRE_MS = 7 * 24 * 60 * 60 * 1000L; public static String createToken(Long userId, String username) { return Jwts.builder() .claim("uid", userId) .claim("username", username) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_MS)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }逻辑说明：createToken 把用户 id 和用户名写进 token 的 claim 中，并设置 7 天过期时间。parseToken 解析并验签，验签失败会抛异常，拦截器捕获后直接返回 401。论文里可以写一句“token 无状态存储在客户端，服务端不需要保存会话”。
参数说明：SECRET 在实际项目中至少 32 字符，不要硬编码在代码里，可以放到 application.yml 中读取，毕设演示阶段写在类里问题不大，但论文里建议写上“生产环境应从配置中心读取”。过期时间设置 7 天是为了演示方便，真实项目通常是 2 小时短期 token 加刷新机制，这个差异答辩时主动说清楚反而加分。
拦截器代码是鉴权核心：
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equals(request.getMethod())) { return true; } String auth = request.getHeader("Authorization"); if (auth != null && auth.startsWith("Bearer ")) { try { JwtUtil.parseToken(auth.substring(7)); return true; } catch (Exception e) { // token 过期或非法，落到下方统一返回 } } response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"message\":\"未登录或登录已过期\"}"); return false; } }逻辑说明：preHandle 先放行 OPTIONS 预检请求，否则前端跨域请求会死在拦截器这一层。然后从 Header 取 Authorization 字段，规范是Bearer <token>，截掉前 7 个字符再解析。解析失败统一返回 401，由前端跳转登录页。
注意点：不要把“判断是否登录”写进每个 Controller 里重复调用，拦截器一次解决。注册拦截器时需要配置放行路径，比如登录接口、注册接口、动漫列表和详情接口都不需要登录，收藏、评论、评分接口必须拦截。配置写在 WebMvcConfigurer 里：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/auth/register", "/api/anime/**"); } }参数说明：addPathPatterns 管哪些路径要过拦截器，excludePathPatterns 管放行路径。这里/api/anime/**放行是让游客能看列表和详情，符合实际需求。注册登录接口放行是因为用户还没登录。写论文时把这张“拦截路径表”做成表格放进设计文档，比大段文字直观得多。
4. 前端从 0 到 1：首页、详情页与播放页的完整链路
后端接口就绪后，前端的工作是把它串成能看的页面。我不建议在这里花太多时间打磨动画效果，优先把“能看、能点、能提交”做扎实。
4.1 路由设计：游客与登录用户的边界
前端路由直接决定用户体验。游客可以看首页、列表、详情、播放页，但收藏、评论、评分这些操作必须登录。用 Vue Router 的 meta 字段标记哪些页面需要登录，然后在全局守卫里统一判断：
const routes = [ { path: '/', component: Home }, { path: '/anime/:id', component: AnimeDetail }, { path: '/login', component: Login }, { path: '/favorites', component: Favorites, meta: { requiresAuth: true } }, { path: '/manage', component: Manage, meta: { requiresAuth: true } }, ]; router.beforeEach((to) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth && !token) { return { path: '/login', query: { redirect: to.fullPath } }; } });逻辑说明：全局守卫在每次路由跳转前执行，to.meta.requiresAuth为 true 且本地没有 token 时，直接重定向到登录页，并把原始目标地址放在 query 里，登录成功后跳回去。
参数说明：localStorage 是前端存储 token 的常用位置，刷新不丢失。路由守卫只做页面级拦截，接口级拦截靠后端的 JWT 拦截器，两层配合才完整。要注意登录页本身不能带 requiresAuth，否则会死循环。还有一个细节：登录成功后要把用户信息也存一份，比如localStorage.setItem('userInfo', JSON.stringify(res.data.data))，个人中心显示头像昵称时直接用，不用再发请求。
4.2 首页与列表页：请求封装、卡片渲染与图片懒加载
axios 不能每个页面都 new 一个实例，统一封装是基本功。创建src/api/request.js，设置 baseURL、超时时间和请求拦截器，请求拦截器里自动附带 token：
import axios from 'axios'; const service = axios.create({ baseURL: '/api', timeout: 10000, }); service.interceptors.request.use((config) => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = 'Bearer ' + token; } return config; }); service.interceptors.response.use( (response) => { // 后端统一返回 { code, message, data } if (response.data.code === 401) { localStorage.removeItem('token'); window.location.href = '/login'; } return response.data; }, (error) => { return Promise.reject(error); } ); export default service;逻辑说明：请求拦截器统一加 token，响应拦截器统一处理 401，这样每个页面都不用重复写“token 失效跳登录”的逻辑。baseURL 设为/api，开发环境靠 vite 转发到后端端口，生产环境靠 Nginx 转发，前后端分离模式下前端代码不用区分环境。
参数说明：timeout 设 10 秒是合理的演示值，太短容易在答辩网络波动时误报，太长体验差。401 处理用window.location.href强制跳转，比router.push更可靠，不会受到当前路由守卫限制。
图片懒加载是首页性能的细节，同时也是论文里能写的小亮点。用一个自定义指令实现：
app.directive('lazy', { mounted(el, binding) { const src = binding.value; const observer = new IntersectionObserver((entries) => { if (entries[0].isIntersecting) { el.src = src; observer.unobserve(el); } }); observer.observe(el); }, });逻辑说明：图片元素先不设置 src，只放一个低质量占位图或空背景，等 IntersectionObserver 检测到图片进入视口时才把真实地址赋给 el.src。这样首页几十张卡片同时加载时，不会一次性请求所有图片。
参数说明：IntersectionObserver 是现代浏览器原生 API，不需要额外依赖。指令的 binding.value 是真实图片地址，模板里写成v-lazy="item.cover"。如果你不想自己写，也可以引入现成的懒加载库，但自己写的这段进论文附录更显扎实。
4.3 详情页与播放页：评论、追番与播放地址的拼装
详情页是整个网站信息最密集的地方：封面、标题、分类、简介、选集列表、评论列表、收藏按钮、评分组件。加载逻辑是进去同时请求两个接口——动漫详情和评论列表：
const detail = await getAnimeDetail(id); const comments = await getComments(id);评论提交需要注意：未登录用户点击提交时，后端会返回 401，前端拿到 401 后跳登录页。这个流程要提前测通，因为答辩时最容易在“游客状态提交评论”这个动作上露怯。提交成功后调用一次评论列表刷新，不要手动拼接数据，保证数据源唯一。
追番收藏按钮的状态也要一开始就确定：进入页面时调一个“是否已收藏”的接口，返回 true 按钮显示“已收藏”，返回 false 显示“收藏”。这个接口需要登录，所以游客进来默认显示收藏按钮，点击后跳登录页即可。
播放页相对简单，拿到剧集信息后，用原生 video 标签渲染：
<video :src="currentVideoUrl" controls autoplay class="player"></video>currentVideoUrl 是后端返回的本地视频相对路径，比如/videos/a_01.mp4。这里有个常见的播放黑屏坑：视频编码格式不对。浏览器对 H.264 兼容最好，对 H.265(HEVC) 支持很差。如果你的演示视频是 mkv 或者 H.265 编码，建议提前转码。我一般用 FFmpeg 做一次性转换：
ffmpeg -i input.mkv -vcodec h264 -acodec aac output.mp4逻辑说明：这条命令把任意视频转成 H.264 + AAC 编码的 MP4，浏览器基本都能直接播放。参数-vcodec h264指定视频编码，-acodec aac指定音频编码，output.mp4是输出文件。转码速度取决于视频大小，演示视频控制在 50MB 以内，一段几分钟的样片就够了，答辩现场没人在意片源画质。
5. 常见问题与排查：联调期最容易翻车的 5 个位置
这一章全是血泪经验。前后端联调期的大多数“玄学问题”，最后查下来都是编码、跨域、静态资源这三类。这里挑 5 个最典型的，按“现象 → 原因 → 解决”写清楚，每一条都对应一个真实的调试过程。
5.1 图片集体裂开：外链防盗链的坑
现象：本地开发时页面正常，部署到演示环境后，首页动漫封面图全部不显示，浏览器控制台一片红色 403。
原因：为了省事直接引用了外部动漫站点的图片 URL。这些站点在服务器层面做了 Referer 防盗链校验，只要请求头里的 Referer 不是它们的允许域名，就直接拒绝返回图。本地打开 HTML 时 Referer 为空，部分站点放行；部署后走的是你自己的域名，Referer 变成你的地址，就被识别为盗用，403 一片。
解决：不要依赖外链。写一个初始化脚本，把需要的封面图下载到本地项目的静态目录，路径存进数据库的 cover 字段。下载时可以带一个伪装 Referer 的请求头，但更干净的做法是找无版权演示图，或直接自己生成占位图。部署后用 Nginx 托管本地静态目录：
server { listen 80; location /images/ { alias /opt/ct-anime/images/; } }逻辑说明：把所有静态图片收敛到/images/路径，请求由 Nginx 直接返回本地文件，不经过后端应用。这样既解决了防盗链问题，也减轻了后端压力。论文里可以写“系统采用本地静态资源托管方案，不依赖外部图片服务”。
5.2 跨域导致登录态丢失：前后端端口不一致
现象：登录接口调用成功，token 也存进 localStorage 了，但页面一刷新又跳回登录页。更诡异的是，收藏功能时好时坏。
原因：前端跑在 8080，后端跑在 8081，属于跨域请求。后端没配跨域时，axios 的请求会被浏览器拦截，登录接口往往是第一个暴露问题的。如果后端配了跨域但没放行 Authorization 头，token 就带不过去，后端拦截器拿不到 token 返回 401，前端一看 401 就把 localStorage 清了，表现为“登录成功又跳回登录”。
解决：后端统一配置 CORS，允许前端地址，并放开所有自定义头：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }参数说明：allowedOriginPatterns 用*表示允许所有来源，和 allowCredentials 配合时不能写成 allowedOrigins("")，这是 Spring 的硬性要求。allowedHeaders("") 放开所有请求头，including Authorization。前端不需要额外设置 withCredentials，token 是显式放在 Header 里的，不依赖 Cookie，所以这个配置够用。
但更省事的做法是开发环境直接用 vite 的 devServer 转发：
server: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, }, }, }这样前端所有 /api 请求都转发到后端，浏览器感知不到跨域，生产环境再用 Nginx 做同样的事。答辩时建议先讲转发方案，再讲 CORS 配置，显得你理解两种手段的区别。
5.3 播放页黑屏转圈：视频编码与 MIME 类型
现象：点击剧集后 video 标签有 src，播放器一直转圈或黑屏，控制台没有明显报错，network 面板里视频请求是 200。
原因：大概率是视频编码不兼容。浏览器支持 H.264 和部分 VP9，但 H.265(HEVC) 在多数浏览器里没有硬解支持。另一个隐蔽原因是后端返回的视频文件 Content-Type 不是video/mp4，浏览器不认这个资源当视频流。
解决：视频文件提前用 FFmpeg 转成 H.264 编码的 MP4，然后部署时确认静态资源路径的 MIME 类型。Spring Boot 的静态资源配置一般会自动带上 video/mp4，如果用的 Nginx，确认 mime.types 里有video/mp4 mp4;。如果是在线视频 URL，尽量只对接明确支持跨域播放的资源，否则还要在响应头里加Access-Control-Allow-Origin。
排查顺序固定：先看 network 里视频请求的 Content-Type，再看视频编码信息，确认浏览器兼容。用 FFprobe 查编码：
ffprobe -v error -select_streams v:0 -show_entries stream=codec_name -of default=noprint_wrappers=1 output.mp4逻辑说明：这条命令只输出视频流的编码名称，是 h264 就能直接播放，是 hevc 就得转码。把排查命令写进论文附录的测试章节，答辩老师会认为你有实际排障能力。
5.4 中文搜索搜不到：编码链路没打通
现象：搜索框输入“柯南”点击搜索，列表为空，但打开数据库手动执行WHERE title LIKE '%柯南%'能查到数据。
原因：中文在请求链路上编码断裂。开发环境最常见的是数据库连接串没指定characterEncoding=utf8，导致中文参数传到 MySQL 后变乱码，匹配不上。另一个位置是 Tomcat 的 GET 请求默认用 ISO-8859-1 解码 URI，中文参数到后端就已经是乱码。
解决：第一处，在 application.yml 的数据库连接串中加上编码参数：
spring: datasource: url: jdbc:mysql://localhost:3306/anime_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai第二处，如果是独立 Tomcat 部署，改 server.xml 中 Connector 的 URIEncoding：
<Connector port="8080" protocol="HTTP/1.1" URIEncoding="UTF-8"/>逻辑说明：POST 请求走 request body，编码受spring.encoding控制；GET 请求的参数拼在 URL 里，必须靠容器解码。前后端分离项目里，前端用 axios 发 GET 时，中文会被浏览器自动 encode，后端拿到的是百分号编码后的字符串，Tomcat 用 UTF-8 解码才能还原。写论文时把这条“字符集配置清单”列成表格，属于很实在的系统环境设计内容。
5.5 答辩现场启动失败：依赖下载慢与端口占用
现象：演示当天，后端项目在 IDE 里启动一直转圈，过了五分钟还没起来，台下老师已经开始皱眉。或者后端起好了，前端页面却访问不到。
原因：平时在 IDE 里跑，依赖早就下完了，感觉不到问题。换一台没缓存依赖的机器，Maven 需要现场下载框架依赖，速度完全看网络状态。另一个常踩的坑是 8080 端口被占用，启动直接爆Port already in use。
解决：提前打好可执行 jar 包，演示时直接用 java -jar 启动，绕开 IDE 和依赖下载：
mvn clean package -DskipTests java -jar backend/target/anime-0.0.1.jar参数说明：-DskipTests 跳过测试，避免答辩现场跑测试用例中断。jar 包内置 Tomcat，8080 被占用就换端口启动：java -jar anime-0.0.1.jar --server.port=8081。前端构建后把 dist 目录放进后端src/main/resources/static，这样只启动一个进程，页面和接口就都能访问，现场演示的故障面最小。
还有个隐蔽问题：数据库。如果答辩机器上没有 MySQL，后端起来也会报连接失败。提前准备一个 MySQL 容器或把数据库连接切到嵌入式数据库做兜底，我一般会写一个启动检查脚本，探测数据库端口通不通，不通就给出中文提示。脚本本身不复杂，但能在关键时刻救命。
6. 论文编排与验收：把“能跑”变成“能答辩”的 4 个技巧
一个能跑的项目只代表完成了一半，论文排版和答辩演示是另一半。这里整理四个我每次带毕设都会用到的技巧。
6.1 三张图决定论文第一印象
论文里最值得花时间的三张图：系统架构图、数据库 ER 图、核心功能时序图。架构图从浏览器出发，指向静态资源服务和后端接口，再连到 MySQL，分三层画清楚；ER 图把六张表的主外键关系画出来，t_favorite 和 t_rating 这两个多对多桥梁表重点标注；时序图选“用户登录后收藏动漫”这个完整链路，从点击收藏按钮到后端校验 token、写库、返回最新状态，全程画完。这三张图分别放在绪论、概要设计、详细设计三章，评审翻到这几页就知道你的系统是完整的。
6.2 用测试表代替截图流水账
很多论文写系统测试时贴十几张截图，评委根本看不完。更有效的方式是功能测试表加接口测试表。功能测试表写用例编号、操作步骤、预期结果、实际结果；接口测试表写请求方式、接口路径、入参、返回状态码和响应体。每张表 10 到 15 行足够，重点覆盖登录、搜索、评论、收藏、播放五条主链路。测试结果全部写“通过”，但真实跑一遍后再填，不要编。
6.3 答辩前把“问不倒”训练成习惯
评委常问的问题高度集中：数据怎么来的、图片为什么本地化、密码怎么存、搜索为什么直接用 LIKE、评论怎么防刷。答案都在前几章里：数据用脚本初始化并保留可复现机制，图片本地化是为了解决防盗链，密码用 BCrypt 加密，搜索在数据量小的时候 LIKE 够用，评论接口做了简单的同账号频率限制。拿着这份清单让同学扮演评委提问，多练两轮，上场就不慌。演示时固定一条路径：启动后端 → 打开首页 → 搜索动漫 → 进详情 → 登录 → 收藏 → 发评论 → 退出登录。每一步都能对应到论文章节。
6.4 附录代码的整理技巧
核心代码不要整页贴。选出 10 段左右有代表性的代码放进附录：JWT 工具类、拦截器、统一响应封装、建表 SQL、图片懒加载指令、评论提交、视频转码命令、Nginx 配置。每段代码附一句“实现的功能”说明。正文部分用自己的话描述实现思路，不要大段引用代码，这样既避免查重问题，也让论文读起来更流畅。
我每次交付前有个习惯：把数据库删掉重建，从零启动一遍，确认没有任何“我本机能跑”的隐藏依赖；再把 jar 包复制到另一台干净机器上跑一遍，验证端口、数据库、静态资源全部就绪。这次写这篇，也把同样的检查顺序过了一遍，踩过的坑都留在了第 5 章。希望帮到你。
本文还有配套的精品资源，点击获取
