简介在线小说阅读平台Java源码是一套基于Spring Boot与Vue的前后端分离项目适合Java初学者、毕业设计或课程设计者参考。平台围绕用户信息、小说展示与阅读等核心功能展开技术栈涵盖MySQL 5.7、MyBatisPlus、Maven、AJAX等可在Eclipse、IDEA等环境中运行。压缩包为zip格式体积约18.83MB具体文件总数与类型明细暂未披露内容预览显示资料包内含系统实现说明、用户信息/图片素材/视频素材等模块划分以及从选题动因、背景意义到相关技术介绍的章节式设计文档便于按章节理解项目结构。目前已有62人浏览学习适合需要快速搭建小说阅读网站、梳理SpringBoot项目分层与前后端联调思路的读者。借助这套源码可以重点学习用户管理、数据表设计与接口实现并参照目录结构完成毕业设计文档的撰写与答辩准备。1. 基于springboot的在线小说阅读平台从零搭一个能跑通全流程的后端骨架要说最近被问得最多的练手项目除了电商就是内容类平台。而基于springboot的在线小说阅读平台属于那种“看起来简单、做起来全是细节”的典型用户注册登录、书籍列表、章节阅读、阅读进度、书架收藏表面上是五张表的事真把接口设计、权限校验、缓存策略、异常处理串起来新手写一周很正常写出来能不能扛住并发又是另一回事。本文用一套可复现的Spring Boot工程把在线小说阅读平台的核心模块拆开讲跑通最小可行版本、说清每个接口为什么这样设计、参数怎么调、以及那些不跑到线上根本发现不了的坑。适合刚学完SSM或Spring Boot基础、想拿一个完整项目练手或做毕设的人也适合想快速搭一套内容类项目骨架的Java开发。2. 技术选型与工程搭建为什么是Spring Boot 2.7 MyBatis-Plus Redis2.1 版本选型避开Spring Boot 3.x的坑先聊版本。现在新建Spring Boot项目官方默认推3.x但如果是拿来部署到学生服务器、或者跑一些老教程里的代码我一般建议选2.7.x。原因很直接Spring Boot 3.0强制要求JDK 17而很多线上服务器和大部分教材还停在JDK 8另外3.x里javax.servlet换成了jakarta.servlet一些老工具和网上的博客代码直接迁移会报“包不存在”。pom.xml核心依赖如下parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies这段配置里mybatis-plus-boot-starter是核心。它内置了分页插件、代码生成器、条件构造器写CRUD少掉一半样板代码。需要注意的是 runtime MySQL驱动不需要参与编译运行时才会被加载如果把runtime误写成compile会导致打出的jar包体积变大而且没实际好处。JDK版本要在pom里显式指定不然Maven默认按JDK 8编译但环境是JDK 17会报“无效的目标发行版”properties java.version1.8/java.version maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target /propertiesSpring Boot 2.7.18是2.x的最后一个维护版本安全问题都已修复这是我能给的最稳组合。2.2 数据表设计先把在线小说阅读平台的五张表理清楚小说阅读平台和电商最大的区别是电商的订单是一次性数据小说的阅读进度是持续更新数据。建表时如果不好好设计唯一键后面做“最近阅读”“书架同步”都会很别扭。我常用的五张表如下CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT BCrypt加密后, nickname varchar(50) DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE book ( id bigint(20) NOT NULL AUTO_INCREMENT, book_name varchar(100) NOT NULL, author varchar(50) DEFAULT NULL, category_id int(11) DEFAULT NULL, intro text, cover_url varchar(255) DEFAULT NULL, word_count bigint(20) DEFAULT 0, status tinyint(4) DEFAULT 1 COMMENT 1连载 2完结, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE book_chapter ( id bigint(20) NOT NULL AUTO_INCREMENT, book_id bigint(20) NOT NULL, chapter_no int(11) NOT NULL COMMENT 章节序号从1开始, title varchar(200) NOT NULL, content longtext, word_count int(11) DEFAULT 0, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_book_chapter (book_id, chapter_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE user_book_shelf ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL, book_id bigint(20) NOT NULL, last_chapter_no int(11) DEFAULT 0 COMMENT 上次读到的章节, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_book (user_id, book_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE book_category ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(20) NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;有两个地方特别说明。一是book_chapter的chapter_no不要用自增主键当章节号——如果你要做章节重排、或从别的站点导入章节自增ID会乱掉。二是user_book_shelf里的UNIQUE KEY uk_user_book (user_id, book_id)这是关键的约束没有它用户重复收藏同一本书会产生脏数据。2.3 工程目录结构按Controller-Service-Mapper分层的约定小说阅读平台这种规模没必要上微服务一个单体应用拆好包足够了。我习惯按业务功能划分包com.example.novel ├── controller // 接口入口 │ ├── AuthController.java │ ├── BookController.java │ └── ChapterController.java ├── service // 业务逻辑 │ ├── UserService.java │ ├── BookService.java │ └── ChapterService.java ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto // 接收参数的对象 ├── vo // 返回给前端的对象 ├── config // 配置类如RedisConfig、WebMvcConfig ├── common // 统一返回包装、异常处理、工具类 └── NovelApplication.javaController层只做参数接收和调用service的转发不写SQL、不写业务判断这是Spring Boot项目的基本约定。有人图省事把逻辑全写在Controller里后面改一个需求要动三层代码那是给自己挖坑。3. 用户与书籍模块实现JWT登录鉴权和书籍列表接口3.1 用BCrypt JWT做登录鉴权为什么不用MD5和Session登录鉴权是平台的第一个坎。早期教程喜欢用MD5加盐再存数据库但MD5已经被GPU加速撞库撞穿现在做项目起步就该用BCrypt。Spring Security里自带BCryptPasswordEncoder但只为用个加密算法引入整个Security太重我一般单独引spring-security-crypto依赖。注册和登录的Service实现Service RequiredArgsConstructor public class UserServiceImpl implements UserService { private final UserMapper userMapper; private final BCryptPasswordEncoder passwordEncoder new BCryptPasswordEncoder(); Override public void register(RegisterDTO dto) { // 检查用户名是否已存在 Long count userMapper.selectCount( new LambdaQueryWrapperUser() .eq(User::getUsername, dto.getUsername())); if (count 0) { throw new BusinessException(用户名已存在); } User user new User(); user.setUsername(dto.getUsername()); user.setPassword(passwordEncoder.encode(dto.getPassword())); user.setNickname(dto.getNickname()); userMapper.insert(user); } Override public String login(LoginDTO dto) { User user userMapper.selectOne( new LambdaQueryWrapperUser() .eq(User::getUsername, dto.getUsername())); if (user null || !passwordEncoder.matches(dto.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } // 生成JWT有效期7天单位为毫秒 return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, JWT_SECRET) .compact(); } }注意到两个设计决策密码入库前必须encode比对时用matches而不是解码后equals——BCrypt每次生成的盐都不同直接equals永远比对失败这是新手最常踩的坑。JWT里只放userId和username不塞密码、不塞手机号等敏感信息即使token被截获泄露面也有限。登录信息放在JWT里服务端就变成“无状态”好处是水平扩展时不需要共享Session坏处是token无法主动失效。对小说平台这种低敏感场景7天有效期足够了。3.2 登录拦截器与ThreadLocal传递用户信息有了token还需要一个拦截器把所有需要登录的接口保护起来。这里有一个常用且容易踩坑的做法用ThreadLocal保存当前登录用户避免在每个Controller方法里都从token解析userId。Component public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); try { Claims claims Jwts.parser() .setSigningKey(JwtUtil.SECRET) .parseClaimsJws(token) .getBody(); Long userId Long.valueOf(claims.getSubject()); UserContext.set(userId); // ThreadLocal保存 return true; } catch (Exception e) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); return false; } } response.setStatus(HttpStatus.UNAUTHORIZED.value()); return false; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { UserContext.clear(); // 防止线程池复用导致数据错乱 } }关键在于afterCompletion里的UserContext.clear()。Tomcat的工作线程是复用的ThreadLocal不清理下一次请求进来会读到上一个用户的ID——这就是那种“偶发出现别人数据”的玄学Bug的来源而且极难排查。WebMvcConfig里注册拦截器Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/register, /api/book/**); } }注意放行的路径设计书籍列表和章节阅读是可以匿名访问的但书架、阅读进度、收藏接口必须登录。excludePathPatterns里把/api/book/**放行了意味着书籍详情不需要登录也能看——这是产品需求决定的别一棍子全拦住。3.3 书籍列表分页查询MyBatis-Plus分页插件与条件构造器书籍列表的接口核心是分页和条件筛选。MyBatis-Plus的分页插件需要单独配置一个Bean才会生效不然Page对象返回的数据是全量分页参数无效——这是一个很容易被忽略的配置项。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }Service层的分页查询Override public IPageBookVO listBooks(BookQueryDTO dto) { PageBook page new Page(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapperBook wrapper new LambdaQueryWrapper(); // 分类筛选 if (dto.getCategoryId() ! null) { wrapper.eq(Book::getCategoryId, dto.getCategoryId()); } // 按书名模糊搜索用like而非eq if (StringUtils.hasText(dto.getKeyword())) { wrapper.like(Book::getBookName, dto.getKeyword()); } // 按更新时间排序注意orderByDesc wrapper.orderByDesc(Book::getCreateTime); IPageBook result bookMapper.selectPage(page, wrapper); // 转换为VO隐藏不必要的字段 return result.convert(book - { BookVO vo new BookVO(); BeanUtils.copyProperties(book, vo); return vo; }); }这里有一个性能细节selectPage默认会先执行一条count查询再执行数据查询当单表数据量特别大时count本身会成为瓶颈。MyBatis-Plus提供了Page的setOptimizeCountSql选项做优化但数据量没到百万级默认配置足够用。4. 章节阅读与性能优化Redis缓存和异步计数4.1 章节内容接口设计为什么章节内容不能直接查数据库章节内容是访问频率最高、对响应时间最敏感的数据。一个在线小说阅读平台用户每翻一章就是一次全文请求几千字的文本每次从MySQL全文读出数据库压力会随并发直线上升。我第一次做类似项目时直接让用户请求打MySQL上线当天数据库连接数就飙满。后来学乖了章节内容属于“读多写极少”的数据完美契合Redis缓存策略。Service RequiredArgsConstructor public class ChapterServiceImpl implements ChapterService { private final ChapterMapper chapterMapper; private final RedisTemplateString, String redisTemplate; private static final String CHAPTER_CACHE_PREFIX novel:chapter:; Override public ChapterVO getChapter(Long bookId, Integer chapterNo) { String cacheKey CHAPTER_CACHE_PREFIX bookId : chapterNo; // 1. 先查缓存 String cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return JSON.parseObject(cached, ChapterVO.class); } // 2. 缓存未命中查数据库 Chapter chapter chapterMapper.selectOne( new LambdaQueryWrapperChapter() .eq(Chapter::getBookId, bookId) .eq(Chapter::getChapterNo, chapterNo)); if (chapter null) { throw new BusinessException(章节不存在); } ChapterVO vo new ChapterVO(); BeanUtils.copyProperties(chapter, vo); // 3. 写入缓存设置过期时间 redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(vo), 2, TimeUnit.HOURS); return vo; } }这段代码的缓存模式是经典的Cache Aside。步骤是先读缓存命中直接返回未命中则查库再写缓存设置过期时间。需要注意两点key里同时带bookId和chapterNo避免不同书的章节串数据缓存value用JSON字符串而不是Java对象序列化这样Redis的key肉眼可见排查问题时能直接看内容。4.2 缓存穿透与缓存雪崩空值缓存和过期时间抖动缓存不是加了就万事大吉。“缓存穿透”就是最常见的坑请求查一个不存在的章节号缓存永远没有每次请求都会打到数据库。攻击者如果循环请求chapterNo999999数据库会被无效查询打爆。解决办法是空值缓存——查不到也往Redis写一个空标记过期时间设短一些if (chapter null) { // 空值缓存防止穿透 redisTemplate.opsForValue().set(cacheKey, , 5, TimeUnit.MINUTES); throw new BusinessException(章节不存在); }另一个是缓存雪崩。如果所有章节缓存的过期时间都设置成2小时那么同一时刻过期的key数量巨大瞬间所有请求涌向数据库。解决办法是给过期时间加一个随机抖动// 过期时间设为 2小时 随机0-30分钟避免批量失效 long expire 2 * 3600 ThreadLocalRandom.current().nextInt(1800); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(vo), expire, TimeUnit.SECONDS);这个随机抖动的写法在Redis集群和单机环境下都适用属于应对雪崩的常规操作。4.3 阅读进度更新用Redis做临时存储再异步落库在线小说阅读平台的另一个核心数据是阅读进度。这个数据的特征和章节内容相反写频繁且允许延迟落库。用户每翻一章就要更新user_book_shelf.last_chapter_no如果同步update MySQL刷书快的人一秒触发好几次写操作数据库压力不小。我采用的做法进度先写Redis定时任务批量刷回MySQL。private static final String PROGRESS_KEY_PREFIX novel:progress:; Override public void updateProgress(Long userId, Long bookId, Integer chapterNo) { String key PROGRESS_KEY_PREFIX userId : bookId; redisTemplate.opsForValue().set(key, String.valueOf(chapterNo), 1, TimeUnit.DAYS); }定时任务使用Spring自带的Scheduled不需要引入额外的调度框架Scheduled(fixedDelay 60 * 1000) // 每分钟执行一次 public void syncProgressToDb() { // 从Redis中获取所有进度key SetString keys redisTemplate.keys(PROGRESS_KEY_PREFIX *); for (String key : keys) { // 解析userId和bookId // 取lastChapterNo值 // 执行upsert到user_book_shelf表 } }定时任务代码里有一个需要注意的地方redisTemplate.keys()在生产环境慎用因为KEYS *在全量key较多时会导致Redis阻塞。当前进度key数量可控可以用但数据量大了之后建议换成Scan命令或者按用户维度维护一个增量列表。同步落库时推荐使用INSERT ... ON DUPLICATE KEY UPDATE配合建表时的UNIQUE KEY uk_user_book (user_id, book_id)天然实现“有则更新、无则插入”的upsert语义避免先查再改的竞态问题INSERT INTO user_book_shelf (user_id, book_id, last_chapter_no, update_time) VALUES (#{userId}, #{bookId}, #{chapterNo}, NOW()) ON DUPLICATE KEY UPDATE last_chapter_no VALUES(last_chapter_no), update_time NOW()4.4 书籍字数和点击量的更新策略书籍列表页需要展示“字数”和“热度”这两个指标也是高频读、低频高频混合写的场景。比较常见的做法是把word_count的更新做成异步计算——章节发布或修改时重新统计该书的章节总字数然后update一次而不是在每次查列表时去SUM所有章节字数。public void refreshBookWordCount(Long bookId) { // 用SQL聚合查询该书所有章节字数 Long total chapterMapper.sumWordCountByBookId(bookId); Book book new Book(); book.setId(bookId); book.setWordCount(total); bookMapper.updateById(book); }这一步可以用MQ实现异步也可以简单地在Scheduled定时任务里批量处理“状态为正在更新的书”。对单体项目来说同步刷也无妨因为章节发布的频率本身很低不是性能瓶颈。5. 在线小说阅读平台的常见坑与排查从JWT失效到数据错乱的五个血泪经验5.1 JWT突然失效排查结果是服务器时间不准现象本地测试token正常部署到线上后用户反馈“登录状态一会儿就掉了”。原因JWT的签发时间setIssuedAt和过期时间setExpiration都依赖服务器系统时钟。线上服务器时区或时间漂移导致签发出来的token时间戳比实际时间快/慢了几分钟服务端解析时直接判定token过期。这个坑在我第一次部署时折腾了一下午才发现属于“黑匣子”级别的低级错误人容易被业务代码带走。解决检查线上服务器时钟是否同步date -R看时区配置NTP同步JWT的过期时间宽容度加大或使用setNotBefore规避时钟偏移。最省事的方法是统一使用Redis记录签发时间但多数场景校准服务器时钟就够了。5.2 ThreadLocal用户ID串号数据偶发错乱现象用户A的请求偶发返回用户B的书架数据且没有规律。原因拦截器里ThreadLocal存储了userId但请求结束时没有清理。Tomcat线程池复用线程下一次请求拿到上一次遗留的userId。这是线上最容易出诡异Bug的原因之一。解决afterCompletion里必须调用ThreadLocal.remove()而不是set(null)。另外如果用了异步线程池处理业务ThreadLocal不会自动传递需要显式传参或使用TransmittableThreadLocal。5.3 Spring Boot版本太高引入的老依赖全报错现象用Spring Boot 3.0新建项目后引入网上教程里的MyBatis-Plus、jwt依赖编译直接报错找不到javax.servlet相关类。原因Spring Boot 3.x做了大版本升级把Java EE API迁移到了jakarta.*命名空间所有按javax.*写的旧依赖在编译期就过不去。很多博客教程还停留在2.x时代按Spring Boot 3.x跑必然翻车。解决有两条路。一是改用Spring Boot 2.7.xJDK 8可跑二是换用适配3.x的依赖版本比如MyBatis-Plus用3.5.3.1以上版本同时把所有import javax.servlet改为import jakarta.servlet。如果是练手项目我更推荐直接上2.7.18省时间去处理业务逻辑比折腾框架版本有意义。5.4 分页接口返回全量数据MyBatis-Plus分页失效现象Page参数传了pageNum1pageSize10但返回的总记录数和列表都是全量的SQL日志里看不到LIMIT关键字。原因没有注册PaginationInnerInterceptor。这是MyBatis-Plus最容易踩的坑它的分页是依赖拦截器在SQL执行前拼接LIMIT语句实现的漏掉配置类等于分页形同虚设。解决在配置类里显式声明MybatisPlusInterceptor并添加PaginationInnerInterceptor(DbType.MYSQL)。注意DbType要和数据库类型一致否则SQL方言拼接可能出错。5.5 导入章节内容时出现中文乱码和重复数据现象用脚本往book_chapter批量导入章节发现中文全是“???”或者重复导入了两遍。原因两个独立问题。乱码是数据库连接串没指定characterEncodingutf8或表的字符集不是utf8mb4重复数据是导入脚本用自增ID判断“是否已存在”但章节号chapter_no没有唯一键保护。解决JDBC连接串加characterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai表建好后用ALTER TABLE book_chapter ADD UNIQUE KEY uk_book_chapter (book_id, chapter_no)并在导入脚本里用INSERT IGNORE或ON DUPLICATE KEY UPDATE做幂等写入。这属于做数据导入时必查的第一批排查点。6. 进阶玩法接口单元测试、构造数据与部署验证到这里平台能跑通了但这只是第一步。真正决定一个项目可交付性的是能不能持续修改、不会改一处坏一片。我在项目后期一般会补上核心接口的单元测试和一组快速验证脚本。先看点简单的用MockMvc测试登录接口。SpringBootTest AutoConfigureMockMvc class AuthControllerTest { Autowired private MockMvc mockMvc; Test void testLogin() throws Exception { String json {\username\:\test1\,\password\:\123456\}; mockMvc.perform(post(/api/auth/login) .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isOk()) .andExpect(jsonPath($.data).isNotEmpty()); } }单测的意义在于保证重构安全性。后期我把分页查询从selectList改成selectPage后就是靠这几个测试快速确认老接口没被改坏。另一个容易忽略的验证是部署层面。Spring Boot项目打包后检查jar包内是否包含静态资源。前面提到的vue打包放进springboot中常见做法是把Vue构建后的dist目录拷进src/main/resources/static再打包。有个坑是如果项目里配置了接口前缀/api前端路由需要走history模式还要在转发规则里排除掉/api否则刷新页面会404。部署上线前最后一步建议确认三个细节是否关闭了Spring Boot的默认Banner日志会干净很多、是否给Redis设置了密码、是否把MyBatis-Plus的SQL日志只开到开发环境。这三个都是小事但都关系到线上可观察性。我一般把Banner关掉用spring.main.banner-modeoffRedis密码写到配置中心或环境变量而不是硬编码在application.yml里——安全意识应该从练手项目就开始养成。回顾这个在线小说阅读平台核心思路就一句话实体设计定边界JWT管鉴权Redis挡流量异步做解耦单测保回归。这套模式不限于小说换成新闻、博客、漫画平台表结构和接口换个名字就能复用。希望这篇笔记里关于版本选型、拦截器清理、缓存穿透的“踩坑”经验能帮你省下几个调试的夜晚。本文还有配套的精品资源点击获取