SpringBoot毕设项目实战：小说阅读平台全栈开发指南

1. 选题价值与功能设计拆解

1.1 为什么是“小说阅读平台”这类选题

每年到毕设季，Java方向的学生问得最多的就是“老师，SpringBoot选题选什么好”。我做了这么多年开发和带毕设的经验，小说阅读平台这类题目几乎是Java Web方向里的“常青树”，原因很简单：它覆盖的技术点够全，但又不是什么都往上堆。

一个完整的小说阅读平台，用户端要做注册登录、小说浏览、分类检索、书架收藏、阅读记录、章节翻页、评论互动；管理端要做小说录入、章节管理、用户管理、数据统计。这一套下来，SpringBoot的控制器层、服务层、持久层全用上了，MySQL的表设计和关联查询也练到了，前端页面不管是Thymeleaf模板还是Vue分离都能接得住。

更关键的一点是，小说阅读平台的业务逻辑非常直观，不需要你有什么行业背景。电商你得理解订单状态机、库存扣减，支付你得了解对账流程，但小说平台的逻辑就是一个“用户看书”的场景，需求分析阶段不会卡壳，中期答辩不至于被老师问到说不出话。

从工作量评估的角度看，一个学生从零开始做这个选题，数据库设计2到3天，后端接口开发2周左右，前端页面1到2周，联调测试加写论文1周，整体4到6周是能完成的。相比那些动辄涉及高并发、分布式、消息队列的选题，这个工作量对大多数本科生来说刚刚好——既不会轻松到让老师觉得你什么都没做，也不会难到你中期就想换题。

1.2 核心功能模块的完整拆解

我建议把功能拆成用户端和管理端两个大模块，每个模块再往下细分成几个子功能，这也是毕业设计论文里“功能需求分析”章节的标准写法。

用户端这边，第一块是账号体系：注册、登录、修改密码、退出登录。这里不建议做邮箱验证码激活——太麻烦，答辩的时候还得现场演示发邮件，很容易翻车。用简单的用户名加密码注册就够了，密码用MD5加盐或者BCrypt加密存储，能讲出加密的原理就行。

第二块是小说浏览：首页展示推荐小说和分类入口，分类可以按“玄幻、都市、科幻、历史、悬疑”这种常规网文分类来定。列表页支持分页浏览，小说详情页展示封面、作者、简介、字数、状态（连载中/已完结）、最新章节信息。这部分考察的是条件查询和分页，是面试和答辩都喜欢问的点。

第三块是阅读功能，这也是和普通CRUD拉开差距的地方。小说详情页点“开始阅读”进入章节阅读页，章节的“上一章”“下一章”切换要有，阅读进度要记录，下次打开能跳转到上次读到的位置。进度记录这个功能，很多同学会忽略，但加上之后整个项目的完成度立刻不一样，论文里可以单独写一小节。

第四块是书架和评论。书架就是收藏功能，把感兴趣的小说加进去，方便下次直接看。评论是用户对小说或者章节发表评论，列表展示。这块涉及多表关联查询，论文里可以写“实现了用户与小说之间的多对多关系及一对多评论关系”，听起来就很规范。

管理端这边相对简单：管理员登录、小说管理（增删改查、上下架）、章节管理（按小说维护章节列表、内容录入）、用户管理（查看用户列表、禁用账号）、数据统计（小说总数、用户总数、评论总数，可以用图表展示）。五块功能做下来，管理端的CRUD风格统一，开发起来效率高，而且论文里能写的点一点都不少。

1.3 这个选题可以延伸发挥的加分项

如果只满足于上面的功能，这个项目能拿个中等偏上的分数。但如果你想让项目看起来更有亮点，有几个方向可以加——不至于把工作量翻倍，但答辩的时候明显有东西可讲。

第一个加分项是阅读进度断点续读。这个上面已经提到了，但我要强调它的实现价值：设计一张用户阅读记录表，每次进入章节页时更新记录，回到书架时按记录跳转。这是一个很贴近真实产品的功能，而且实现成本很低，表结构加一个字段的事。

第二个加分项是全文搜索。可以用MySQL的LIKE模糊查询先顶住，简单直接，答辩能糊弄过去；如果想显得高级一点，引入Elasticsearch对小说标题和简介建立索引。如果不想折腾ES，MySQL的全文索引也够用，论文里写“基于倒排索引的全文检索实现”就够了。我的建议是先用LIKE，论文和答辩讲清楚场景，Elasticsearch等有精力再说。

第三个加分项是排行榜。日榜、周榜、总榜，按点击量或者收藏量排序。这本质上就是一个带条件的分组统计SQL，GROUP BY加ORDER BY，几分钟就能写完，但视觉效果和功能完整度提升非常明显。

第四个加分项是评论的二级回复，也就是“回复某人的评论”。在多了一张评论表的基础上加一个parent_id字段，自己关联自己就行了，技术上不难，但业务上会显得你的项目思考得很细。

我不建议碰的方向是：分布式部署、消息队列、Redis缓存、微服务拆分。这些名词在毕设答辩里不是加分项，因为你真把它做出来撑不起来，反而会被老师追问到怀疑人生。这个选题老老实实把单体架构做深做透，比堆技术栈有用得多。选对复杂度，是毕设成功的一半。

2. 核心技术栈选型与理由

2.1 SpringBoot版本到底怎么选

技术选型这块，我见过太多学生栽在版本搭配上。很多初学SpringBoot的人一上来就用3.x版本，结果MyBatis的适配包找不到、JDK版本要求17以上、一些老教程的配置方式完全不兼容，光折腾环境就花了一周。

我的建议很明确：老老实实选SpringBoot 2.7.x系列，配JDK 1.8。原因有三个：一是网上能找到的教程、博客、参考代码绝大多数是2.x版本的，你遇到问题搜索解决方案时命中率高得多；二是毕设项目用不到SpringBoot 3.x的新特性，虚拟线程、GraalVM原生镜像这些和你的项目没有半点关系；三是JDK 1.8是大多数高校机房和老师电脑上的默认版本，你做演示的时候不会因为环境问题翻车。

具体版本组合，我常用的配置是：SpringBoot 2.7.18、JDK 1.8、MySQL 5.7或者8.0都行（建议5.7，兼容性更好）、MyBatis Plus 3.5.x替代原生MyBatis。这里多说一句，用MyBatis Plus而不是纯MyBatis，是因为它的BaseMapper内置了增删改查方法，单表操作不用自己写XML，开发效率至少提高30%。答辩的时候老师如果问“你用什么持久层框架”，你答“MyBatis Plus，它是在MyBatis基础上的增强工具，单表操作不需要拼SQL”，这句话就能证明你不是只会复制粘贴。

2.2 前端方案：模板引擎还是前后端分离

前端方案是另一个容易纠结的地方。我见过几种典型组合：纯Thymeleaf模板、Thymeleaf加Bootstrap、Vue分离、Vue加Element UI。每种都有各自的适用场景，需要结合你的实际情况来选。

保守方案是Thymeleaf加Bootstrap。Thymeleaf是SpringBoot官方推荐的模板引擎，最大的优势是前后端不分离，但后端可以往页面里直接填充数据，模型数据用Model对象传给视图，在HTML里用th:each、th:if这些标签渲染列表和条件。对大多数学生来说，一套Bootstrap响应式页面把用户端和管理端都包了，不需要会Vue的响应式原理和数据绑定，学习和调试成本最低。缺点也很明显：页面刷新的交互体验比较“传统”，但作为毕设完全够用。

想显得更现代的方案是Vue分离。Vue 2加Element UI（注意Vue 3对应的是Element Plus），前后端通过JSON数据交互。这种方案视觉效果好、答辩演示起来加分，但开发量会变大：需要单独处理跨域问题、接口风格更规范（用RESTful风格设计API）、前端调试要开两个服务（前端Node服务加后端SpringBoot服务）。如果你的前端基础比较好或者有几个月的Vue使用经验，选这条路没问题；如果是零基础，我不建议在毕设期间从零学Vue。

个人最推荐的是Thymeleaf加Bootstrap的保守方案，因为毕设的核心评分点在“业务完整性”和“后端设计”上，页面只要能清爽有层次，老师不会因为你没用Vue而扣分。反过来，用了Vue但CORS跨域没配好、请求一直报错，反而影响演示效果。

2.3 数据库：MySQL的版本与配置细节

MySQL这块，5.7是当前最稳妥的选择。虽然官方已经在推进8.0，但很多老机器上MySQL 5.7的服务开箱即用，5.7的sql_mode默认配置也更宽松。不过如果你已经装了8.0也不用换，8.0和5.7对毕设项目的区别主要在建连驱动和时区配置上，functionality层面影响很小。

连接配置是必踩的坑之一。在application.yml里配置数据源时，如果MySQL是8.0版本，驱动类要用com.mysql.cj.jdbc.Driver，URL里建议加上useSSL=false&serverTimezone=Asia/Shanghai这两个参数。前者是关闭SSL加密连接避免本地连接警告，后者是把时区对齐到东八区解决“Server returns invalid timezone”的报错。很多同学第一次连8.0版MySQL时遇到连接失败，排查到最后就是时区没配置。

字符集问题也得提前处理。MySQL服务端的字符集建议在my.cnf里统一设置为utf8mb4，为什么用utf8mb4而不是utf8？因为utf8mb4是utf8的超集，能存四字节的Emoji表情和生僻字。小说内容里万一出现特殊字符，utf8mb4不会报错，而utf8在某些情况下会因字节数超限导致插入失败。建表的时候也建议给每个表都明确指定ENGINE=InnoDB DEFAULT CHARSET=utf8mb4。

字符编码这块还要注意连接层的设置：characterEncoding=utf-8这个参数加在JDBC URL里，保证Java在读写中文时不会出现乱码。三个层面——服务端、表结构、连接串——全部对齐成utf8mb4，乱码问题就能彻底从源头解决。

3. 数据库表设计与核心流程实现

3.1 六张核心表的结构设计

小说阅读平台我建议设计六张表，不多不少正好覆盖全部功能。数据库设计这块是论文里的重头戏，每张表都要能讲清楚业务含义和字段设计理由。

第一张是用户表，字段包括id、username、password、nickname、avatar、email、role（区分普通用户和管理员）、status（启用或禁用）、create_time。password字段记得存加密后的密文，长度设64位就够用。role字段用tinyint就行，1是管理员，0是普通用户，登录后根据角色跳转不同首页。

第二张是小说的分类表：id、category_name、sort_order。这个表结构非常简单，但要注意分类数据需要手动初始化，在项目启动时用CommandLineRunner接口往表里插入默认数据，或者直接在SQL脚本里写好插入语句。

第三张是小说信息表，这是核心中的核心。建议字段有：id、book_name、author、category_id（关联分类表）、intro、cover_url、status（1连载，0完结）、click_count、favorite_count、chapter_count（冗余字段，方便列表展示总章数而不需要每次COUNT查询）、create_time、update_time。这里有两个设计亮点：一是category_id外键关联但不在数据库里实际建物理外键约束，用逻辑外键的方式在Java代码里维护关联关系，这样查询灵活、删除方便，论文里可以写“为了降低耦合，采用逻辑外键而非物理外键”；二是chapter_count这类冗余字段能避免多表关联COUNT的复杂SQL。

第四张是章节表：id、book_id（关联小说表）、chapter_no（章节序号）、chapter_title、content（用longtext存储正文）、word_count、create_time。新增章节时要同步更新小说表里的chapter_count字段，事务要加在service层保证两个操作的一致性。

第五张是书架表：id、user_id、book_id、create_time，联合唯一索引unique(user_id, book_id)防止重复收藏。

第六张是评论表和阅读记录表。评论表：id、book_id、user_id、content、create_time、parent_id（可空，为空表示顶级评论，非空表示二级回复）；阅读记录表：id、user_id、book_id、chapter_id、update_time，每次阅读时更新，查询时取出记录跳转到对应章节。

这套表设计能满足所有功能需求，而且每张表都有明确业务含义，答辩讲数据模型设计时能从头到尾串起来。

3.2 关键SQL与接口的设计思路

表结构定下来之后，有几个核心的查询和接口要提前想清楚。

第一个是小说列表的分页查询。前端需要传current和pageSize两个参数，后端用MyBatis Plus的Page对象做分页。分页查询的核心是条件的动态拼装，比如按分类、按关键字、按状态过滤，MyBatis Plus的LambdaQueryWrapper用eq和like方法就能拼出来，不需要手写动态SQL。

第二个是小说的详情信息查。一个小说详情页需要的小说基本信息、分类名、最新章节信息，涉及三张表。这里有两种做法：一是写多表关联SQL用JOIN一次查出来；二是先查小说表再分别查分类和最新章节。我更推荐第一种，虽然MyBatis Plus不太擅长JOIN，但可以自定义Mapper方法，在XML里写一条带LEFT JOIN的SQL把小说信息和分类名一起查出来，效率高、语义清晰。

第三个是阅读记录写入。每次用户进入章节阅读页时更新阅读记录表的逻辑是：先select判断是否存在该用户加该小说的记录，存在则update为当前章节，不存在则insert。用MyBatis Plus的selectOne加saveOrUpdate两步操作搞定，但要注意并发情况下可能会重复插入，所以数据库表设计时建议给user_id加book_id加联合索引，保证唯一性。

第四个是评论的列表展示。查询一篇小说下的所有评论并同步显示评论人的用户名，这需要评论表JOIN用户表。如果想实现二级回复，需要先把顶级评论查出来，再按parent_id批量查询子评论组装成树形结构。这个逻辑工作量不大但能体现你处理复杂数据的能力，论文里专门写一节“树形评论数据的组装”就很有说服力。

代码层面，接口遵循RESTful风格：GET /api/book/page是分页查询，GET /api/book/{id}是详情，POST /api/user/login是登录，PUT /api/user/password是修改密码。返回结果统一封装成Result对象，包括code、message、data三个字段。这个Result类是面试常问的“统一返回结构”，实际开发中也是标配。

3.3 事务、拦截器与全局异常处理

业务逻辑之外的三个技术细节，往往是答辩时老师考察你“有没有开发经验”的地方。

事务方面：添加章节要更新小说表的总章节数，这个操作涉及两张表的写入，必须加@Transactional注解保证原子性。这里有个细节要注意，Spring事务默认只在RuntimeException时回滚，如果方法中catch了异常但没有抛出RuntimeException，事务是不会回滚的。所以建议在catch块中手动throw new RuntimeException("XXX失败")或者在注解上标记rollbackFor = Exception.class。

登录拦截用HandlerInterceptor实现：写一个LoginInterceptor实现preHandle方法，从Session中判断用户是否已登录，未登录就重定向到登录页或返回JSON提示信息。注册拦截器时用WebMvcConfigure注册器，addInterceptors方法里addPathPatterns设置拦截路径和excludePathPatterns设置放行路径（登录页、注册接口、小说列表这些不需要登录就能访问）。

全局异常处理用@RestControllerAdvice结合@ExceptionHandler注解。创建一个GlobalExceptionHandler类，分别处理业务异常（比如用户名已存在）、参数校验异常（MethodArgumentNotValidException）和兜底的Exception。这样controller层就不用每个方法都写try-catch，错误信息也能统一格式返回给前端显示。这个小模块写下来不超过30行代码，但论文明细里的“全局异常处理机制”一节就有内容可写了。

4. 开发环境搭建与项目的初始化

4.1 本地开发环境准备清单

开始写代码之前，先把开发环境一次性配好，这块配置时间和学习成本值得花，环境不统一后面每步都会出问题。

环境推荐清单：JDK 1.8（安装后配置JAVA_HOME环境变量）、Maven 3.6以上（配置本地仓库镜像为阿里云镜像加速依赖下载）、IDE用IntelliJ IDEA（社区版完全够用，不需要旗舰版）、MySQL 5.7或8.0（安装时注意记住root密码）、Navicat或DataGrip作为数据库图形化客户端、前端如果走Thymeleaf方案不需要额外装Node环境。

Maven的镜像配置很容易被忽略。默认的中央仓库在国内下载SpringBoot依赖非常慢，在Maven的settings.xml里加阿里云镜像配置：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

配好之后，第一次拉取SpringBoot全家桶依赖的速度能从十几分钟降到一两分钟。

4.2 SpringBoot项目的初始化步骤

建议直接到Spring官方Initializr页面生成项目骨架，而不是自己手动搭目录。选择Maven工程、打包方式jar、Java版本8、SpringBoot版本2.7.x，依赖勾选Web、Thymeleaf、MySQL Driver、MyBatis Plus（注意官方生成器没有MyBatis Plus选项，需要自己在pom.xml里添加）。

生成后pom.xml手动添加几个依赖：MyBatis Plus的SpringBoot Starter、Lombok（减少实体类的getter/setter代码）、Druid数据源或HikariCP（SpringBoot默认用HikariCP，其实不用额外引入，但如果你想要Druid监控页面可以替换）、commons-lang3（一些字符串和对象的工具类）。

项目目录结构按标准分包：controller、service（下面可以分impl子包）、mapper、entity、config、common（放统一返回结果和异常处理）。entity目录对应数据库表实体，用@TableName注解关联表名，字段用驼峰命名法对应数据库下划线字段，MyBatis Plus默认开启驼峰转换。

启动类上添加@MapperScan注解扫描mapper接口，这样不用每个Mapper都单独加@Mapper注解。

4.3 MySQL数据库初始化脚本的准备

数据库初始化是一个容易被低估的环节。我建议写一个完整的init.sql脚本，包含库创建、表创建、基础数据插入三部分，用Navicat执行一次就能得到可用的初始数据库。

初始化数据至少要包含：1个管理员账号（admin/admin123就是常规操作，毕业设计不需要把密码搞复杂）、1个普通测试账号（test/123456）、5到10条分类数据、20部小说数据（每部小说至少5个章节），这样第一次启动项目就能看到列表有内容，演示效果完整。

这里有个经验之谈：小说正文数据用真实网文的一段文字即可，但注意版权问题，随便写几十个字或者用“这是一段测试内容”打底就行，一是在线演示不需要完整内容，二是避免不必要的版权风险。重点是表结构和页面效果，内容只是填充物。

5. 核心功能的代码实现与解析

5.1 登录注册与Session会话管理

登录注册是第一个需要实现的功能模块，也往往是答辩的第一个操作演示。注册接口接收username、password、nickname三个参数，处理逻辑是：先查用户名是否存在，存在则抛出业务异常“用户名已被注册”，不存在则对密码做BCrypt加密后insert用户记录。这里用BCrypt而不是MD5，原因是BCrypt是哈希算法会内置随机盐值，相同的密码每次加密结果不同，安全性远高于MD5。答辩被问到为什么不直接用MD5，你就可以从这个角度回答。

登录接口的处理更完整：根据用户名查用户记录，BCrypt的matches方法比对密码，校验通过后把用户信息存入Session。注意区分用户管理员和普通用户：登录成功后前端根据role字段跳转到不同的系统入口。登录状态拦截器前面提到的LoginInterceptor就在这一步派上用场，所有需要登录的接口都进来的第一步校验Session里是否存在用户数据。

一个小坑提醒：Session失效时间默认是30分钟无操作自动过期，可以在application.properties里配置server.servlet.session.timeout=60m调到60分钟，防止演示到一半被退出登录。

5.2 小说的分页列表与详情展示

小说列表页是整个平台的门面，实现质量直接影响第一印象。推荐的做法是：Controller接收pageNum和pageSize参数，用MyBatis Plus的Page对象作为条件构造器的参数，返回的IPage结果里天然包含了records列表、total总数、pages总页数等数据，前端只需要循环渲染数据，分页组件用Bootstrap的pagination做一个简单的上一页下一页就够。

列表页的筛选条件建议至少支持分类过滤和关键字模糊搜索两个维度。分类可以用下拉框选择，关键字搜索小说名和作者。条件组装时用LambdaQueryWrapper，语法是这样的：

LambdaQueryWrapper<Book> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.isNotBlank(keyword)) { wrapper.like(Book::getBookName, keyword).or().like(Book::getAuthor, keyword); } if (categoryId != null) { wrapper.eq(Book::getCategoryId, categoryId); }

注意or条件和eq条件混用时，MyBatis Plus会自动加上括号，但为了保险起见，复杂条件我还是建议自己加and和or的组合，别依赖自动加括号的逻辑，排查问题时容易绕晕。

详情页的设计是重点。除了小说基本信息，建议在页面下方做成“目录”形式展示全部章节，点击目录项跳转到章节阅读页。目录列表同样考虑分页——小说如果有一千章，一次性查出来会几百KB的传输量，分页加载用户体验更好且SQL压力小。计算字数这种指标，可以让前端在demo字数，也可以后端在新增章节时同步到字段里。

5.3 章节阅读与进度记录

章节阅读页是小说业务的核心交互，实现要点有两个：章节内容的展示和上下章的切换。章节内容直接用chapter实体带content字段查出来，然后th:utext渲染HTML，这样数据库存的是什么前端就显示什么，支持将来富文本编辑器的扩展。

上下章的切换有一个简单好用的方法：查章节的时候同时查出当前章的chapterNo，上一章按order by chapter_no desc limit 1查出小于当前编号的第一条；下一章用order by chapter_no asc limit 1查出大于当前编号的第一条。这样无论编号是否连续都能正确跳转。

进度记录强调的是“何时记录”和“记录什么”。我建议用户进入章节页时后台立即记录进度，而不是等用户退出时才记录。实现方法是进入页面的Controller方法里，先查询阅读记录表中该用户加该小说的记录是否存在，存在则更新chapter_id和update_time，不存在则插入一条新记录。进度保存后，书架和详情页会显示“最近阅读到第X章”，点击跳转就是这个逻辑。

断开继续读的状态还有一个额外好处：写论文时可以画一个“用户阅读时序图”，从进入平台、搜索小说、进入详情、点击阅读、记录进度到退出阅读，一条链路非常完整，老师的印象分会明显不一样。

5.4 管理端的CRUD与数据维护

管理端的开发模式相对固定，以小说管理为例：列表展示用分页查询，新增和编辑共用一个页面，删除按钮加一个弹窗确认。

新增和编辑合并处理的做法：Controller先判断传入的id是否为空，为空则是新增，不为空则是更新。一个接口两个逻辑，前端也复用一个表单页面，减少大量重复代码。小说录入时封面图片的上传，本地开发推荐直接把图片Base64转成字节存到一个上传文件夹里，访问时通过虚拟路径映射到本地目录。因为毕设不需要处理大量图片的分布式存储，本地文件存储思路简单、调试方便。

管理端用户管理模块，除了列表展示，建议把“禁用/启用”功能做实。用户状态是字段status，禁用后登录时拦截器校验状态不为启用状态就提示“账号已被禁用”，这个能体现你对业务权限的思考，也能防止在演示时被负面情况打脸。

5.5 统一返回结果与异常处理

统一返回结果是个小细节，但在代码规范和答辩技术讨论中很受重视。新建Result类，包含code、message、data三个字段，提供静态工厂方法Result.success(data)和Result.error(code, message)。所有Controller方法的返回类型都改成Result，前端拿到的结构永远是：

{ "code": 200, "message": "成功", "data": {} }

这个风格是现在企业开发的标配，花十几分钟实现，答辩时讲代码规范就能直接拿这个举例。

全局异常处理配合着加。GlobalExceptionHandler里定义三个方法：处理业务异常（自定义BusinessException，比如登录失败、用户名存在、小说不存在）、处理参数校验异常（@Valid注解触发）、处理未知异常。业务异常的状态码用500还是200，我的建议是HTTP状态码统一200，业务状态码放code字段里区分。道理很简单：前端判断逻辑统一看body中的code就行，只看HTTP状态码容易出现200但业务失败、前端误以为成功的问题。

6. 调试技巧与常见问题排查

6.1 前后端联调时的经典错误处理

前后端联调阶段是最容易抓狂的，这里整理几个高频错误和处理方法。

跨域问题：如果前端是Vue分离开发，必会遇到CORS报错。解决办法有三个：后端加@CrossOrigin注解（局限性是只能加在Controller类上，多个类都要加很繁琐）、实现WebMvcConfigurer重写addCorsMappings全局配置（推荐）、或者用代理服务器转发（前端配置proxyTable把/api开头的请求转发到后端）。全局配置的写法：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

JSON序列化循环引用问题：实体类中如果Book关联了Category，序列化成JSON时可能递归嵌套。解决办法是在实体类的关系字段上标注@JsonIgnoreProperties或者把复杂关系用VO类隔离掉，不要让实体类直接暴露给前端。

数据库连接失败：通常检查三点——MySQL服务是否启动、URL中的ip端口是否正确（localhost和127.0.0.1有时在本机也会因为IPV6解析出错，可以用jdbc:mysql://127.0.0.1:3306/bookdb）、账号密码是否匹配。如果出现“Access denied for user”，检查是不是密码错了或者远程连接没开权限。

端口被占用：SpringBoot默认8080端口被某进程占用时，启动日志会显示端口绑定异常。两种解法：找到占用端口的进程kill掉，或者在配置里改成别的端口比如8081。改端口是最省事的，毕设项目端口用什么都不影响评分，但改名后记得告诉前端同学更新请求地址。

6.2 数据相关的坑位与解决办法

数据问题主要集中在字符编码、日期格式和数据类型映射三个地方。

乱码问题：页面显示中文乱码，先排查后端响应编码，在application.yml里配置server.servlet.encoding.force=true再加characterEncoding=UTF-8，确保响应头强制使用UTF-8。数据库表中中文乱码，检查数据库字符集是否为utf8mb4，表字符集是不是utf8mb4。如果已经存了错误数据，最简单的方式是把SQL文件导出修改字符集重新导入。

Date类型返回的格式问题：Java后端默认序列化Date类型返回给前端是时间戳数字（毫秒值），前端需要转格式，太不直观。配置统一的JSON序列化格式在application.yml：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这样所有接口返回的日期字段都自动变成人类可读格式。

MySQL的sql_mode导致的问题：如果本地MySQL 5.7开启了ONLY_FULL_GROUP_BY模式，GROUP BY查询严格情况下会报错。开发阶段建议把下面的配置放到my.cnf的mysqld节点下：

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

避免GROUP BY限制影响开发效率，生产环境再按需调整。

插入小说正文超长报错：如果content字段不小心用了varchar(255)，插入几百字的小说正文就会报“Data too long for column”错误。解决方法是把content字段类型改成longtext或者text，varchar最多65535字节且受行长度限制，不适合存长文本。

6.3 性能与体验的细节优化

毕设项目虽然不要求高并发，但有些东西做一下能明显提升使用体验，也能在答辩时体现你做事的细致程度。

第一，热门小说列表加缓存。可以用Spring Cache加@Cacheable注解缓存在内存中，缓存的key可以是“book:hot”，缓存时间为5分钟。这样高频访问的热门列表不会每次都查一次数据库，你可以正大光明在论文里写“利用Spring Cache实现对热数据的缓存，降低数据库压力”。实现方式很简单：在service方法的加@Cacheable(value = "hotBooks", key = "#categoryId")，再加一个@EnableCaching开启缓存支持。

第二，列表页的图片懒加载直接交给前端，在img标签上用loading="lazy"属性。一行代码的事，但对首页多张封面的加载体验提升明显，做技术分享的时候这个点也可以提一嘴。

第三，数据库索引使用。在用户表username字段加唯一索引（保证唯一登录名）、小说表category_id加普通索引（分类查询频繁）、章节表book_id加索引（章节查询根据书来查）。索引的使用是性能调优的基础，有索引和没索引在千万级数据量的查询性能差别是数量级的。毕设虽然数据量很小，但建索引的动作代表了规范意识。

7. 答辩准备与演示要点

7.1 演示时的功能演示动线设计

答辩演示是有套路可循的，好的演示动线能在十分钟内展现你所有的功能亮点和代码功底。

我建议的路径是：先演示管理员登录，展示管理端界面，快速说清楚小说管理、分类管理、用户管理这几个模块的功能，然后演示添加一本小说和对应章节的操作，说明数据如何维护。接着退出登录，用普通用户账号登录，重点演示首页浏览、按分类筛选、搜索小说、进入详情页、查看目录、阅读某一章节、点击上一章下一章、把小说加入书架、查看书架列表、回到阅读进度；最后走到评论区发表一条评论，展示评论列表。这一套走下来，前后端所有功能都被覆盖了一遍。

演示过程要提前至少完整演练两遍，重点检查两个环节：一是网络环境切换时前端资源加载是否正常（防止演示时CSS或JS文件加载超时导致页面错乱）；二是数据库是否处于初始状态，不要出现脏数据影响演示效果。

答辩过程中被问到“你这个项目最大的难点是什么”，我建议准备一个真实踩过坑的点来讲，不要泛泛而谈“解决了高并发下数据库压力”这种假大空的结论。比如你可以说“在实现阅读进度记录时，我遇到了并发情况下重复插入记录的问题，最后通过给user_id和book_id字段添加联合唯一索引，加上事务控制解决了”。这种具体的问题和解决方案，比任何高大上但经不起追问的描述都更有说服力。

7.2 论文写作的几个重点章节建议

论文框架常规按“绪论、相关技术介绍、系统分析、系统设计、系统实现、系统测试、总结、参考文献”组织，写作时有几个要点能让论文质量明显提升。

相关技术介绍章节不要写成网上抄下来的名词解释堆砌，而是围绕“为什么要选这个技术且怎么用的”来写。比如MyBatis Plus的介绍，就写清楚它是MyBatis的增强工具、内置了常用CRUD方法、本项目用它来减少SQL编写工作量。

系统分析章节中的可行性分析要结合本项目实际内容来写，技术可行性从JVM生态成熟度、开发工具丰富度、参考资源充足度分析，操作可行性考虑到管理员的界面操作简单、用户端交互直观。不要空泛地写“随着社会的发展，人们越来越重视精神生活”，这种套话一眼就会被发现是抄的。

系统测试章节除了写功能测试表格（测试用例编号、测试项、操作步骤、预期结果、实际结果、是否通过），也要加入接口测试的说明。可以写你用了Postman对关键接口做了测试，附上几个接口的请求和响应截图，比如登录接口返回token、分页查询接口返回records和total。这些细节能让老师确认你的代码是实际运行过的，不是只会写文档。

7.3 代码讲解环节的准备思路

代码讲解是让很多学生紧张的环节，但思路对了就能从容应对。老师大概率会随机打开你的Controller或Mapper文件，挑几个关键点问。你需要提前准备的内容包括：整个项目的目录结构（各包作用）、从浏览器请求到数据库响应的全链路（Controller接收参数、Service处理逻辑、Mapper操作数据库、返回JSON结果）、某个具体功能（比如登录）的完整实现代码走向。

强烈建议在答辩前自己模拟一次：把自己想象成老师，打开LoginController，问你“这段登录逻辑为什么要先查一次库再比对密码？”“你Session里存的是什么对象？”“如果用户密码错了你怎么告诉前端的？”——能流畅回答出这三个问题，登录这个功能基本就能过关了。

另一个容易问的点是“如果我想在你这上面加一个功能，怎么扩展？”有准备的话就很加分：比如加一个管理员删除评论的功能，先在前端管理页面添加按钮，再在Controller中添加delete接口，Service层通过id删除对应评论，由于评论表有parent_id字段，记得同时处理二级回复的孤儿数据。讲清楚思路，老师就知道你的项目结构是清晰可扩展的。

8. 常见问题与避坑手册

8.1 开发周期中最容易卡住的时间点

每年带毕设，我发现几个高频翻车的时间节点，在这里给正在做的同学提前打个预防针。

第一个卡点是环境搭建阶段，主要是版本不匹配问题：SpringBoot版本和JDK版本不一致、Maven依赖下载失败、MySQL驱动版本和服务端版本不匹配。应对方法是严格按我前面推荐的版本组合走，不要尝试最新版本或者随意升级。遇到依赖下载失败，检查Maven镜像是否配置了阿里云，mvn -v命令确认Maven运行正常，Maven本地仓库如果之前下过损坏的jar，把repository目录下对应的文件删掉重新下载。

第二个卡点是前后端联调阶段，主要卡在数据格式不一致上：后端返回的是驼峰命名的JSON字段，前端代码里用的却是下划线写法；或者日期格式不对、Integer类型和前端字符串比较时出现的类型错误。解决思路很简单：接口返回的数据结构一定要求统一，不要每个接口各写各的格式。定义一个VO类包裹返回结果，然后用Postman提前自测几个关键接口。

第三个卡点是论文查重阶段，很多同学代码写完留两周写论文，结果查重率40%以上被迫改到崩溃。应对方法：相关技术介绍、系统分析这些套话比较多的章节，用自己的话尽量重写；系统实现章节多贴自己的核心代码（代码查重不参与文字比对）加少量自然语言描述就够了；系统测试章节的表和截图也能稀释重复率。论文不要最后一周才开始写，至少提前三周动笔。

8.2 二次开发与扩展方向的建议

做完基础功能后，如果时间有富余，我的扩展优先级是：排行榜、评论二级回复、全书搜索、数据可视化大屏、Redis缓存热点数据、部署到云服务器。

其中部署到云服务器是性价比很高的一个加分项。买一台便宜的云服务器（学生机就行），装MySQL和JDK，打包成jar上传，用nohup命令后台运行，域名加Nginx反向代理。答辩时直接从服务器访问网址演示，效果比你电脑本地演示好一个档次，也体现了“实际部署经验”这个面试常问的点。

部署时经常遇到的一个坑是云服务器安全组没放行端口，比如默认8080端口没对外开放，外网完全无法访问。记得先在云控制台的安全组规则里放行8080端口。另一个坑是云服务器的MySQL默认绑定127.0.0.1，需要修改bind-address为0.0.0.0才能让公网访问，但不建议把数据库直接暴露到公网，你只需要本地连接服务器上的数据库时走SSH隧道即可，或者更稳妥的做法是只让后端应用在服务器本机连数据库，对外只暴露8080端口。

排行榜的实现思路：给小说的click_count字段加一个字段自增接口，用户每次阅读章节时调用UPDATE book SET click_count = click_count + 1 WHERE id = ?，排行榜按click_count或favorite_count排序Top10即可。

如果要加Redis缓存，建议从热门小说列表入手：读操作先查缓存，缓存没有再查数据库回填；写操作在修改小说后清理对应缓存。这个围绕热门页的Cache Aside模式最好讲清楚，是一个标准的Redis适用场景，也是面试中Redis缓存的常考题目。

8.3 时间安排的推荐节奏

最后给正在规划的同学一个参考节奏，以6周为标准周期：

第1周：完成环境搭建（JDK、Maven、MySQL、IDEA），生成项目骨架，数据库init.sql跑通，项目能启动起来。

第2周：实现用户注册登录、小说分类模块、小说信息的CRUD功能。

第3周：实现小说详情页、章节列表和章节阅读，打通前后端的数据链路。

第4周：实现评论、书架、收藏、阅读进度记录功能，管理端做完整。

第5周：联调测试、修复Bug、补全数据和细节（排行榜、搜索、状态管理），开始写论文的前两章。

第6周：论文完成、PPT制作、答辩演练。

这个时间表是按每天半天左右的学习和开发时间排的，如果全天投入，可以压缩到4周。多数卡壳的学生卡在前两周——不是代码写不出来，而是环境和版本问题消耗了太久。如果你照着这篇文章推荐的版本组合走，很大概率能避免这些问题。

8.4 常见问题速查表

我个人在实际开发中的体会是，上面表格里这九类问题，几乎每个学生至少踩中三到五个。不是因为你基础差，而是这些坑本身就“埋”得很深，只有真正写过一个完整项目的人才会知道。遇到的时候不用慌，先定位问题是在哪一层——是配置问题、SQL问题还是代码逻辑问题，然后从表里对应的方案入手排查，基本都能在半小时内解决。

最后再分享一个小技巧：写代码的过程中，每次完成一个小模块就顺手提交一次Git记录，留档的关键不是为了日记，而是为了论文里的“系统开发过程”、答辩说辞以及后期回溯。哪怕是单机开发，Git的提交历史也会在写实现章节时给你提供最真实的素材。这些真实的提交记录，远比答辩时“我这周每天都在写代码”的口头说明更有说服力。