企业官网建设流程全解析

简介：面向毕业设计与Java全栈学习的小说阅读系统源码包，基于Spring Boot 3与Vue 3实现前后端分离架构，完整覆盖小说推荐、作品检索、排行榜、阅读、评论、会员中心、作家专区、充值订阅、新闻发布等核心业务模块。包体共518个文件，约40.04MB，以188个Java源文件、225个class编译文件为主，同时包含XML与yml配置、SQL脚本、Vue前端模板及2份docx论文文档，源码、数据库脚本和论文配套齐全，便于边读边做。已有54人浏览学习，适合高校计算机、软件工程专业学生用于课程设计或毕业答辩，也可作为企业级应用原型参考。深入阅读代码可理解Spring Boot集成MyBatis-Plus、MySQL持久化、多级缓存与分层设计，学习单例、工厂、观察者等设计模式的实际落地；通过Vue 3响应式页面与RESTful接口联调，能完整走通从后端服务到前端展示的全栈开发流程，项目完整度和实战参考价值都比较高。

1. 小说阅读系统：为什么说难点全在“读完接着读”

带过毕业设计或 Java 课程设计的人，对小说阅读系统这个题目应该不陌生。乍一看它就是个简易版的小说网站：书架、阅读页、翻上一章下一章，似乎一个 CRUD 就能解决。真动手写代码时才会发现，阅读器进度存储、章节内容与列表的数据拆分、用户阅读位置的唯一性约束，任何一个环节没想清楚，都会让程序在答辩演示时当场翻车。

这类系统最核心的诉求不是把小说展示出来，而是把“读到哪了”这件事稳定地记录下来。用户可能用手机看完一章，关掉页面，第二天从第一章重新翻起——这种体验做不好，整个系统就没有存在价值。本文用 Spring Boot + Vue 这套主流组合，把小说阅读系统的表结构、接口设计和论文写法一起拆开讲，中间会穿插我实际调试时踩过的坑，适合正在做课设、毕设，或者想拿一套干净代码练手的人。

2. 技术选型与数据库设计：先把四张核心表立住

2.1 为什么选 Spring Boot + Vue：课设项目最稳的组合

小说阅读系统在常见的 Java 课程设计和毕业设计中，出现频率极高。选型时我不建议碰微服务、消息队列这类重型组件，用 Spring Boot + MyBatis-Plus + Vue 就足够覆盖“管理后台 + 前端阅读页”的全部需求。Spring Boot 负责提供接口，Vue 负责渲染页面，两者通过 JSON 通信，数据层用 MySQL 存储。

有人在答辩时喜欢强调“前后端分离”，但分离的关键不在架构口号，而在接口设计是否清晰。小说阅读系统需要的接口数量不多，核心就几组：书籍列表、章节列表、章节详情、阅读进度上报、书架增删。把它们按 REST 风格组织好，比引入 Nginx 反向代理这类部署概念更能让评委信服。

另外补充一句，这类源码在网上一搜一大把，但多数是打包好的“源码建站”成品，数据库脚本和前端构建产物混在一起，很难二次修改。你要找的是能本地跑起来、目录清晰、带论文框架的源码，否则答辩抽问某个类的作用时，只能干瞪眼。

2.2 数据表设计：book、chapter、user、reading_progress 怎么关联

我做过几个阅读类系统的数据模型，总结下来四张表足够覆盖主流程。核心思路是：书籍与章节是一对多，用户与阅读进度是一对一（同一本书只保留一条进度记录），书架关系用中间表或单独一张表存都可以。

先看书籍表与章节表，章节表尤其要注意字段取舍：

CREATE TABLE `book` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(100) NOT NULL COMMENT '书名', `author` VARCHAR(50) DEFAULT '' COMMENT '作者', `category_id` INT DEFAULT 1 COMMENT '分类ID', `cover_url` VARCHAR(255) DEFAULT '' COMMENT '封面图URL', `description` TEXT COMMENT '简介', `status` TINYINT DEFAULT 1 COMMENT '1连载 2完结', `word_count` INT DEFAULT 0 COMMENT '总字数', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `chapter` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `book_id` BIGINT NOT NULL COMMENT '所属书籍ID', `chapter_no` INT NOT NULL COMMENT '章节序号，从1开始', `title` VARCHAR(200) NOT NULL COMMENT '章节名', `content` MEDIUMTEXT NOT NULL COMMENT '章节正文', `word_count` INT DEFAULT 0 COMMENT '本章字数', UNIQUE KEY `uk_book_chapter` (`book_id`, `chapter_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有一个关键设计：章节表用chapter_no而不是直接用自增主键id作为排序依据。原因是导入小说数据时，章节顺序经常被打乱，先插第 5 章再插第 3 章是常态，如果依赖自增 id 排序，前端翻页会错乱。uk_book_chapter唯一索引保证同一本书内章节号不重复，这也是导入去重的基本防线。

阅读进度表的设计是另一个重点。很多人会把进度直接挂在 chapter 表上，用“当前用户 ID + 当前章节 ID”查询，但这样只能定位到章节，无法记录章节内滚动位置。如果你希望用户重新打开时还停在上一段的附近，必须把滚动偏移也存下来：

CREATE TABLE `reading_progress` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL, `book_id` BIGINT NOT NULL, `chapter_id` BIGINT NOT NULL COMMENT '最后阅读章节ID', `chapter_no` INT NOT NULL COMMENT '最后阅读章节序号', `scroll_offset` INT DEFAULT 0 COMMENT '章节内滚动偏移量，单位px', `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_user_book` (`user_id`, `book_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

uk_user_book是必须的，它保证一个用户在同一本书下只有一条进度记录，后续更新走INSERT ... ON DUPLICATE KEY UPDATE，省去先查后改的两步操作。scroll_offset这个字段很多课设源码里都没有，但加上它，答辩时就能讲出“精细化阅读体验”的设计思路，属于性价比极高的小亮点。

书籍与用户的关联，即书架表，字段不需要很多，记录一下加入时间即可：

CREATE TABLE `user_bookshelf` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL, `book_id` BIGINT NOT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_user_book` (`user_id`, `book_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建表时统一用utf8mb4而不是utf8，原因很简单：小说内容里可能出现 emoji 或生僻字，utf8在 MySQL 中只有 3 字节，部分字符会直接报错或变成问号。这个坑我在导入数据时踩过，换成utf8mb4后一直没再犯。

2.3 数据从哪来：书籍内容的导入与清理

数据库设计完之后，最现实的问题是数据源。小说阅读系统的演示效果很大程度取决于书库是否丰富，但版权问题必须留意。我一般的做法是：用经典公版书（比如《红楼梦》《三国演义》这类已进入公共领域的作品）填充数据，既能展示效果，又不会惹麻烦。

内容导入要写一个解析脚本，把按章节分割的文本文件批量写入数据库。常见格式是每章一个 txt 文件，文件名即章节名。导入时的坑在于文本编码，Windows 上导出的 txt 可能是 GBK，而数据库是 utf8mb4，不转码会出现大量乱码。我的处理方式是用 Java 读取时显式指定字符集，示例脚本如下：

public void importChapters(Long bookId, File dir) throws IOException { File[] files = dir.listFiles((d, name) -> name.endsWith(".txt")); if (files == null) return; // 按文件名排序，保证章节顺序与书名序号一致 Arrays.sort(files, Comparator.comparing(File::getName)); int chapterNo = 1; for (File file : files) { String content = FileUtils.readFileToString(file, "UTF-8"); // 如果原文是GBK编码，需要先转码再入库 // String content = new String(Files.readAllBytes(file.toPath()), "GBK"); chapterMapper.insert(new Chapter(bookId, chapterNo++, file.getName().replace(".txt", ""), content, content.length())); } }

导入脚本的逻辑重点有两个：一是排序方式，Comparator.comparing(File::getName)按文件名自然排序，比如“第1章.txt”“第2章.txt”，如果文件名是“第1章.txt”到“第10章.txt”混在一起，自然排序会出现 1、10、2 的问题，所以我在实际项目中会把章节号直接编码在文件名里，如“001.txt”“010.txt”，避免字符串排序陷阱。二是转码，注释里保留 GBK 转码逻辑，导入前先确认源文件编码，比事后清洗数据省事得多。

3. 核心功能实现：从书架列表到阅读进度上报

3.1 书架接口：一次查询把“书 + 进度”拼出来

书架页是整个系统的门面。它的展示需求是：列出用户加入书架的所有书，每本书要显示当前读到第几章、是否更新。如果前端拿到书架列表后再逐本书查询进度，会产生 N+1 查询，书架书一多接口就变慢。

常见的做法是后端一条 SQL 关联出结果，避免前端多次请求。在 MyBatis-Plus 里，我一般用自定义 Mapper XML 写联表查询，而不是直接用LambdaQueryWrapper做单表操作：

<select id="selectBookshelfWithProgress" resultType="map"> SELECT b.id AS bookId, b.title, b.author, b.cover_url AS coverUrl, COALESCE(rp.chapter_no, 0) AS lastChapterNo, COALESCE(c.title, '未开始') AS lastChapterTitle, b.word_count AS wordCount FROM user_bookshelf ub JOIN book b ON ub.book_id = b.id LEFT JOIN reading_progress rp ON rp.book_id = b.id AND rp.user_id = #{userId} LEFT JOIN chapter c ON c.id = rp.chapter_id WHERE ub.user_id = #{userId} ORDER BY ub.create_time DESC </select>

这里的核心逻辑是LEFT JOIN reading_progress和LEFT JOIN chapter分别取进度和章节标题，COALESCE处理用户没读过的情况。注意第一条LEFT JOIN的条件里带了rp.user_id = #{userId}，这是为了防止联表时把别的用户的进度带进来，如果漏掉这个条件，一旦有两个人读同一本书，进度就会互相串——这个问题在联表查询里非常隐蔽，光看数据很难发现。

3.2 阅读页接口：章节内容与上下章导航一次返回

阅读页的接口最容易设计成“只返回当前章节内容”，然后前端自己计算上下章。但这样会导致用户翻页时多出一次额外请求，而且前端必须知道当前章是全书的第几章才能算“下一章”。我倾向于把上下章信息直接放在接口响应里，前端拿到nextChapterId直接跳转，不需要自己拼逻辑。

Controller 层代码大致如下：

@GetMapping("/chapter/{chapterId}") public Result<ChapterDetailDTO> getChapter(@PathVariable Long chapterId) { ChapterDetailDTO dto = chapterService.getChapterDetail(chapterId); return Result.success(dto); }

Service 层是重点，要做三步：查当前章、查下一章、更新阅读进度：

public ChapterDetailDTO getChapterDetail(Long chapterId) { Chapter current = chapterMapper.selectById(chapterId); if (current == null) { throw new BusinessException("章节不存在"); } // 当前章节的下一章：同一本书、章节号比当前大1 Chapter next = chapterMapper.selectOne(new LambdaQueryWrapper<Chapter>() .eq(Chapter::getBookId, current.getBookId()) .gt(Chapter::getChapterNo, current.getChapterNo()) .orderByAsc(Chapter::getChapterNo) .last("LIMIT 1")); ChapterDetailDTO dto = new ChapterDetailDTO(); dto.setBookId(current.getBookId()); dto.setChapterId(current.getId()); dto.setChapterNo(current.getChapterNo()); dto.setTitle(current.getTitle()); dto.setContent(current.getContent()); dto.setNextChapterId(next == null ? null : next.getId()); return dto; }

这个接口有一个隐藏设计点：nextChapterId是 null 时表示全书已读完，前端读到 null 就不显示“下一章”按钮，而显示“已完结”。有些源码会把完结判断放在前端用 chapterNo 和总章数比较，但这样每次都要查总章数，多一次查询。

更新阅读进度我单独放在另一个接口里，由前端在页面卸载时调用，这样设计的好处是阅读正文的接口不掺杂写操作，浏览器的频繁刷新不会产生大量 UPDATE 语句：

// 前端在页面隐藏或离开时上报进度 window.addEventListener('beforeunload', () => { navigator.sendBeacon('/api/progress/report', JSON.stringify({ bookId: currentBookId, chapterId: currentChapterId, chapterNo: currentChapterNo, scrollOffset: window.scrollY })); });

用sendBeacon发送进度上报是实际项目里的常用做法，比fetch更可靠，因为页面卸载时fetch请求极大概率被浏览器取消，而sendBeacon会保证请求送达。这里我把scrollOffset一并上报，配合表设计里预留的字段，就完成了从书架到阅读页的进度闭环。

3.3 进度上报接口：INSERT ON DUPLICATE KEY UPDATE

服务端接收进度上报时，如果我先查一条进度记录，存在则更新，不存在则插入，那刚打开一本书时会多出一次 SELECT，并且并发场景下可能插入两条记录，造成唯一键冲突。更稳的做法是用 MySQL 的ON DUPLICATE KEY UPDATE一次搞定：

@PostMapping("/progress/report") public Result<Void> reportProgress(@RequestBody ProgressReportDTO dto) { progressMapper.report(dto.getUserId(), dto.getBookId(), dto.getChapterId(), dto.getChapterNo(), dto.getScrollOffset()); return Result.success(); }

对应的 Mapper SQL：

<insert id="report"> INSERT INTO reading_progress (user_id, book_id, chapter_id, chapter_no, scroll_offset) VALUES (#{userId}, #{bookId}, #{chapterId}, #{chapterNo}, #{scrollOffset}) ON DUPLICATE KEY UPDATE chapter_id = VALUES(chapter_id), chapter_no = VALUES(chapter_no), scroll_offset = VALUES(scroll_offset) </insert>

这个写法的妙处在于，无论记录是否存在，都只需要一次 SQL 往返。VALUES()函数在 MySQL 8.0.20 之后标记为废弃，但功能仍然可用，课设项目里用没有问题；如果想要更规范的写法，可以改成AS new ON DUPLICATE KEY UPDATE chapter_id = new.chapter_id的别名语法。

各参数传递时注意类型一致性，chapterId是 Long，scrollOffset是 Integer，Jackson 反序列化时如果前端传了字符串，需要确认不会因类型转换报错。我建议前端统一用数字类型，避免把scrollOffset写成"123px"这种带单位的字符串。

4. 从源码到论文：把代码逻辑翻译成文字和图表

4.1 论文结构怎么对应源码模块

拿到一套完整的源码后，很多人的问题是“代码能跑，但论文写不出来”。这是因为写论文时没有按照软件工程的视角重新组织代码，而是按代码的执行顺序去讲。写小说阅读系统的论文，本质上是在回答三个问题：系统要做什么、怎么设计、怎么实现。对应的源码模块分别是：需求分析阶段看接口文档和原型，概要设计阶段看数据库表和系统架构图，详细设计阶段看核心类的时序图。

论文目录通常可以这样映射：

这里有一个答辩时很加分的技巧：把数据库的 E-R 图画清楚。很多论文里的 E-R 图画得过于复杂，把每个字段都标出来，反而看不清实体之间的关系。小说阅读系统的实体关系很简单，用户、书籍、章节、阅读进度四个方框，连上四条线，标注一对多关系就够了。

4.2 设计模式在看代码时怎么识别

小说阅读系统虽然规模不大，但源码里其实隐藏着几个常见设计模式。识别它们不仅有助于理解代码，论文里也可以在“系统设计”章节提到，属于亮点之一。

最常见的模板方法模式出现在 Service 层。比如书籍列表、章节列表、书架列表这几类查询，逻辑都是“参数校验 → 查库 → 转换 VO → 返回”，这个流程可以用抽象基类固定下来，子类只实现查询逻辑。看代码时如果发现某个 Service 类继承了一个抽象父类，父类里定义了protected abstract方法，基本上就是这个模式。

观察者模式则可以用在“阅读进度变更”的监听上：用户上报进度后，除了更新reading_progress表，还可以触发“最近阅读列表更新”“用户阅读时长统计”这类监听器。课设项目不一定实现了这个模式，但只要在论文里提出这个设计思路，评委就会认为你想过扩展性。

4.3 答辩演示的节奏：先走主流程，再展示数据设计

答辩演示是源码项目最容易翻车的地方。我的血泪经验是：不要从登录页开始演示，那太无聊，评委听了一整天，注意力早就不集中了。直接打开书架，展示一个有多本书、有进度的界面，然后点进一本有阅读进度的书，让页面自动恢复到最后阅读位置，滚动到某个位置刷新页面，验证进度没有丢。

这个演示路径背后的逻辑是：先验证“进度存储”这个核心卖点，再顺手提一句“这是通过reading_progress表的唯一索引和ON DUPLICATE KEY UPDATE实现的”。之后再去展示后台管理功能，比如添加书籍、导入章节。整个演示不超过五分钟，但每一步都在强调设计亮点。

5. 避坑指南：小说阅读系统的 5 个常见问题

5.1 前端传的进度永远比实际少一章

现象：用户读完第 10 章，返回书架，显示读到第 9 章，再点进去又从第 9 章开始。

原因：前端在beforeunload里上报的chapterId是当前页面已经渲染出来的章节，但用户可能正在阅读页里点了“下一章”按钮，页面还没加载完新章节就触发了卸载事件，上报的还是旧章节的 ID。更深层的原因是，章节跳转用的是<a>标签，点击后会立即触发页面刷新，beforeunload事件竞争不过浏览器的导航流程。

解决：在点击“下一章”时，先把目标章节的信息存入sessionStorage，beforeunload时优先取缓存里的值上报，没有缓存再取当前页面的章节信息。这样即使页面还没渲染完成，进度也不会丢。

5.2 多本书阅读进度互相覆盖

现象：用户看完 A 书，再看 B 书，返回 A 书时进度变成了 B 书的进度。

原因：前端上报进度时用localStorage保存了全局的“当前章节”，但这个变量是全局的，切换书籍时没有被重置。后端虽然区分了book_id，但前端取章节 ID 时取的是缓存值，导致请求体里bookId是 A 书，chapterId却是 B 书的章节 ID，后端更新时又信任了chapterId对应的章节内容。

解决：前端以bookId为维度管理阅读状态，书架点击事件里要显式调用resetReader()，同时后端在上报进度前校验chapterId属于bookId，不属于则拒绝写入。这个校验逻辑只需一条查询：

// 更新进度前校验章节归属 boolean exists = chapterMapper.exists(new LambdaQueryWrapper<Chapter>() .eq(Chapter::getId, dto.getChapterId()) .eq(Chapter::getBookId, dto.getBookId())); if (!exists) { throw new BusinessException("章节与书籍不匹配"); }

5.3 小说正文中带 HTML 标签导致页面错乱

现象：某章内容在页面上时而正常，时而出现大量空格或换行丢失；有些章节没有段落缩进。

原因：导入的 txt 文件里，章节内容包含原始的空格、换行、全角符号，而前端用v-html渲染，如果正文里恰好有<字符（比如数学公式），就会被浏览器解析成标签，导致页面整体塌陷。另一个常见点是段落划分，纯文本的换行是\n，在 HTML 中不会被渲染成换行。

解决：后端在返回章节内容之前做一次清洗，把\n替换为<p>标签，并把特殊字符转义。常见做法是把每个自然段用两个换行符切分，包裹成段落标签后拼接：

public String formatContent(String rawContent) { if (rawContent == null) return ""; // 统一换行符 String normalized = rawContent.replace("\r\n", "\n"); // 按空行切分段落 String[] paragraphs = normalized.split("\n\n"); return Arrays.stream(paragraphs) .map(p -> "<p>" + p.replace("\n", "<br/>") + "</p>") .collect(Collectors.joining()); }

清洗时注意不要把正文里的引号误伤，只处理换行和尖括号就够用。前端渲染时也要配合v-html而不是{{ }}插值，否则段落标签会被当成文本显示。

5.4 搜索功能慢得离谱，关键词一多就超时

现象：搜索“修仙”很快，但搜索“主角 穿越 系统 无敌”这类多关键词时，接口响应时间超过三秒。

原因：这是典型的LIKE '%关键词%'全表扫描问题。搜索关键词多的时候，SQL 变成WHERE title LIKE '%主%' OR title LIKE '%角%'，MySQL 无法用索引，只能逐行匹配。数据量几千本书时勉强能接受，一旦章节数破万，查询就直接变慢。

解决：最简单的方案是把搜索限定在书名和作者字段上，不搜索正文，并在title字段上建立全文索引。MySQL 的FULLTEXT索引用自然语言模式可以做到秒级返回：

ALTER TABLE book ADD FULLTEXT INDEX ft_title (title);

查询时用MATCH(title) AGAINST ('修仙 穿越' IN NATURAL LANGUAGE MODE)替代LIKE。如果课设要求里没有搜索正文的需求，直接限制“只搜书名”，加上索引后性能问题基本消失。

5.5 部署到服务器后封面图全部损坏

现象：本地开发时封面图正常，部署到云服务器后所有书籍封面都变成裂图。

原因：本地图片是直接放在项目static目录下的，而部署时是把项目打成 jar 包运行，Spring Boot 不会把 jar 内的static文件暴露为静态资源路径。同时，图片路径在本地写的是相对路径/images/1.jpg，部署后域名变了但路径没变，所以 404。

解决：最常见做法是把封面上传到服务器磁盘的独立目录（如/data/www/novel/cover），然后在 Nginx 里配置静态资源映射。Spring Boot 里不用存图片，只存 URL 路径，部署时就能和前端代码解耦。本地开发时可以在application.yml中配置本地目录对应关系：

spring: web: resources: static-locations: file:/data/www/novel/,classpath:/static/

这样本地读 classpath，服务器读磁盘，代码不需要改。这个坑的隐蔽之处在于本地永远测不出来，一定要到部署环节才暴露，所以在写部署文档时我会把那台服务器的路径和权限单独写清楚。

6. 进阶玩法：给小说阅读系统加一个“最近阅读”的缓存层

主流程跑通之后，系统已经能用了，但性能上还有两个明显可以优化的点：书架列表每次都要联表查询，用户频繁访问的章节每次都查库。这两个场景都非常适合加缓存，特别是用 Redis 做书架聚合数据的缓存。

常见做法是，书架列表的 key 设置为user:bookshelf:{userId}，首次查询时把联表结果放入缓存，设置 5 分钟过期。之后用户访问书架直接从 Redis 读取，不再走 MySQL 联表。用户阅读某一章后，需要主动删除该书架的缓存，否则书架上的“读到第几章”会滞后一期：

@CacheEvict(value = "bookshelf", key = "#userId") public void reportProgress(Long userId, ProgressReportDTO dto) { // 原有的进度上报逻辑 }

在 Spring Boot 里用@CacheEvict注解比手动调用redisTemplate.delete()干净得多，并且不侵入业务代码。这个设计属于“看得到性价比”的优化，代码量不大，但对接口响应速度的提升是数量级的，从几十毫秒降到几毫秒。

如果不想引入 Redis，也可以用 Caffeine 本地缓存，更适合课设项目里“部署简单”的诉求。但要注意本地缓存在多实例部署时会出现数据不一致，如果论文里只部署单机，Caffeine 完全够用。

这类优化我一般放在主流程完成之后再做，顺序很重要：先把进度闭环跑通，再考虑缓存，不要一开始就在缓存上设计，容易过度工程。做完整套优化之后，我最深的体会是：小说阅读系统的难度不在地层的算法，而在数据之间的关系梳理和边界情况的处理——你读完第 1 章跳到第 100 章会怎样、断网时点下一章会怎样、同一本书多端同时读会怎样。把这些边界情况都想清楚，一个课设项目的含金量远超那些只是堆了页面和接口的“源码站”模板。希望这篇笔记能帮你在自己的项目里少走几步弯路。

本文还有配套的精品资源，点击获取