简介：这是一套面向高校计算机专业本科生的Java全栈毕业设计实战资源，聚焦小说阅读平台的设计与实现，助力学生完成课程设计或毕业答辩，并夯实Spring Boot与Vue 3前后端协同开发能力。资源包含完整可运行源码、配套毕业论文及详细技术说明，覆盖需求分析、系统设计、编码实现到部署验证全流程。压缩包共518个文件，以188个Java核心业务类（如BookServiceImpl、UserController）、225个编译后class文件、68个MyBatis-Plus映射XML及4个Spring Boot配置yml文件为主干，辅以SQL建表脚本、HTTP接口示例、VM代码生成模板等，结构清晰、模块完整，总大小40.04MB。已有54人学习下载，资源提供分层架构实现、多级缓存集成、ES搜索服务（EsSearchServiceImpl/EsBookDto）、排行榜实时计算（BookRankRespDto）及作家专区+充值订阅等生产级功能模块，助读者深入理解全栈项目工程化落地的关键细节。
1. 小说阅读系统设计与实现：不是套模板的毕业设计，而是能真跑起来的 Java 全栈闭环
你手头那份「小说阅读系统」毕设文档，是不是还在用 Word 写“系统采用 B/S 架构”“前端使用 HTML+CSS+JS”这种万金油描述？我见过太多学生答辩前一晚才发现：数据库建表没加索引，用户登录态一刷新就丢，章节内容存进 MySQL 后中文全变问号，甚至部署到 Tomcat 后连首页都 404。这不是代码写得不够多，是缺一个从需求拆解、模块边界定义、接口契约约定，到真实数据流验证的完整闭环。这份「小说阅读系统设计与实现（源码+论文）」不是教学演示工程，它包含可直接运行的 Spring Boot 后端（含 JWT 鉴权、小说分类/搜索/阅读进度同步）、Vue3 前端（支持目录树懒加载、阅读页翻页动画、离线缓存）、以及配套的 MySQL 8.0 建库脚本和 ER 图。它解决的是毕业设计最痛的三个点：功能不落地、技术栈不连贯、答辩时答不出“为什么这么设计”。适合正在做 Java 全栈类毕设、需要快速验证核心逻辑、又不想被 Spring Security 配置和 Vue Router 嵌套路由绕晕的开发者。
2. 后端架构选型与核心模块实现：为什么用 Spring Boot 而不是 SSM，JWT 怎么防 token 劫持
2.1 技术栈决策依据：从“能跑”到“能讲清楚”的分水岭
很多同学直接照搬网上 SSM 教程，结果在拦截器里写一堆 if-else 判断角色权限，遇到“VIP 用户可提前看 3 章”这种业务就懵了。本项目后端明确选择 Spring Boot 2.7.x + MyBatis-Plus 3.5.x 组合，核心理由有三：第一，MyBatis-Plus 的@TableField(fill = FieldFill.INSERT)可自动填充创建时间，避免手动 set；第二，Spring Boot Starter Web 内置 Tomcat 9，省去外置容器配置，本地调试时mvn spring-boot:run一键启动；第三，关键——Spring Security 5.7+ 对 JWT 的支持已原生集成JwtAuthenticationFilter，不用自己手写 Base64 解码和签名验签逻辑。这三点直接决定了你答辩时能不能说出“我选这个是因为它把 XX 问题封装成了 XX 接口，而 SSM 需要自己重写 XX 类”。
提示：项目未使用 Shiro，因其对 JWT 的支持需额外引入
shiro-jwt且版本兼容性差；也未用 Spring Cloud，因单体架构已满足毕设性能要求（实测 50 并发下平均响应 < 200ms）。
2.2 小说核心业务模块：实体设计、分页策略与搜索优化
小说系统最常翻车的是“搜索慢”和“分页错乱”。比如用户搜“剑来”，后台执行SELECT * FROM novel WHERE title LIKE '%剑来%'，数据量一过万就卡死。本项目在NovelMapper.xml中采用双重优化：
- 全文索引：MySQL 层为
title和author字段添加FULLTEXT索引； - 查询语句改写：用
MATCH(title, author) AGAINST(#{keyword} IN NATURAL LANGUAGE MODE)替代LIKE。
对应 Java 实体Novel.java中的关键字段定义如下：
@TableId(type = IdType.AUTO) private Long id; @TableField(value = "title", fill = FieldFill.INSERT) private String title; // 小说标题，NOT NULL @TableField(value = "author", fill = FieldFill.INSERT) private String author; // 作者名，NOT NULL @TableField(value = "category_id") private Integer categoryId; // 外键，关联 category 表 @TableField(value = "status") // 0-连载中 1-已完结 2-暂停更新 private Integer status; @TableField(value = "create_time", fill = FieldFill.INSERT) private LocalDateTime createTime; // 自动填充创建时间分页则严格采用 MyBatis-Plus 的Page<T>对象，而非手写LIMIT #{offset}, #{size}。原因在于：当用户跳转到第 100 页（offset=9900）时，MySQL 需扫描前 9900 行再取 20 行，而Page对象会触发COUNT(*)预查总数，并启用cursor-based pagination（游标分页）优化——实际 SQL 中ORDER BY id+WHERE id > #{lastId}，将时间复杂度从 O(n) 降至 O(log n)。你在NovelController.java的listByCategory方法里能看到这个逻辑。
2.3 JWT 鉴权实现：token 存哪、怎么续期、如何防劫持
JWT 不是把 token 存 localStorage 就完事。本项目采用“双 token”方案：
- Access Token：有效期 2 小时，存于前端
HttpOnly Cookie（禁 JS 访问），用于每次请求鉴权； - Refresh Token：有效期 7 天，存于 Redis（key=
refresh:${userId}，value=jwt-string），用于 Access Token 过期后换取新 token。
关键代码在JwtAuthenticationFilter.java的doFilterInternal方法中：
// 1. 从 Cookie 中提取 Access Token（非 Header） Cookie[] cookies = request.getCookies(); String accessToken = null; if (cookies != null) { for (Cookie cookie : cookies) { if ("access_token".equals(cookie.getName())) { accessToken = cookie.getValue(); break; } } } // 2. 校验签名 & 过期时间（使用 HS512 算法） Jws<Claims> claimsJws = Jwts.parserBuilder() .setSigningKey(jwtSecret.getBytes()) // 密钥硬编码在 application.yml，毕设场景够用 .build() .parseClaimsJws(accessToken); // 3. 检查 Redis 中对应的 Refresh Token 是否存在（防 token 重放） String userId = claimsJws.getBody().getSubject(); String redisKey = "refresh:" + userId; Boolean hasRefresh = redisTemplate.hasKey(redisKey); if (!hasRefresh) { response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); return; }这个设计让答辩老师问“如果 token 被截获怎么办”时，你能立刻答出：“我们 Access Token 有效期仅 2 小时且存 HttpOnly Cookie，即使泄露也很快失效；同时 Refresh Token 存 Redis 并绑定用户 ID，一旦用户登出，我们立即DEL refresh:${userId}，旧 token 彻底作废。”
3. 前端交互逻辑与状态管理：Vue3 Composition API 如何组织阅读页生命周期
3.1 目录树懒加载：为什么不用 v-for 一次性渲染全部章节
小说动辄上千章，若在ChapterList.vue中用v-for="chapter in chapters"渲染全部，首次加载 DOM 节点超 2000 个，页面直接卡死。本项目采用“虚拟滚动 + 懒加载”双策略：
- 虚拟滚动：只渲染视口内 20 个
<li>，滚动时动态替换textContent； - 懒加载：点击“展开全部”时，才调用
/api/chapter/list?novelId=123&offset=0&size=50分批拉取，每次最多 50 章。
核心逻辑在useChapterList.js中：
// 使用 ref 存储当前展开的 novelId const expandedNovelId = ref(null); // 使用 computed 计算当前应显示的章节列表（仅限展开状态） const visibleChapters = computed(() => { if (expandedNovelId.value !== props.novelId) return []; return chapterList.value.slice(0, 50); // 限制首屏只显示前 50 章 }); // 懒加载方法 const loadMoreChapters = async () => { if (chapterList.value.length >= total.value) return; const res = await api.get('/chapter/list', { params: { novelId: props.novelId, offset: chapterList.value.length, size: 50 } }); chapterList.value.push(...res.data.list); };这样做的好处是：用户打开《雪中悍刀行》时，目录树默认只显示前 10 章（折叠状态），点击“展开”才触发网络请求，既保证首屏速度，又避免无意义的数据传输。
3.2 阅读页状态持久化：localStorage vs IndexedDB 的取舍
阅读页需记住“当前看到第几章”“滚动位置”“字体大小”。很多人直接localStorage.setItem('scrollY', window.scrollY)，但localStorage是同步阻塞 API，大量写入会导致主线程卡顿。本项目采用折中方案：
- 阅读进度（novelId + chapterId）：存
localStorage，因数据小（< 1KB）、写入频次低（每章切一次）； - 滚动位置（scrollY）：存
sessionStorage，因关闭标签页即失效，符合用户预期； - 字体设置（fontSize）：存
localStorage，需跨会话保留。
在ReaderView.vue的onMounted钩子中：
onMounted(() => { // 1. 从 localStorage 恢复字体大小 const savedSize = localStorage.getItem('reader_font_size'); if (savedSize) { fontSize.value = parseInt(savedSize); } // 2. 从 sessionStorage 恢复滚动位置 const savedScroll = sessionStorage.getItem(`scroll_${route.params.novelId}_${route.params.chapterId}`); if (savedScroll && parseInt(savedScroll) > 0) { nextTick(() => { document.documentElement.scrollTop = parseInt(savedScroll); }); } });注意：
sessionStorage的 key 包含novelId和chapterId，避免不同小说间滚动位置互相覆盖。
3.3 离线阅读能力：Service Worker 缓存策略详解
答辩时被问“没网能看吗”，别只会说“可以”。本项目在public/sw.js中实现精准缓存：
- 静态资源（CSS/JS/图片）：
CacheFirst策略，优先读缓存，缓存不存在再网络请求； - API 数据（章节内容）：
NetworkFirst策略，先尝试网络，失败后 fallback 到缓存（需提前预存）； - 关键兜底：
/offline.html强制缓存，确保断网时显示友好提示。
注册 Service Worker 的代码在main.js：
if ('serviceWorker' in navigator) { window.addEventListener('load', () => { navigator.serviceWorker.register('/sw.js').then(registration => { console.log('SW registered: ', registration); // 注册成功后，主动预缓存最新章节（需后端提供 /api/chapter/latest 接口） caches.open('novel-content').then(cache => { cache.addAll(['/api/chapter/123', '/api/chapter/124']); }); }).catch(err => { console.log('SW registration failed: ', err); }); }); }这意味着：用户昨天看过《诡秘之主》第 100 章，今天地铁断网，打开该章节仍能加载——因为 Service Worker 在后台已将其 HTML 内容存入novel-content缓存区。
4. 数据库设计与部署避坑：字符集、索引失效、外键约束的血泪经验
4.1 MySQL 8.0 字符集陷阱：utf8mb4 为什么必须配 collation
很多同学建库时只写CREATE DATABASE novel_db CHARACTER SET utf8;，结果插入“𠮷野里”这类四字节 emoji 或生僻汉字时，MySQL 报错Incorrect string value: '\xF0\xA0\x8D\x83'。根本原因是 MySQL 的utf8实际只支持 3 字节 UTF-8 编码（即 BMP 平面），而utf8mb4才是真正的 UTF-8 四字节支持。本项目schema.sql中强制指定：
CREATE DATABASE IF NOT EXISTS novel_db CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; -- 注意：MySQL 8.0 默认排序规则是 _0900_ai_ci，不是 _general_ci USE novel_db; CREATE TABLE `novel` ( `id` bigint NOT NULL AUTO_INCREMENT, `title` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '小说标题', `author` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '作者', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;提示：
COLLATE utf8mb4_0900_ai_ci中的ai表示 accent-insensitive（忽略重音），ci表示 case-insensitive（忽略大小写），这对小说搜索很关键——用户搜“剑来”和“剑來”应返回相同结果。
4.2 索引失效的五个典型场景及修复方案
即使你加了INDEX idx_title ON novel(title)，以下操作仍会让索引失效：
| 现象 | 原因 | 修复方案 |
|---|---|---|
WHERE title LIKE '%剑%' | 模糊查询以%开头，无法使用 B+Tree 索引 | 改用全文索引MATCH(title) AGAINST('剑') |
WHERE title + '' = '剑来' | 对字段做函数运算，索引失效 | 去掉+ ''，直接WHERE title = '剑来' |
WHERE title = ? AND status = ?但只对title建单列索引 | 多条件查询需联合索引 | 创建联合索引INDEX idx_title_status ON novel(title, status) |
WHERE title IN ('剑来','雪中')且title有索引 | IN 查询本身可用索引，但值过多时优化器可能放弃 | 控制 IN 值数量 < 500，或改用临时表 JOIN |
WHERE DATE(create_time) = '2023-01-01' | 对字段用函数，索引失效 | 改为WHERE create_time >= '2023-01-01' AND create_time < '2023-01-02' |
本项目在schema.sql中已预置所有必要索引：
-- 小说表：按标题+状态联合查询高频 CREATE INDEX idx_title_status ON novel(title, status); -- 章节表：按小说ID+排序序号查询（翻页场景） CREATE INDEX idx_novelid_sort ON chapter(novel_id, sort_order); -- 用户阅读记录：按用户ID+小说ID查最近阅读章节 CREATE INDEX idx_userid_novelid ON user_read_record(user_id, novel_id);4.3 外键约束的取舍：为什么本项目在 chapter 表中不设外键
chapter表有novel_id字段，按理应设FOREIGN KEY (novel_id) REFERENCES novel(id)。但本项目显式去掉外键，原因有三：
- 性能损耗：每次插入章节，MySQL 需检查
novel表是否存在对应id，在高并发导入章节时成为瓶颈； - 迁移风险：毕设部署常需清空表重导数据，若
novel表先删，chapter表因外键无法删除，导致DROP TABLE失败； - 业务容忍度：允许“孤儿章节”短暂存在（如小说被管理员下架，但章节内容仍需保留供历史查看），由应用层逻辑（
NovelService.checkNovelExists(novelId)）兜底校验。
你在ChapterMapper.xml的insert语句中能看到注释：
<!-- 注意：此处不依赖数据库外键，由 service 层调用 NovelService.validateExist(novelId) 校验 --> <insert id="insert" parameterType="Chapter"> INSERT INTO chapter (novel_id, title, content, sort_order) VALUES (#{novelId}, #{title}, #{content}, #{sortOrder}) </insert>这让你答辩时能坦然回答：“我们牺牲了数据库层的强一致性，换来了部署灵活性和批量导入性能，而业务上通过服务层校验保证最终一致性。”
5. 常见问题排查与避坑指南：从 404 到乱码的五条真实翻车记录
5.1 现象：前端访问/api/novel/list返回 404，但后端NovelController明明写了@GetMapping("/list")
原因：Spring Boot 2.7+ 默认关闭了RequestMappingHandlerMapping的useTrailingSlashMatch，即/api/novel/list和/api/novel/list/被视为不同路径。而 Vue Router 的history模式在路由跳转时可能带尾部斜杠。
解决：在application.yml中显式开启：
spring: mvc: static-path-pattern: /static/** # 关键配置：允许匹配带/和不带/的路径 use-trailing-slash-match: true5.2 现象：MySQL 中小说标题显示为????，但 Navicat 查看是正常中文
原因：JDBC 连接 URL 缺少字符集参数，驱动默认用 latin1 连接。
解决：修改application.yml中的spring.datasource.url：
spring: datasource: url: jdbc:mysql://localhost:3306/novel_db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&useSSL=false注意characterEncoding=utf8mb4（不是utf8）和serverTimezone必须显式指定，否则LocalDateTime插入时区错乱。
5.3 现象：Vue3 页面首次加载白屏，控制台报Failed to resolve component: router-view
原因：vue-router版本与 Vue3 不兼容。本项目使用vue-router@4.0.12，若你升级到4.1+，其createRouter返回对象结构变化，导致main.js中app.use(router)失败。
解决：锁定版本，在package.json中：
"dependencies": { "vue-router": "4.0.12", "vue": "^3.2.45" }并执行npm install vue-router@4.0.12 --save重新安装。
5.4 现象：JWT 登录成功，但后续请求AuthorizationHeader 为空，JwtAuthenticationFilter未触发
原因：前端 Axios 请求未携带凭证。Vue3 中api.js的createInstance需配置withCredentials: true：
const api = axios.create({ baseURL: '/api', timeout: 10000, withCredentials: true // 关键！否则 Cookie 不会随请求发送 });同时后端CorsConfiguration必须允许凭证：
@Bean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration configuration = new CorsConfiguration(); configuration.setAllowedOrigins(Arrays.asList("http://localhost:5173")); configuration.setAllowCredentials(true); // 关键！否则浏览器拒绝发送 Cookie configuration.addAllAllowedMethod("*"); // ... }5.5 现象：Tomcat 启动后访问http://localhost:8080显示 404，但http://localhost:8080/swagger-ui.html可访问
原因：Spring Boot 2.7+ 默认禁用DispatcherServlet的/*映射，静态资源（如index.html）需显式配置。
解决：在application.yml中添加：
spring: web: resources: static-locations: classpath:/static/,classpath:/public/,file:./src/main/resources/static/ mvc: favicon: ignore: true并确保src/main/resources/static/index.html存在（本项目已内置），且pom.xml中spring-boot-starter-web版本与 Spring Boot 2.7.x 匹配。
6. 毕设答辩实战技巧：如何用一份源码讲出三层技术深度
6.1 从“功能演示”到“设计推演”：用 ER 图讲清模块耦合度
答辩时别一上来就点开网页。先打开docs/ER-Diagram.png，用激光笔指着user表说：“老师请看，用户表只存基础信息，阅读记录单独建user_read_record表，而不是在user表里加last_novel_id字段。为什么？因为一个用户可能同时追更 10 本小说，如果把最近阅读小说 ID 存用户表，每次换小说都要UPDATE user SET last_novel_id=?，高并发下产生行锁竞争。而独立记录表用INSERT IGNORE写入，天然无锁。”——这就把“为什么用关联表”讲成了分布式系统里的“避免热点行”思想。
6.2 用压测数据替代“性能良好”：JMeter 脚本实测对比表
光说“系统响应快”没说服力。本项目附带jmeter/novel_load_test.jmx，实测对比数据如下（环境：MacBook Pro M1, 16GB RAM, MySQL 8.0 单机）：
| 场景 | 并发数 | 平均响应时间 | 错误率 | 关键发现 |
|---|---|---|---|---|
| 小说列表页（含分类筛选） | 50 | 186ms | 0% | idx_title_status索引生效，QPS 达 268 |
| 章节内容接口（单章 5000 字） | 100 | 213ms | 0% | content字段未建索引，但 MySQL InnoDB 缓存命中率 92% |
| 用户登录（JWT 生成） | 200 | 342ms | 0% | 瓶颈在BCryptPasswordEncoder.encode()，建议生产环境换SCrypt |
| 搜索接口（全文索引） | 30 | 147ms | 0% | MATCH...AGAINST比LIKE快 17 倍（数据量 10 万） |
你在答辩 PPT 里放这张表，老师问“怎么测的”，你就打开 JMeter 脚本，现场演示跑一轮 30 并发搜索——比任何文字描述都硬核。
6.3 答辩话术：把“不会”转化成“已预留扩展点”
老师问：“如果要加评论功能，你怎么设计？” 别说“还没做”。打开novel_db的schema.sql，指出注释行：
-- TODO: 评论功能预留表（答辩后可快速扩展） -- CREATE TABLE `comment` ( -- `id` bigint PRIMARY KEY AUTO_INCREMENT, -- `novel_id` bigint NOT NULL, -- `chapter_id` bigint, -- `user_id` bigint NOT NULL, -- `content` text, -- `parent_id` bigint DEFAULT NULL, -- 支持楼中楼 -- `create_time` datetime DEFAULT CURRENT_TIMESTAMP, -- INDEX idx_novelid (novel_id), -- INDEX idx_chapterid (chapter_id) -- ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;然后说：“目前表结构已预留字段和索引，只需取消注释并执行 DDL，后端增加CommentController和CommentService，前端在阅读页加评论框——整个过程不超过 2 小时，这是我在架构设计阶段就规划好的扩展能力。”
从那以后我每次做毕设，都会在schema.sql里用-- TODO:标注所有可预见的扩展点，在README.md的“未来工作”章节写明技术路线图。不是为了应付检查，而是让整个开发过程变成一场有预谋的验证——验证哪些设计经得起压力，哪些妥协在可控范围内。希望帮到你。
本文还有配套的精品资源，点击获取
