简介一份基于Springboot的学生读书笔记共享系统设计与实现资料包面向Java课程设计、毕业设计及Springboot初学者。内容涵盖完整源码与配套论文论文按绪论、技术介绍、需求分析、系统设计、系统实现、系统测试等章节展开清晰呈现从需求到实现的完整开发脉络。系统选用Java、MySQL、Tomcat与Springboot框架实现管理员后台、前台首页、用户读书笔记共享等典型功能模块。压缩包共784个文件体积19.18MB以js、vue、java、css、html、png等类型为主其中前端vue与js文件承载页面交互java文件处理后端逻辑sql脚本提供数据库初始化doc/docx为论文文档并附带bat运行脚本便于本地启动。已有32人学习下载适合需要快速搭建同类课设项目、参考论文结构或学习SpringbootVue前后端整合的读者。1. 学生读书笔记共享系统SpringBoot 单体项目为什么仍是毕设与接私活的首选拿到「基于 SpringBoot 学生读书笔记共享设计与实现」这个标题很多人的第一反应是“又一个图书管理系统换皮”。但把「共享」两个字拆开看它比常见的单机图书借阅多了两条核心链路笔记的上传 / 展示 / 检索以及多用户之间的可见性控制。这正是 SpringBoot 单体应用最舒服的射程范围——既不需要微服务那套注册中心、消息队列来撑场面也不会因为业务太简单导致论文没东西可写。我见过太多人一上来就纠结要不要上 Redis、要不要拆前后端分离最后卡在环境搭建上而这个项目用一套 SpringBoot MyBatis Plus Thymeleaf或 Vue 分离就能跑通全部需求源码包里的论文还能直接对应到数据库设计、权限模型和测试章节。这个标题的受众也很明确计算机相关专业做毕业设计的学生、准备 Java 课程设计的初学者以及接外包时碰到“读书笔记共享”这类需求的全栈开发者。它的价值不在于算法多难而在于把 CRUD 做扎实——用户注册登录、笔记的增删改查、按分类 / 关键字搜索、点赞收藏、个人笔记与公共笔记的可见性切换再加上 JWT 或 Session 的权限控制。把这些点理顺系统就能稳定跑起来论文也有真实的数据流和界面截图可写。下面我会按一条可复现的路线拆解先讲清楚设计上的四个关键选型再给出数据库与项目骨架的最小实现接着处理文件上传与全文检索这两个最容易翻车的模块最后把部署和避坑清单一次性讲透。2. 先想清楚四件事共享边界、权限模型、富文本存储、检索方式2.1 共享边界公开、私有与关注可见别把权限设计成布尔值读书笔记共享系统最容易被做“浅”的地方就是给笔记表加一个is_public字段然后查询时where is_public 1。这种做法在演示时没有问题但论文的“需求分析”和“系统设计”章节会显得非常单薄。更合理的设计是三级可见性公开所有人可见、私有仅自己可见、好友/关注可见仅关注者可见。三级权限在数据库里可以用一个tinyint字段visibility表示但在查询层需要分别处理公开笔记直接查私有笔记追加user_id 当前用户关注可见则要通过关注关系表先查出被关注者的 ID 集合再作为in条件拼入查询。常见做法是在 Service 层封装一个NoteQuery对象里面携带当前用户 ID、目标用户 ID、关键字、分类 ID、分页参数然后由 SQL 动态拼接条件。用 MyBatis Plus 时我一般直接用 LambdaQueryWrapper配合and嵌套来处理权限条件。这里有个参数细节查询公开笔记时不要带user_id条件否则会漏掉其他用户的公开内容而查询“我的笔记”时才需要eq(user_id, currentUserId)。把这两个条件分开封装成两个方法比在同一个方法里用 if 判断更清晰也方便论文里写“模块划分”。2.2 权限控制用 Sa-Token 还是 JWT 拦截器SpringBoot 做登录认证绕不开 Session、JWT、Sa-Token 这几个选择。对于这个项目的规模我的建议是直接上 Sa-Token——它比 Shiro 轻比手写 JWT 拦截器省事而且自带的StpUtil.getLoginId()能直接拿到当前登录用户 ID省去从 Token 里解析用户信息的样板代码。源码包里如果是老项目很可能是 Spring Security JWT 的组合但如果你是自己从零写Sa-Token 的学习成本和出 bug 的概率都低得多。使用 Sa-Token 时核心配置就三件事引入依赖、配置拦截器或过滤器、在登录接口调用StpUtil.login(userId)。需要注意的一个坑是Token 生效范围默认是单点登录模式同一账号在多处登录会互相踢下线做读书笔记这类系统用户很可能在手机和电脑同时使用需要在配置里打开is-concurrent: true并设置is-share: false这样每个设备各自持有 Token互不影响。不用 Sa-Token 的话也可以继续用 Shiro但 Shiro 在 SpringBoot 3.x 下的整合比较折腾而 Sa-Token 对 SpringBoot 2.x / 3.x 都跟进得很快这也是我近年更推荐它的原因。2.3 富文本笔记的存储Markdown 源码入库渲染交给前端读书笔记和普通文章的区别在于它既有结构化元数据书名、作者、页码、分类又有非结构化的笔记正文。正文如果是纯文本系统体验会很差如果直接粘贴 Word 里的富文本又容易带进大量垃圾标签和样式。最常见的方案是前端用 Markdown 编辑器如 md-editor-v3 或 wangEditor 的 Markdown 模式后端只保存 Markdown 原文展示时前端用 marked / markdown-it 渲染成 HTML。这样数据库里存的是一段普通文本占用空间小也方便做关键词搜索。有个参数需要提前定好笔记正文的字段类型用text而不是varchar。MySQL 的varchar最长 65535 字节但这是按字符集换算的utf8mb4 下实际最多存 16383 个汉字左右。一篇读书笔记加上摘录和感想很容易超过这个长度届时 Hibernate 建表会直接报错。用text类型64KB或longtext4GB就不会有瓶颈。如果你用 MyBatis Plus实体类上要加TableField(typeHandler JacksonTypeHandler.class)之类的注解来处理特殊类型不过对于纯 Markdown 字符串普通String字段直接映射就行不需要 typeHandler。2.4 检索方案先做 LIKE再考虑全文索引不要一上来就上 ES热搜词里频繁出现“springboot 整合”“源码”这类字眼很多人会误以为做一个带搜索功能的系统必须上 Elasticsearch。实际上当你的数据量在十万条以内时MySQL 的 LIKE 查询配合合理索引完全够用。读书笔记共享系统的数据量级——就算一个高校所有学生都用笔记总数也很难超过几十万条。在这个量级下WHERE title LIKE %关键字% OR content LIKE %关键字%的查询虽然会全表扫描但单表几十万数据、平均笔记长度 1KB 的场景下响应时间通常仍在几百毫秒以内对毕业设计演示毫无压力。如果论文想强调“检索性能优化”可以做一层轻量级方案给 title 字段加前缀索引给 content 字段建 FULLTEXT 索引MyISAM 或 InnoDB 的 ngram 解析器。MySQL 5.7 的 InnoDB 支持中文全文索引建表时用FULLTEXT KEY ft_content (content)查询时用MATCH(content) AGAINST(关键字 IN NATURAL LANGUAGE MODE)。这里有个坑ngram 默认分词长度是 2搜索单个汉字时查不到东西需要配置ngram_token_size2但最小支持 1配置 1 后单个字也能搜。更省事的做法是直接用 LIKE 糊一层然后在校验阶段通过explain看执行计划用数据说明“现阶段 LIKE 满足需求未来数据量增大后可平滑切换 ES”——这个表述在论文里比“我用了 ES”更容易自圆其说因为 ES 的部署和维护成本在毕设答辩时反而会成为被追问的重灾区。3. 从零搭出可运行的共享系统数据库脚本和 SpringBoot 项目骨架3.1 数据库设计五张表覆盖全部核心业务这个系统的实体并不复杂我按“用户—笔记—互动—关注”四个维度拆成五张表user用户、note笔记、category分类、note_like点赞、user_follow关注。如果要做收藏功能再加一张note_favorite但为了演示和论文篇幅点赞和收藏通常二选一我建议保留点赞因为点赞的计数更新逻辑更适合在论文里写“并发控制”。下面是最小可运行的建表脚本我直接把它放进源码包的sql/init.sql里。注意note表里的visibility字段0私有1公开2关注可见status字段预留审核能力默认 1 表示已发布0 表示草稿。有些二手源码会把草稿直接删掉但保留草稿功能会让论文的“用例图”多一个角色动作建议不删。CREATE DATABASE IF NOT EXISTS reading_notes DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE reading_notes; DROP TABLE IF EXISTS note; DROP TABLE IF EXISTS user_follow; DROP TABLE IF EXISTS note_like; DROP TABLE IF EXISTS category; DROP TABLE IF EXISTS user; CREATE TABLE user ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL COMMENT 登录名, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, nickname VARCHAR(50) DEFAULT NULL COMMENT 昵称, avatar VARCHAR(255) DEFAULT NULL COMMENT 头像URL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE category ( id BIGINT NOT NULL AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT 分类名如文学、技术、历史, sort INT DEFAULT 0 COMMENT 排序权重, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT笔记分类表; CREATE TABLE note ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 作者ID, category_id BIGINT DEFAULT NULL COMMENT 分类ID可空表示未分类, title VARCHAR(200) NOT NULL COMMENT 标题, content LONGTEXT NOT NULL COMMENT Markdown正文, book_name VARCHAR(100) DEFAULT NULL COMMENT 关联书名, visibility TINYINT NOT NULL DEFAULT 1 COMMENT 0私有 1公开 2关注可见, status TINYINT NOT NULL DEFAULT 1 COMMENT 0草稿 1已发布, like_count INT NOT NULL DEFAULT 0 COMMENT 点赞数冗余字段, view_count INT NOT NULL DEFAULT 0 COMMENT 浏览数, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_category_id (category_id), KEY idx_create_time (create_time), FULLTEXT KEY ft_title_content (title, content) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT读书笔记表;这段脚本有四个参数细节值得说明。第一密码字段长度设为 100因为 BCrypt 加密后的字符串长度是 60但有些实现会带前缀或 salt 信息留出余量可以避免后面改动字段第二title和content一起建了全文索引如果后续觉得搜索不准可以拆成两个单独的 FULLTEXT 索引分别做标题权重和正文权重第三like_count和view_count是典型的冗余计数每次点赞 / 访问时先更新计数再插入明细记录而不是实时count(*)第四所有外键都没有在数据库层面声明只建了普通索引——这是企业开发里的常见习惯让外键约束交给应用层处理避免删除用户时被外键拦住论文里也可以写“出于性能与扩展性考虑物理外键不建逻辑外键由 Service 层维护”。另外还需要note_like和user_follow两张表这里就不展开全部脚本了核心思路是note_like以(user_id, note_id)建联合唯一索引防止重复点赞user_follow以(user_id, follow_user_id)建联合唯一索引防止重复关注。两张表的主键都用自增BIGINT不要用联合主键因为在 MyBatis Plus 中联合主键需要额外配置自增单主键最省事。3.2 SpringBoot 工程骨架包结构、依赖版本与启动类拿到一个“源码论文”的压缩包第一步不是急着跑起来而是先看pom.xml里的 SpringBoot 版本。这里有一个高频坑很多老项目的源码是基于 SpringBoot 2.3/2.4 写的但你在新电脑上装的是 JDK 17直接运行会报UnsupportedClassVersionError或者Caused by: java.lang.IllegalArgumentException。常见的做法是把 SpringBoot 版本升到 2.7.18最后一个 2.x 版本兼容 JDK 8~17或 3.1.x要求 JDK 17。如果你用的是 IDEA 自带的 Spring Initializr 生成的 JDK 21 项目再落回 SpringBoot 2.7 会非常痛苦不如直接选 SpringBoot 3.1 对应的 MyBatis Plus 3.5.3。一个合理的包结构如下它和论文里的“系统设计—架构设计”章节能直接对应com.example.readingnotes ├── ReadingNotesApplication.java // 启动类 ├── controller // 控制层AuthController, NoteController, UserController │ ├── dto // 请求体与响应体对象 │ └── vo // 视图对象含分页信息 ├── service // 业务层接口与实现 │ └── impl ├── mapper // MyBatis Plus 的 Mapper 接口 ├── entity // 数据库实体类 ├── config // Sa-Token、CORS、WebMvc 配置 ├── common // 统一返回结果 Result、异常处理、常量 └── utils // 工具类JWT、MD5、字符串处理启动类没有任何特殊之处标准的三件套注解SpringBootApplication、MapperScan(com.example.readingnotes.mapper)、public static void main。但有一点需要注意如果你的 application.yml 里没有配置spring.datasource.url启动时会因为无法创建数据源而直接退出。很多二手源码会自带一个application-druid.yml或application-dev.yml运行前要确认spring.profiles.active指向了正确的环境。用 H2 内存库做演示也是一种常见做法但论文里如果截图是 H2 的 URL答辩时容易被追问“为什么不用 MySQL”所以我建议一律改成 MySQL并附上sql/init.sql。3.3 统一返回结果与全局异常让前后端联调少吵三次架这个项目的接口返回格式如果不统一Postman 调试时会很崩溃。我一般定义一个ResultT泛型类包含code、message、data三个字段成功时code200业务失败时code400或code401未登录时code401。Controller 里所有接口都返回Result?配合RestControllerAdvice做全局异常处理把MethodArgumentNotValidException参数校验失败、BusinessException自定义业务异常、Exception兜底分别映射到对应的 code。这样前端拿到非 200 的 code 后弹出 message 即可完全不用关心 HTTP 状态码。一个常用的参数校验技巧是在 DTO 字段上直接标注NotBlank(message 标题不能为空)、Size(max 200)SpringBoot 在进 Controller 方法前就会自动校验出错后由全局异常处理器统一返回。这比在 Service 里写几十行 if 判断干净得多论文里也可以写“通过注解式校验减少业务代码冗余”。4. 上传与分享链路笔记发布、全文检索、点赞关注的实现细节4.1 发布笔记的最小可用逻辑草稿、状态与标记清除发布笔记这个动作在NoteController里对应一个POST /api/note接口。请求体里带上title、content、categoryId、visibility、bookName如果status0则是保存草稿status1则是直接发布。在NoteServiceImpl里核心逻辑是判断当前登录用户与笔记作者是否一致、设置userId、调用save或saveOrUpdate。这里有个容易漏掉的点修改笔记时不能把create_time重置如果你是先查出来再 set 新值那么继续沿用原对象的创建时间如果直接用前端传回的对象去 update很可能把createTime覆盖成当前时间。Override public Long createNote(NoteCreateRequest request) { Note note new Note(); note.setUserId(StpUtil.getLoginIdAsLong()); note.setTitle(request.getTitle()); note.setContent(request.getContent()); note.setCategoryId(request.getCategoryId()); note.setBookName(request.getBookName()); note.setVisibility(request.getVisibility()); note.setStatus(request.getStatus()); note.setLikeCount(0); note.setViewCount(0); noteMapper.insert(note); return note.getId(); }这段代码的逻辑是从 Sa-Token 会话里拿到当前登录用户 ID然后逐字段装配新笔记。注意categoryId可能是 null此时分类接口要容错——查询笔记列表时如果categoryId为空则不做过滤而不是查出category_id IS NULL的数据。分页查询用 MyBatis Plus 的PageNote对象构造LambdaQueryWrapperNote时先eq(Note::getStatus, 1)再根据权限条件决定and嵌套里的过滤条件。一个可行的写法是如果当前用户已登录查询条件为(visibility1 OR (visibility2 AND user_id IN (select follow_user_id from user_follow where user_id当前用户)) OR user_id当前用户)如果未登录直接eq(visibility, 1)。把未登录场景单独处理是因为未登录用户不应该触发关注表查询这样也能减少一次无谓的数据库访问。4.2 点赞计数与并发用乐观锁还是直接 UPDATE点赞功能看着简单但并发下容易出数据不一致。比如两个人同时点赞like_count先读后写就可能丢更新。最简单的修复是直接用一条 SQL 完成自增不要先查询再更新。在 MyBatis Plus 里可以自定义 SQL也可以直接用UpdateWrapperboolean success likeService.saveOrUpdate(...); // 先插入点赞记录通过唯一索引保证不重复 if (success) { noteMapper.update(null, new LambdaUpdateWrapperNote() .eq(Note::getId, noteId) .setSql(like_count like_count 1)); }这里的关键是setSql(like_count like_count 1)它让数据库在原子层面完成自增避免并发覆盖。如果论文里想提“乐观锁”可以再给note表加一个version字段并在实体类上用Version注解MyBatis Plus 更新时会自动带上WHERE version ?。但对于点赞这种高频操作乐观锁失败重试的成本反而比直接自增高所以我更推荐上面这种 SQL 自增的方式并在论文的“性能优化”部分说明理由。取消点赞时逻辑是对称的先删除note_like记录再执行like_count like_count - 1。这里有一个隐藏很深的坑如果用户从未点赞却调用了取消点赞接口like_count会被误减成负数。解决方法是先查note_like是否存在存在才执行更新或者用UPDATE note SET like_count IF(like_count 0, like_count - 1, 0) WHERE id ?兜底。作为有经验的开发者我建议两层都做应用层保证业务不越权SQL 层保证数据不为负。4.3 全文检索与搜索历史从 LIKE 到 FULLTEXT 的平滑切换前面已经说过默认直接 LIKE 是最省心的。但既然建表脚本里加了 FULLTEXT 索引我在这里给出一个可以二选一的查询封装。默认情况下Service 里的searchNotes(keyword)方法是这样的// LIKE 版本兼容任何 MySQL 版本 ListNote notes noteMapper.selectList(new LambdaQueryWrapperNote() .like(Note::getTitle, keyword) .or() .like(Note::getContent, keyword) .eq(Note::getStatus, 1) .last(LIMIT 20));如果数据量变大或者答辩时想展示“全文索引”可以把上面的条件替换成apply(MATCH(title, content) AGAINST({0}), keyword)。这里有个需要提醒的点AGAINST 的{0}参数必须用 MyBatis Plus 的 apply 参数占位符不能直接字符串拼接否则会报 SQL 注入风险提示。FullText 的搜索默认是自然语言模式搜索“Java 编程”会被拆成“Java”和“编程”两个词想要更精确的短语匹配可以用布尔模式IN BOOLEAN MODE给关键词加上引号。实际测试下来“读书笔记”这种四个汉字的关键词在 ngram 默认 2 字分词下搜“读书笔”也能出结果但搜“读”就查不到——如果论文是在 Linux 环境部署我一般建议直接把ngram_token_size调成 1牺牲一点索引体积换取单字可搜用户体验更贴近手机输入法。搜索历史这个功能属于可选项做起来也不难在user_search_log表里记录user_id, keyword, search_time查询搜索热词时按关键字分组统计。论文里的“数据分析”或“系统亮点”部分可以拿它充一个章节但实现成本很低属于典型的“花小钱装大逼”功能。4.4 文件的落地与访问为什么推荐本地存储而不是 OSS如果共享系统允许上传封面图、附件如 PDF 摘录就会遇到文件存储问题。常见的做法有三种存 MySQL BLOB、存服务器本地、存云 OSS。对于毕设和课程设计本地存储是最稳妥的——因为 OSS 需要开通阿里云 / 腾讯云账号、配 Bucket 权限、写回调一旦你给的源码包里没有真实的 AccessKey答辩演示时一传文件就报错直接翻车。本地存储只需要一个upload/目录并通过配置给 SpringBoot 添加一个静态资源映射。Configuration public class WebMvcConfig implements WebMvcConfigurer { Value(${file.upload-path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/files/**) .addResourceLocations(file: uploadPath /); } }对应地在application.yml里有一行file.upload-path: /Users/你的用户名/reading-notes-upload上传接口用MultipartFile接收文件FileUtils.copyInputStreamToFile写入磁盘然后返回/files/时间戳_原文件名给前端拼完整 URL。参数里有一个坑Linux 部署时路径最后必须带斜杠否则file:协议映射会失败404 找不到资源。Windows 下开发用D:/upload/也可以但注意 SpringBoot 的file:前缀在 Windows 上写file:D:/upload/是合法的写file:D:\upload\则可能因为反斜杠转义出问题。关于文件大小的限制SpringBoot 默认单个文件最大 1MB如果不改配置传一张手机截图就报MaxUploadSizeExceededException。在 yml 里加上spring.servlet.multipart.max-file-size: 10MB和max-request-size: 10MB即可。这个参数卡住过很多人而且报错信息还不直观。5. 避坑指南源码包导入、版本地狱与部署现场的 5 个血泪教训5.1 “SpringBoot 版本太高”导致的启动失败先查 JDK 再看依赖热搜词里反复出现“springboot版本太高”“springboot 版本”这几乎是源码类项目最常见的翻车点。现象是导入源码后 IDEA 里一切正常一运行就报Unable to start ServletWebServerApplicationContext或Failed to configure a DataSource。前者通常是 Jackson 或 Tomcat 版本与 SpringBoot 不兼容后者则是没配数据源。解决路径是先看pom.xml的parent版本看 IDEA 里 Project Structure 的 SDK 是否匹配再按版本号去查对应的 MyBatis Plus 和 Sa-Token 依赖。SpringBoot 3.0 以后不能用javax.*包要用jakarta.*如果你的源码里大量出现import javax.servlet.http.HttpServletRequest且编译不过只能二选一降回 SpringBoot 2.7或全局替换javax为jakarta。多数情况下把项目直接降到 2.7.18 是最省时间的选择。5.2 数据库初始化“成功”但登录表里没数据字符集与 SQL 版本不一致很多源码包里的init.sql是作者从 Navicat 导出的里面可能带SET NAMES utf8mb4或SOURCE命令。直接在命令行手动执行时如果终端字符集是 utf8而表定义是 utf8mb4中文分类名容易变成乱码。解决方法是执行前先SET NAMES utf8mb4;然后用source命令导入时也会带乱码风险建议用 IDEA Database 工具或 Navicat 直接运行整个 SQL 文件这两个工具会正确识别文件编码。另外如果 SQL 文件里有DROP TABLE IF EXISTS在已有数据的库里跑会清库操作前一定确认这不是你的生产库——毕设阶段无所谓如果是在公司环境演示别手滑。5.3 部署到云服务器后图片裂了SpringBoot 静态资源与 Nginx 的归属问题如果是单机部署SpringBoot 的静态资源映射能正常取到本地文件。但很多人会用宝塔或 Nginx 做反向代理这时/files/**的请求会被 Nginx 拦截并转发到 SpringBoot 的 8080 端口。如果 Nginx 配置了location / { proxy_pass http://127.0.0.1:8080; }一般情况下没问题但如果 Nginx 对静态文件设置了try_files或expires或者root指向了别的目录你的图片就会 404。我的建议是部署阶段不要把/files/交给 Nginx直接在 Nginx 里写一个location /files/ { alias /www/wwwroot/reading-notes-upload/; }让 Nginx 直接读磁盘SpringBoot 只负责上传写文件。这样不仅访问速度快还能避免 SpringBoot 容器重启时临时文件丢失。已有的图片还是裂多半是上传时文件名带了中文或空格返回给前端的 URL 没有做 URL 编码浏览器请求时解析失败。解决方法是上传时统一重命名为yyyyMMddHHmmss_随机数.扩展名丢弃原始文件名。论文里可以把这写成一个“文件安全命名策略”也算一个能讲的亮点。5.4 全文索引不生效MySQL 表引擎与 ngram 配置的连环坑如果你选择了 FULLTEXT 方案有一个很容易被忽略的事实MySQL 5.7 默认全文索引只支持英文分词中文要用 ngram 插件。检查办法是执行SHOW VARIABLES LIKE ngram_token_size;如果结果为 2你可以改配置文件my.cnf里的ngram_token_size1后重启 MySQL。但改这个参数会让 MySQL 重建所有全文索引如果表很大启动会变慢。另一个隐蔽问题是LIKE 和 FULLTEXT 两条查询路径对空格和标点的处理逻辑不同同一关键词在搜索结果页和首页“热门笔记”里可能数量不一致测试时注意对账。如果项目在 Windows 本地跑MySQL 服务是mysql命令启动的修改my.ini后需要重启服务如果在 Docker 里跑 MySQL需要挂载配置文件并重建容器。很多人把ngram_token_size写在了[mysqld]下面但 MySQL 8.0 里这个参数必须在[mysqld]之前加载顺序错了直接启动失败。这个坑我踩过一次当时手动执行 SQL 建表一直提示“token not found”后来才发现是配置放在[client]组里导致不生效。5.5 论文写的和代码对不上页面跳转方式与前后端分离的错位部分源码包里早期版本是 Thymeleaf 模板渲染后期作者把前端改成 Vue 了但论文截图还停留在模板版。答辩时老师对比截图和现场 URL发现前端框架对不上会直接被质疑“是不是别人的项目”。解决方法是在代码里保留两种入口或至少保证截图里的页面能被访问到如果源码是前后端分离的你可以在resources/static下放一个index.html里面用 axios 调用后端 API让评委通过http://localhost:8080/直接看到主要页面。无需上线前端工程只需把 Vue 构建后的dist内容复制到static目录同时确保接口是相对路径或带正确前缀。这是毕设演示最稳的做法一套代码直接跑通不再依赖npm run dev进程。6. 进阶与验证写自动化测试、打印执行计划并给论文补上性能数据如果你不想让这个项目停在“能跑”的层面我建议花半天时间补三样东西接口冒烟测试、SQL 执行计划分析、压力测试报告。这三样是论文“系统测试”章节的硬货也是答辩时老师最喜欢问的部分。先加一个 SpringBoot 自带的测试类用 MockMvc 测登录、发布笔记、搜索三个主流程SpringBootTest AutoConfigureMockMvc public class NoteApiTest { Autowired private MockMvc mockMvc; Test public void testPublishNote() throws Exception { // 先登录拿到 token再发布笔记 MvcResult loginResult mockMvc.perform(post(/api/auth/login) .contentType(MediaType.APPLICATION_JSON) .content({\username\:\test\,\password\:\123456\})) .andExpect(status().isOk()) .andReturn(); String token JsonPath.read(loginResult.getResponse().getContentAsString(), $.data.tokenName); String tokenValue JsonPath.read(loginResult.getResponse().getContentAsString(), $.data.tokenValue); mockMvc.perform(post(/api/note) .header(token, tokenValue) .contentType(MediaType.APPLICATION_JSON) .content({\title\:\《活着》读后感\,\content\:\# 第一章 感悟\,\visibility\:1,\status\:1})) .andExpect(jsonPath($.code).value(200)); } }这段测试代码的注意点是Sa-Token 的请求头名称默认是satoken如果你在配置里改过token-name这里的 header 名也要跟着改。很多源码里的 Token 头是Authorization用 Sa-Token 的话可以直接在拦截器里配置别名。看着测试通过还不够我还会直接在 MySQL 里执行项目生成的 SQL 语句前面加EXPLAIN重点看type和rows两列。如果typeALL且rows10000说明没走索引。对于公开笔记列表的分页查询这个 SQL 一般是这样EXPLAIN SELECT * FROM note WHERE status 1 AND visibility 1 ORDER BY create_time DESC LIMIT 10;这里最容易忽略的优化点排序字段create_time如果没有索引MySQL 会先查出全量数据再用 filesort 排序数据量大时很慢。解决方法是建一个联合索引(status, visibility, create_time)让查询走的索引天然有序Extra里不再出现Using filesort。这个优化在论文里可以写满半页老师一听就明白你真的理解索引。压力测试我一般用 JMeter不开 GUI 而是用命令行跑这样给出的数据更可信。测试内容就是 100 个线程循环 10 次请求/api/note/public列表接口观察Throughput和Error%。如果错误率大于 1%九成是数据库连接池默认配置太小——SpringBoot 默认 HikariCP 最大连接数是 10并发一高就Connection is not available。把spring.datasource.hikari.maximum-pool-size调到 50 一般就能解决这又是一个能在测试章节里写“优化前后对比”的素材。最后一句来自我的习惯每个项目交付前我会重新解压一次源码包按 README 从零走一遍部署流程确保我写出的启动步骤不是靠我电脑里的残留环境。很多“源码能跑”的假象都是因为在原项目目录里跑过太多次环境变量、本地数据库都留着旧配置。重新解压后再踩一遍坑才算真正交付。希望帮到你。本文还有配套的精品资源点击获取
