尧图网页设计 
简介这是一套面向高校计算机专业毕业设计的在线图书阅读与图书管理一体化系统源码采用SpringBoot后端与Vue前端分离架构适合正在准备毕设、需要完整可运行项目参考的本科及专科学生。资源包共1777个文件涵盖274个Java后端源码、314个Vue页面组件、379个JavaScript脚本以及properties配置、xml映射、scss样式与svg图标等压缩包约23.01MB结构完整、模块划分清晰。系统集图书阅读、图书管理与创作社区于一体配套数据库脚本与安装部署文档按说明导入sq_book.sql、配置Redis与数据源后即可本地启动前端单独运行sq-ui工程。目前已有150人学习下载。读者可获得一套可直接二次开发的毕设方案涵盖权限管理、图书借阅、在线阅读与社区互动等典型业务并附有部署排错思路与目录组织参考便于快速理解前后端协作流程与项目落地细节。1. 从一份毕业设计标题里拆出可交付的三套系统「毕业设计基于SpringBootVue 在线图书阅读系统源代码数据库安装部署文档、图书管理系统图书创作集社区一体系统」——这个标题信息密度很高但真正落到答辩和验收时评委只关心三件事能不能跑起来、数据从哪来、功能边界在哪。我见过太多同学把「在线图书阅读系统」和「图书管理系统」混成一个东西结果数据库表设计到一半发现借阅记录和阅读进度根本不是一个维度返工重来。这个标题实际上包含三个可独立交付的子系统面向读者的在线阅读端书架、章节阅读、进度记忆、面向管理员的图书管理端编目、上下架、借阅归还、以及图书创作集社区用户发帖、书评、创作连载。三者共用一套用户体系和图书元数据但业务表要分开设计。适合正在做毕设的计算机专业学生也适合想拿一套完整前后端分离项目练手的初级开发者。下面按「先跑通再优化」的顺序把选型、建表、接口、部署和踩坑一次讲清楚。2. 技术选型与工程结构为什么是 SpringBoot Vue 而不是别的2.1 后端选 SpringBoot 的三个现实理由毕业设计最怕的是「环境配三天代码写两行」。SpringBoot 的核心价值在于起步依赖和自动配置——你不需要手动配 Tomcat、不需要写一堆 XML一个spring-boot-starter-web就把内嵌容器和 MVC 全套带进来。对于图书阅读系统这种典型的 CRUD 密集型项目SpringBoot 的生态成熟度意味着你遇到问题时能搜到的解决方案最多。版本选择上有个血泪经验不要盲目追最新版。热搜里「springboot版本太高」是真实痛点——SpringBoot 3.x 要求 JDK 17 起步而很多学校机房还停留在 JDK 8。如果指导老师环境老旧老老实实用 SpringBoot 2.7.x JDK 8省去一堆兼容性折腾。JDK 17 当然更好但毕设阶段稳定优先。依赖清单我一般会锁定这几项!-- pom.xml 核心依赖版本按需调整 -- dependencies !-- Web 层REST 接口 内嵌 Tomcat -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 持久层MyBatis-Plus 比原生 MyBatis 少写大量 XML -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- 数据库驱动MySQL 8 用 com.mysql.cj.jdbc.Driver -- dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency !-- JWT无状态登录前后端分离必备 -- dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency /dependencies选 MyBatis-Plus 而不是 JPA 的原因很直接图书管理系统的查询条件多变按分类、按作者、按上架时间、按借阅状态组合筛选MyBatis-Plus 的QueryWrapper拼条件比 JPA 的 Criteria API 直观得多而且分页插件开箱即用。JWT 做登录态是因为前后端分离后 Session 跨域很麻烦Token 放在请求头里最省事。2.2 前端选 Vue 3 还是 Vue 2热搜里「vue安装及环境配置」「vue入门」「vue面试题」高频出现说明很多人卡在起步。结论新项目直接上 Vue 3 Vite别用 Vue 2 Webpack。Vite 的冷启动速度比 Webpack 快一个数量级改代码热更新几乎无感。Vue 3 的 Composition API 在阅读器这种需要管理多个响应式状态当前章节、滚动位置、字体大小、夜间模式的场景下比 Options API 的this分散管理清晰得多。工程结构建议按功能模块划分而不是按文件类型堆在一起src/ ├── api/ # 接口封装每个模块一个文件 │ ├── book.js # 图书相关接口 │ ├── user.js # 用户认证接口 │ └── community.js ├── views/ # 页面级组件 │ ├── reader/ # 阅读器相关页面 │ ├── admin/ # 管理端页面 │ └── community/ ├── components/ # 可复用组件分页器、富文本编辑器等 ├── router/ # 路由配置注意动态路由权限控制 ├── store/ # Pinia 状态管理 └── utils/ # 请求拦截器、工具函数路由这块有个坑要提前说管理端和读者端的路由权限必须分开控制。常见做法是用路由元信息meta.role标记在全局前置守卫里判断当前用户角色不匹配就重定向。热搜里「vue动态路由」说的就是这个场景——但动态路由的坑在于刷新页面后路由丢失需要在守卫里做一次持久化恢复。2.3 前后端联调时的跨域与打包开发阶段前端跑在localhost:5173后端跑在localhost:8080跨域是必然的。两种解法后端加CrossOrigin注解或者前端 Vite 配代理。我一般用后者因为生产环境打包后前端静态文件直接放进 SpringBoot 的static目录同源就不存在跨域了。// vite.config.js 开发代理配置 export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, // 后端地址 changeOrigin: true, // 允许跨域 rewrite: (path) path.replace(/^\/api/, ) // 去掉前缀 } } } })changeOrigin: true的作用是让代理请求的 Host 头变成目标地址某些后端框架会校验这个。rewrite去掉/api前缀是因为后端接口路径通常不带这个前缀前端加它是为了区分静态资源和接口请求。生产打包时执行npm run build把dist目录内容拷到src/main/resources/static下SpringBoot 会自动作为静态资源提供。3. 数据库设计三套系统共用的表怎么拆3.1 核心表结构与字段说明图书阅读系统最容易设计错的地方是把「图书」和「章节」混在一张表。一本书有多个章节章节内容可能很大几万字如果和图书元数据放一起每次查图书列表都会拖出大字段性能直接崩。正确做法是拆成book元数据和book_chapter章节内容两张表。-- 图书元数据表只存轻量信息列表查询走这张 CREATE TABLE book ( id BIGINT NOT NULL AUTO_INCREMENT, title VARCHAR(200) NOT NULL COMMENT 书名, author VARCHAR(100) DEFAULT NULL, cover_url VARCHAR(500) DEFAULT NULL COMMENT 封面图地址, category_id INT DEFAULT NULL COMMENT 分类ID, intro VARCHAR(1000) DEFAULT NULL COMMENT 简介, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 章节内容表大字段单独存按 book_id 序号查 CREATE TABLE book_chapter ( id BIGINT NOT NULL AUTO_INCREMENT, book_id BIGINT NOT NULL, chapter_no INT NOT NULL COMMENT 章节序号, title VARCHAR(200) DEFAULT NULL, content LONGTEXT COMMENT 正文可能几万字, PRIMARY KEY (id), UNIQUE KEY uk_book_chapter (book_id, chapter_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;utf8mb4而不是utf8是因为要支持 emoji 和生僻字社区发帖场景一定会遇到。uk_book_chapter唯一索引防止同一本书出现重复章节号。content用LONGTEXT是因为单章可能超过 64KBTEXT类型不够用。阅读进度表是另一个关键设计-- 阅读进度记录用户读到哪本书的哪一章 CREATE TABLE reading_progress ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, book_id BIGINT NOT NULL, chapter_no INT DEFAULT 1, scroll_percent DECIMAL(5,2) 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;uk_user_book保证一个用户对一本书只有一条进度记录用INSERT ... ON DUPLICATE KEY UPDATE实现「有则更新无则插入」。scroll_percent记录章节内滚动位置这样用户下次打开能精确回到上次读到的位置而不是只回到章节开头。3.2 社区模块的表怎么和图书关联图书创作集社区的核心是「帖子」和「书评」。书评必须关联到具体图书帖子可以独立存在也可以关联图书。设计上用一张post表加一个可空的book_id字段来兼容两种场景CREATE TABLE post ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, book_id BIGINT DEFAULT NULL COMMENT 关联图书可为空, type TINYINT DEFAULT 1 COMMENT 1普通帖子 2书评 3创作连载, title VARCHAR(200) DEFAULT NULL, content TEXT, like_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_book (book_id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;like_count做成冗余字段而不是每次COUNT(*)查点赞表是因为帖子列表页要显示点赞数实时统计在数据量大时很慢。代价是点赞时要同时更新点赞表和这个计数字段需要用事务包住。这是典型的读多写少场景下的空间换时间。3.3 索引与查询优化图书列表页最常见的查询是「按分类筛选 按上架状态过滤 分页排序」。如果只建了idx_category当分类下数据量大时MySQL 可能选择全表扫描。复合索引的顺序很关键-- 复合索引等值条件在前范围/排序在后 ALTER TABLE book ADD INDEX idx_status_category (status, category_id);status放前面是因为它的区分度虽然不高但查询中几乎总是等值条件status 1而category_id可能作为IN查询。实际执行时用EXPLAIN看type列目标是ref或range出现ALL就说明索引没生效。热搜里「springboot项目结构」很多人问但结构清晰只是第一步SQL 写不对照样慢。4. 核心功能实现阅读器、借阅、社区发帖4.1 阅读器的章节加载与进度记忆阅读器是用户体验的核心。前端请求章节内容时后端接口设计成GET /api/book/{bookId}/chapter/{chapterNo}返回章节正文和上下章是否存在。前端拿到内容后渲染同时监听滚动事件计算百分比节流后上报进度。// 阅读进度上报节流 3 秒一次避免频繁写库 import { throttle } from lodash-es const reportProgress throttle(async (bookId, chapterNo, percent) { await api.post(/reading/progress, { bookId, chapterNo, scrollPercent: percent // 0-100 的数值 }) }, 3000) // 滚动监听计算当前滚动位置占全文的百分比 function onScroll() { const el document.documentElement const total el.scrollHeight - el.clientHeight const percent total 0 ? (el.scrollTop / total) * 100 : 0 reportProgress(currentBookId.value, currentChapter.value, percent.toFixed(2)) }节流 3 秒是权衡太频繁写库压力大太稀疏用户切换设备时进度丢失。scrollPercent保留两位小数精度够用又不会让字段过长。后端收到后用INSERT ... ON DUPLICATE KEY UPDATE写入一条 SQL 搞定插入和更新。章节切换时有个细节如果用户从第 3 章跳到第 10 章进度里的chapter_no要更新但scroll_percent要重置为 0否则会跳到第 10 章的中间位置体验很怪。这个逻辑放在后端做前端只传当前章节和百分比。4.2 借阅归还的状态机与并发控制图书管理系统的借阅功能本质是一个状态机可借 → 已借出 → 已归还。核心问题是并发——同一本书被两个人同时点「借阅」怎么办。常见做法是用数据库行锁-- 借阅先查库存再扣减用 FOR UPDATE 锁行 START TRANSACTION; SELECT stock FROM book WHERE id #{bookId} FOR UPDATE; -- 应用层判断 stock 0 后执行 UPDATE book SET stock stock - 1 WHERE id #{bookId}; INSERT INTO borrow_record (user_id, book_id, borrow_time, status) VALUES (#{userId}, #{bookId}, NOW(), 1); COMMIT;FOR UPDATE锁住这本书的行第二个请求会阻塞直到第一个事务提交。如果库存为 0应用层抛异常回滚。这个方案在单机 MySQL 下没问题但如果部署了多个后端实例数据库行锁依然有效因为锁是在数据库层面的。热搜里「springboot整合activemq」提到的消息队列方案在这里属于过度设计毕设阶段没必要。归还时要注意更新借阅记录状态为已归还同时stock 1两个操作必须在同一事务里。如果只更新了记录没加库存这本书就永远借不出去了这种 bug 在答辩演示时一旦触发非常尴尬。4.3 社区发帖与敏感词过滤社区模块的接口设计遵循 RESTfulPOST /api/post发帖GET /api/post/list分页查询POST /api/post/{id}/like点赞。发帖时要做基本的敏感词过滤毕设不需要接入第三方服务本地维护一个词库用 DFA 算法过滤即可。// 简易敏感词过滤DFA 前缀树启动时加载词库 Component public class SensitiveWordFilter { private final MapCharacter, Object tree new HashMap(); PostConstruct public void init() { // 从 resources/sensitive-words.txt 逐行读取构建前缀树 ListString words loadWordsFromFile(); for (String word : words) { MapCharacter, Object node tree; for (char c : word.toCharArray()) { node (MapCharacter, Object) node.computeIfAbsent(c, k - new HashMap()); } node.put(\0, null); // 结束标记 } } public boolean containsSensitive(String text) { for (int i 0; i text.length(); i) { MapCharacter, Object node tree; for (int j i; j text.length(); j) { char c text.charAt(j); node (MapCharacter, Object) node.get(c); if (node null) break; if (node.containsKey(\0)) return true; } } return false; } }DFA 的时间复杂度是 O(n)n 是文本长度比逐个词contains快得多。\0作为结束标记是因为正常文本不会包含空字符。词库文件放resources下启动时加载一次常驻内存。这个实现够毕设用生产环境还需要考虑变体字、拼音、拆字等绕过手段但那是另一个话题了。点赞功能用 Redis 做计数器会更优雅但毕设阶段直接更新 MySQL 的like_count字段也能跑。如果要用 Redis注意点赞和取消点赞的幂等性——同一个用户重复点赞不应该重复加一需要用一个user_like表记录谁赞过谁。5. 避坑与排查部署和联调时最容易翻车的五个点5.1 现象前端打包后刷新页面 404原因Vue Router 默认用 history 模式URL 里没有#但 Nginx 或 SpringBoot 静态资源处理不认识这些前端路由刷新时直接找后端要/reader/123这个路径后端没有对应接口就 404。解决两种方案。一是改用 hash 模式URL 带#缺点是丑但省事。二是保持 history 模式在 Nginx 加try_files $uri $uri/ /index.html;或者在 SpringBoot 里加一个转发配置把所有非/api开头的请求转发到index.html。我一般用后者因为毕设部署环境不一定有 Nginx。5.2 现象数据库连接池启动报Communications link failure原因MySQL 8 的驱动类名和 URL 参数跟 5.x 不一样。用了com.mysql.jdbc.Driver会警告URL 没加serverTimezone会报时区错误。解决驱动写com.mysql.cj.jdbc.DriverURL 加?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8mb4useSSLfalse。useSSLfalse在开发环境关掉 SSL 避免证书问题生产环境建议开启。5.3 现象JWT Token 过期后前端所有请求 401用户被踢回登录页原因Token 设置了固定过期时间比如 2 小时到期后前端没有刷新机制直接跳登录。解决双 Token 方案——accessToken 短期30 分钟refreshToken 长期7 天。accessToken 过期时用 refreshToken 换新的refreshToken 也过期才跳登录。实现上在 axios 响应拦截器里判断 401自动调刷新接口重试原请求。注意刷新接口本身要排除在拦截逻辑外否则会死循环。5.4 现象章节内容里的换行和空格在页面上丢失原因前端用{{ content }}插值渲染HTML 会把连续空格和换行符合并成一个空格。解决用white-space: pre-wrap的 CSS 样式保留换行和空格或者把内容按换行符拆成数组用p标签渲染。前者简单后者更可控。如果章节内容来自富文本编辑器直接v-html渲染但要注意 XSS 风险后端存之前要过滤script标签。5.5 现象本地跑得好好的部署到服务器后图片上传失败原因本地图片存的是绝对路径D:/uploads/服务器上没有这个目录。或者上传目录没有写权限。解决上传路径配成可配置项在application.yml里写file.upload-path: /data/uploads/代码里用Value注入。服务器上提前mkdir -p并chmod 755。返回给前端的 URL 用相对路径/uploads/xxx.jpg通过 SpringBoot 的静态资源映射暴露出去不要写死服务器 IP。6. 从能跑到好用三个让答辩加分的技术细节6.1 用 Redis 缓存热门图书列表图书首页的「热门推荐」如果每次都查数据库在演示时数据量小看不出问题但答辩老师问「并发怎么办」就答不上来。加一层 Redis 缓存把首页图书列表缓存 5 分钟接口响应能从几十毫秒降到几毫秒。// 缓存逻辑先查 Redis没有再查库并回写 public ListBookVO getHotBooks() { String key hot:books; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseArray(cached, BookVO.class); } ListBookVO books bookMapper.selectHotBooks(10); redisTemplate.opsForValue().set(key, JSON.toJSONString(books), 5, TimeUnit.MINUTES); return books; }缓存时间设 5 分钟是平衡太短起不到缓存效果太长数据更新不及时。图书上架下架时主动删掉这个 key保证下次请求重新加载。这个「缓存 主动失效」的模式在面试里也是高频考点。6.2 阅读器夜间模式的实现夜间模式不是简单换个背景色要处理图片亮度、代码块配色、字体对比度。用 CSS 变量统一管理:root { --bg-color: #ffffff; --text-color: #333333; --chapter-title: #1a1a1a; } [data-themedark] { --bg-color: #1a1a1a; --text-color: #b0b0b0; --chapter-title: #e0e0e0; } .reader-content { background: var(--bg-color); color: var(--text-color); transition: background 0.3s, color 0.3s; }切换时只改document.documentElement的style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" /> SpringBoot+Vue在线图书阅读系统毕业设计：三套子系统源码、数据库与部署文档
简介这是一套面向高校计算机专业毕业设计的在线图书阅读与图书管理一体化系统源码采用SpringBoot后端与Vue前端分离架构适合正在准备毕设、需要完整可运行项目参考的本科及专科学生。资源包共1777个文件涵盖274个Java后端源码、314个Vue页面组件、379个JavaScript脚本以及properties配置、xml映射、scss样式与svg图标等压缩包约23.01MB结构完整、模块划分清晰。系统集图书阅读、图书管理与创作社区于一体配套数据库脚本与安装部署文档按说明导入sq_book.sql、配置Redis与数据源后即可本地启动前端单独运行sq-ui工程。目前已有150人学习下载。读者可获得一套可直接二次开发的毕设方案涵盖权限管理、图书借阅、在线阅读与社区互动等典型业务并附有部署排错思路与目录组织参考便于快速理解前后端协作流程与项目落地细节。1. 从一份毕业设计标题里拆出可交付的三套系统「毕业设计基于SpringBootVue 在线图书阅读系统源代码数据库安装部署文档、图书管理系统图书创作集社区一体系统」——这个标题信息密度很高但真正落到答辩和验收时评委只关心三件事能不能跑起来、数据从哪来、功能边界在哪。我见过太多同学把「在线图书阅读系统」和「图书管理系统」混成一个东西结果数据库表设计到一半发现借阅记录和阅读进度根本不是一个维度返工重来。这个标题实际上包含三个可独立交付的子系统面向读者的在线阅读端书架、章节阅读、进度记忆、面向管理员的图书管理端编目、上下架、借阅归还、以及图书创作集社区用户发帖、书评、创作连载。三者共用一套用户体系和图书元数据但业务表要分开设计。适合正在做毕设的计算机专业学生也适合想拿一套完整前后端分离项目练手的初级开发者。下面按「先跑通再优化」的顺序把选型、建表、接口、部署和踩坑一次讲清楚。2. 技术选型与工程结构为什么是 SpringBoot Vue 而不是别的2.1 后端选 SpringBoot 的三个现实理由毕业设计最怕的是「环境配三天代码写两行」。SpringBoot 的核心价值在于起步依赖和自动配置——你不需要手动配 Tomcat、不需要写一堆 XML一个spring-boot-starter-web就把内嵌容器和 MVC 全套带进来。对于图书阅读系统这种典型的 CRUD 密集型项目SpringBoot 的生态成熟度意味着你遇到问题时能搜到的解决方案最多。版本选择上有个血泪经验不要盲目追最新版。热搜里「springboot版本太高」是真实痛点——SpringBoot 3.x 要求 JDK 17 起步而很多学校机房还停留在 JDK 8。如果指导老师环境老旧老老实实用 SpringBoot 2.7.x JDK 8省去一堆兼容性折腾。JDK 17 当然更好但毕设阶段稳定优先。依赖清单我一般会锁定这几项!-- pom.xml 核心依赖版本按需调整 -- dependencies !-- Web 层REST 接口 内嵌 Tomcat -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 持久层MyBatis-Plus 比原生 MyBatis 少写大量 XML -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- 数据库驱动MySQL 8 用 com.mysql.cj.jdbc.Driver -- dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency !-- JWT无状态登录前后端分离必备 -- dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency /dependencies选 MyBatis-Plus 而不是 JPA 的原因很直接图书管理系统的查询条件多变按分类、按作者、按上架时间、按借阅状态组合筛选MyBatis-Plus 的QueryWrapper拼条件比 JPA 的 Criteria API 直观得多而且分页插件开箱即用。JWT 做登录态是因为前后端分离后 Session 跨域很麻烦Token 放在请求头里最省事。2.2 前端选 Vue 3 还是 Vue 2热搜里「vue安装及环境配置」「vue入门」「vue面试题」高频出现说明很多人卡在起步。结论新项目直接上 Vue 3 Vite别用 Vue 2 Webpack。Vite 的冷启动速度比 Webpack 快一个数量级改代码热更新几乎无感。Vue 3 的 Composition API 在阅读器这种需要管理多个响应式状态当前章节、滚动位置、字体大小、夜间模式的场景下比 Options API 的this分散管理清晰得多。工程结构建议按功能模块划分而不是按文件类型堆在一起src/ ├── api/ # 接口封装每个模块一个文件 │ ├── book.js # 图书相关接口 │ ├── user.js # 用户认证接口 │ └── community.js ├── views/ # 页面级组件 │ ├── reader/ # 阅读器相关页面 │ ├── admin/ # 管理端页面 │ └── community/ ├── components/ # 可复用组件分页器、富文本编辑器等 ├── router/ # 路由配置注意动态路由权限控制 ├── store/ # Pinia 状态管理 └── utils/ # 请求拦截器、工具函数路由这块有个坑要提前说管理端和读者端的路由权限必须分开控制。常见做法是用路由元信息meta.role标记在全局前置守卫里判断当前用户角色不匹配就重定向。热搜里「vue动态路由」说的就是这个场景——但动态路由的坑在于刷新页面后路由丢失需要在守卫里做一次持久化恢复。2.3 前后端联调时的跨域与打包开发阶段前端跑在localhost:5173后端跑在localhost:8080跨域是必然的。两种解法后端加CrossOrigin注解或者前端 Vite 配代理。我一般用后者因为生产环境打包后前端静态文件直接放进 SpringBoot 的static目录同源就不存在跨域了。// vite.config.js 开发代理配置 export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, // 后端地址 changeOrigin: true, // 允许跨域 rewrite: (path) path.replace(/^\/api/, ) // 去掉前缀 } } } })changeOrigin: true的作用是让代理请求的 Host 头变成目标地址某些后端框架会校验这个。rewrite去掉/api前缀是因为后端接口路径通常不带这个前缀前端加它是为了区分静态资源和接口请求。生产打包时执行npm run build把dist目录内容拷到src/main/resources/static下SpringBoot 会自动作为静态资源提供。3. 数据库设计三套系统共用的表怎么拆3.1 核心表结构与字段说明图书阅读系统最容易设计错的地方是把「图书」和「章节」混在一张表。一本书有多个章节章节内容可能很大几万字如果和图书元数据放一起每次查图书列表都会拖出大字段性能直接崩。正确做法是拆成book元数据和book_chapter章节内容两张表。-- 图书元数据表只存轻量信息列表查询走这张 CREATE TABLE book ( id BIGINT NOT NULL AUTO_INCREMENT, title VARCHAR(200) NOT NULL COMMENT 书名, author VARCHAR(100) DEFAULT NULL, cover_url VARCHAR(500) DEFAULT NULL COMMENT 封面图地址, category_id INT DEFAULT NULL COMMENT 分类ID, intro VARCHAR(1000) DEFAULT NULL COMMENT 简介, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 章节内容表大字段单独存按 book_id 序号查 CREATE TABLE book_chapter ( id BIGINT NOT NULL AUTO_INCREMENT, book_id BIGINT NOT NULL, chapter_no INT NOT NULL COMMENT 章节序号, title VARCHAR(200) DEFAULT NULL, content LONGTEXT COMMENT 正文可能几万字, PRIMARY KEY (id), UNIQUE KEY uk_book_chapter (book_id, chapter_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;utf8mb4而不是utf8是因为要支持 emoji 和生僻字社区发帖场景一定会遇到。uk_book_chapter唯一索引防止同一本书出现重复章节号。content用LONGTEXT是因为单章可能超过 64KBTEXT类型不够用。阅读进度表是另一个关键设计-- 阅读进度记录用户读到哪本书的哪一章 CREATE TABLE reading_progress ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, book_id BIGINT NOT NULL, chapter_no INT DEFAULT 1, scroll_percent DECIMAL(5,2) 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;uk_user_book保证一个用户对一本书只有一条进度记录用INSERT ... ON DUPLICATE KEY UPDATE实现「有则更新无则插入」。scroll_percent记录章节内滚动位置这样用户下次打开能精确回到上次读到的位置而不是只回到章节开头。3.2 社区模块的表怎么和图书关联图书创作集社区的核心是「帖子」和「书评」。书评必须关联到具体图书帖子可以独立存在也可以关联图书。设计上用一张post表加一个可空的book_id字段来兼容两种场景CREATE TABLE post ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, book_id BIGINT DEFAULT NULL COMMENT 关联图书可为空, type TINYINT DEFAULT 1 COMMENT 1普通帖子 2书评 3创作连载, title VARCHAR(200) DEFAULT NULL, content TEXT, like_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_book (book_id), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;like_count做成冗余字段而不是每次COUNT(*)查点赞表是因为帖子列表页要显示点赞数实时统计在数据量大时很慢。代价是点赞时要同时更新点赞表和这个计数字段需要用事务包住。这是典型的读多写少场景下的空间换时间。3.3 索引与查询优化图书列表页最常见的查询是「按分类筛选 按上架状态过滤 分页排序」。如果只建了idx_category当分类下数据量大时MySQL 可能选择全表扫描。复合索引的顺序很关键-- 复合索引等值条件在前范围/排序在后 ALTER TABLE book ADD INDEX idx_status_category (status, category_id);status放前面是因为它的区分度虽然不高但查询中几乎总是等值条件status 1而category_id可能作为IN查询。实际执行时用EXPLAIN看type列目标是ref或range出现ALL就说明索引没生效。热搜里「springboot项目结构」很多人问但结构清晰只是第一步SQL 写不对照样慢。4. 核心功能实现阅读器、借阅、社区发帖4.1 阅读器的章节加载与进度记忆阅读器是用户体验的核心。前端请求章节内容时后端接口设计成GET /api/book/{bookId}/chapter/{chapterNo}返回章节正文和上下章是否存在。前端拿到内容后渲染同时监听滚动事件计算百分比节流后上报进度。// 阅读进度上报节流 3 秒一次避免频繁写库 import { throttle } from lodash-es const reportProgress throttle(async (bookId, chapterNo, percent) { await api.post(/reading/progress, { bookId, chapterNo, scrollPercent: percent // 0-100 的数值 }) }, 3000) // 滚动监听计算当前滚动位置占全文的百分比 function onScroll() { const el document.documentElement const total el.scrollHeight - el.clientHeight const percent total 0 ? (el.scrollTop / total) * 100 : 0 reportProgress(currentBookId.value, currentChapter.value, percent.toFixed(2)) }节流 3 秒是权衡太频繁写库压力大太稀疏用户切换设备时进度丢失。scrollPercent保留两位小数精度够用又不会让字段过长。后端收到后用INSERT ... ON DUPLICATE KEY UPDATE写入一条 SQL 搞定插入和更新。章节切换时有个细节如果用户从第 3 章跳到第 10 章进度里的chapter_no要更新但scroll_percent要重置为 0否则会跳到第 10 章的中间位置体验很怪。这个逻辑放在后端做前端只传当前章节和百分比。4.2 借阅归还的状态机与并发控制图书管理系统的借阅功能本质是一个状态机可借 → 已借出 → 已归还。核心问题是并发——同一本书被两个人同时点「借阅」怎么办。常见做法是用数据库行锁-- 借阅先查库存再扣减用 FOR UPDATE 锁行 START TRANSACTION; SELECT stock FROM book WHERE id #{bookId} FOR UPDATE; -- 应用层判断 stock 0 后执行 UPDATE book SET stock stock - 1 WHERE id #{bookId}; INSERT INTO borrow_record (user_id, book_id, borrow_time, status) VALUES (#{userId}, #{bookId}, NOW(), 1); COMMIT;FOR UPDATE锁住这本书的行第二个请求会阻塞直到第一个事务提交。如果库存为 0应用层抛异常回滚。这个方案在单机 MySQL 下没问题但如果部署了多个后端实例数据库行锁依然有效因为锁是在数据库层面的。热搜里「springboot整合activemq」提到的消息队列方案在这里属于过度设计毕设阶段没必要。归还时要注意更新借阅记录状态为已归还同时stock 1两个操作必须在同一事务里。如果只更新了记录没加库存这本书就永远借不出去了这种 bug 在答辩演示时一旦触发非常尴尬。4.3 社区发帖与敏感词过滤社区模块的接口设计遵循 RESTfulPOST /api/post发帖GET /api/post/list分页查询POST /api/post/{id}/like点赞。发帖时要做基本的敏感词过滤毕设不需要接入第三方服务本地维护一个词库用 DFA 算法过滤即可。// 简易敏感词过滤DFA 前缀树启动时加载词库 Component public class SensitiveWordFilter { private final MapCharacter, Object tree new HashMap(); PostConstruct public void init() { // 从 resources/sensitive-words.txt 逐行读取构建前缀树 ListString words loadWordsFromFile(); for (String word : words) { MapCharacter, Object node tree; for (char c : word.toCharArray()) { node (MapCharacter, Object) node.computeIfAbsent(c, k - new HashMap()); } node.put(\0, null); // 结束标记 } } public boolean containsSensitive(String text) { for (int i 0; i text.length(); i) { MapCharacter, Object node tree; for (int j i; j text.length(); j) { char c text.charAt(j); node (MapCharacter, Object) node.get(c); if (node null) break; if (node.containsKey(\0)) return true; } } return false; } }DFA 的时间复杂度是 O(n)n 是文本长度比逐个词contains快得多。\0作为结束标记是因为正常文本不会包含空字符。词库文件放resources下启动时加载一次常驻内存。这个实现够毕设用生产环境还需要考虑变体字、拼音、拆字等绕过手段但那是另一个话题了。点赞功能用 Redis 做计数器会更优雅但毕设阶段直接更新 MySQL 的like_count字段也能跑。如果要用 Redis注意点赞和取消点赞的幂等性——同一个用户重复点赞不应该重复加一需要用一个user_like表记录谁赞过谁。5. 避坑与排查部署和联调时最容易翻车的五个点5.1 现象前端打包后刷新页面 404原因Vue Router 默认用 history 模式URL 里没有#但 Nginx 或 SpringBoot 静态资源处理不认识这些前端路由刷新时直接找后端要/reader/123这个路径后端没有对应接口就 404。解决两种方案。一是改用 hash 模式URL 带#缺点是丑但省事。二是保持 history 模式在 Nginx 加try_files $uri $uri/ /index.html;或者在 SpringBoot 里加一个转发配置把所有非/api开头的请求转发到index.html。我一般用后者因为毕设部署环境不一定有 Nginx。5.2 现象数据库连接池启动报Communications link failure原因MySQL 8 的驱动类名和 URL 参数跟 5.x 不一样。用了com.mysql.jdbc.Driver会警告URL 没加serverTimezone会报时区错误。解决驱动写com.mysql.cj.jdbc.DriverURL 加?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8mb4useSSLfalse。useSSLfalse在开发环境关掉 SSL 避免证书问题生产环境建议开启。5.3 现象JWT Token 过期后前端所有请求 401用户被踢回登录页原因Token 设置了固定过期时间比如 2 小时到期后前端没有刷新机制直接跳登录。解决双 Token 方案——accessToken 短期30 分钟refreshToken 长期7 天。accessToken 过期时用 refreshToken 换新的refreshToken 也过期才跳登录。实现上在 axios 响应拦截器里判断 401自动调刷新接口重试原请求。注意刷新接口本身要排除在拦截逻辑外否则会死循环。5.4 现象章节内容里的换行和空格在页面上丢失原因前端用{{ content }}插值渲染HTML 会把连续空格和换行符合并成一个空格。解决用white-space: pre-wrap的 CSS 样式保留换行和空格或者把内容按换行符拆成数组用p标签渲染。前者简单后者更可控。如果章节内容来自富文本编辑器直接v-html渲染但要注意 XSS 风险后端存之前要过滤script标签。5.5 现象本地跑得好好的部署到服务器后图片上传失败原因本地图片存的是绝对路径D:/uploads/服务器上没有这个目录。或者上传目录没有写权限。解决上传路径配成可配置项在application.yml里写file.upload-path: /data/uploads/代码里用Value注入。服务器上提前mkdir -p并chmod 755。返回给前端的 URL 用相对路径/uploads/xxx.jpg通过 SpringBoot 的静态资源映射暴露出去不要写死服务器 IP。6. 从能跑到好用三个让答辩加分的技术细节6.1 用 Redis 缓存热门图书列表图书首页的「热门推荐」如果每次都查数据库在演示时数据量小看不出问题但答辩老师问「并发怎么办」就答不上来。加一层 Redis 缓存把首页图书列表缓存 5 分钟接口响应能从几十毫秒降到几毫秒。// 缓存逻辑先查 Redis没有再查库并回写 public ListBookVO getHotBooks() { String key hot:books; String cached redisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseArray(cached, BookVO.class); } ListBookVO books bookMapper.selectHotBooks(10); redisTemplate.opsForValue().set(key, JSON.toJSONString(books), 5, TimeUnit.MINUTES); return books; }缓存时间设 5 分钟是平衡太短起不到缓存效果太长数据更新不及时。图书上架下架时主动删掉这个 key保证下次请求重新加载。这个「缓存 主动失效」的模式在面试里也是高频考点。6.2 阅读器夜间模式的实现夜间模式不是简单换个背景色要处理图片亮度、代码块配色、字体对比度。用 CSS 变量统一管理:root { --bg-color: #ffffff; --text-color: #333333; --chapter-title: #1a1a1a; } [data-themedark] { --bg-color: #1a1a1a; --text-color: #b0b0b0; --chapter-title: #e0e0e0; } .reader-content { background: var(--bg-color); color: var(--text-color); transition: background 0.3s, color 0.3s; }切换时只改document.documentElement的style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />