简介：在Java Web开发领域，Spring Boot凭借自动配置与生态整合能力，成为企业级应用和毕业设计的主流框架。理解其底层原理，如依赖注入、自动配置机制，是掌握后端开发的关键。结合MySQL数据库设计与MyBatis Plus持久层框架，可以显著提升CRUD操作效率，让开发者更专注业务逻辑。对于交易类系统，JWT无状态认证保障接口安全，而前端通过Vue与Axios实现前后端分离交互，则贴近现代工程实践。本文以校园二手书交易平台为例，完整梳理从角色划分、表结构设计到订单并发控制、文件上传、部署避坑的整个链路，适用于需要快速搭建管理系统的开发场景，也为学习Spring Boot整合技术栈提供了一份可复用的工程模板。
1. 项目概述与整体设计思路
每年毕业季，总有一批计算机相关专业的学生在“做什么课题”这件事上纠结。如果你正在选毕业设计题目，或者已经选了“基于SpringBoot的校园二手书交易管理系统”但还没想清楚怎么做，这篇文章可以直接帮你把整个项目的骨架立起来。
先说清楚这个项目到底是什么。它本质上是一个面向高校场景的C2C（个人对个人）二手图书交易平台，功能对标闲鱼的书本交易模块：学生注册登录后可以发布闲置教材、小说、考研资料，其他同学可以浏览、搜索、下单购买，买卖双方在线沟通或线下交易。技术栈以Spring Boot为主，配合MyBatis Plus操作MySQL，前端可以用Vue或Thymeleaf模板引擎，整体是一个前后端分离或半分离的典型Java Web项目。
为什么这个题目被反复选为毕业设计？原因很直接：它是标准的“管理系统”类课题，业务模型清晰，技术覆盖面广，基本上每个学校Java方向的学生都会学到Spring Boot、MySQL、MyBatis这些技术，做起来不至于超纲，但又能体现出完整的开发流程。更重要的是，校园二手书这个场景非常具体，不像“超市管理系统”那么套路化，论文写起来也有真实的需求分析可讲，答辩的时候老师问起来也答得上来。
我拆解这个项目的思路时，第一件事不是写代码，而是把角色和流程定住。系统里必须要有两类角色：普通学生用户和管理员。学生可以注册、登录、发布图书、修改下架图书、浏览图书、下单求购、管理个人收货信息；管理员则负责用户管理、图书审核、分类管理、订单监控、统计报表。第三类角色“游客”要不要做？看个人时间和需求，做了可以看图书列表但无法下单，不做也不影响主流程，建议时间紧就直接砍掉。
从业务流来看，核心链路只有三条：登录注册、图书发布与检索、订单交易。把这三条链路跑通，系统就完成了八成。其余功能比如评论、收藏、站内信、在线支付都属于锦上添花，毕设项目里能用模拟支付或者直接标记“线下交易”就行，千万别一上来就想着对接支付宝微信，那是给自己挖坑。
技术选型上，我建议用Spring Boot 2.x版本配合JDK 8，原因后面会细说。数据库用MySQL 5.7或8.0，ORM用MyBatis Plus而不是原生MyBatis，因为它的代码生成器和通用Service能省掉大量重复性的CRUD工作，CURD写得多不代表能力强，把时间花在业务逻辑和论文质量上才是正路。
前端框架这块要看你的定位。如果是前后端分离项目，用Vue 3 + Element Plus或者Vue 2 + Element UI都行，前端单独跑在一个端口，通过HTTP请求调用后端接口；如果不想搞那么复杂，直接用Spring Boot自带的Thymeleaf渲染页面，一个项目包就能跑起来，部署省事。我带过不少学生，大多数人的前端基础都不算扎实，所以我个人更推荐前后端分离——不是因为它简单，而是因为和论文里的“系统设计”章节更匹配，画架构图、写接口文档都有素材。
2. 数据库设计与核心表结构
这个项目的核心在数据库设计，表结构设计得合理，后面代码怎么写都顺；表结构混乱，到联调阶段就会各种难受。校园二手书交易系统里最重要的几张表，我一个个拆开讲。
2.1 用户表：区分角色是第一步
用户表是系统的基础，我习惯叫它sys_user，字段主要包含主键id、用户名、密码、昵称、头像、手机号、邮箱、角色（0管理员/1普通用户）、状态（0禁用/1正常）、创建时间、更新时间。密码这里千万不能明文存储，用BCrypt加密，Spring Security自带的BCryptPasswordEncoder就能搞定，注册的时候加密，登录的时候比对。
额外的信息比如学号、专业、学院这些，看需求。如果论文里有“用户信息管理”这个功能点，建议加上学号字段，并且做唯一约束，这样管理员在后台查重、审核的时候也方便。地址信息别一股脑塞用户表里，因为用户可能填多个收货地址，建议单独建一张user_address表，通过user_id关联，这也是数据库范式的基本要求，论文里能当作设计亮点来写。
2.2 图书表：状态字段驱动业务流程
图书表是这个项目的灵魂，我把它命名为book_info。核心字段包括主键id、书名、作者、出版社、ISBN号、原价、售价、成色（全新/九成新/八成新等）、分类id、描述、封面图片URL、发布人id、状态（0待审核/1在售/2已售出/3下架/4审核驳回）、浏览数、创建时间、更新时间。
最关键的字段是“状态”，它驱动着整个图书的生命周期。学生发布图书后，管理员审核通过才进入在售状态，其他用户才能看到；一旦被下单且交易完成，就变成已售出状态，别人就看不到了；发布人自己也可以主动下架。用整型数字表示状态比用字符串更高效，而且在代码里写枚举判断也更清晰，答辩的时候可以顺便讲一讲“状态机”的概念，这是加分项。
图书封面的存储是个容易纠结的问题。如果直接把图片以Base64字符串存在MySQL里，数据库会很臃肿，备份恢复都慢。建议服务器本地存储或者用对象存储，数据库只存访问路径。本地环境的话，在配置里设置一个虚拟路径映射到上传目录，比如file:D:/upload/映射到/images/**，这样页面上的<img>标签直接引用就好。
2.3 订单表与交易流程设计
有了用户和图书，订单表就是连接两者的桥梁。订单表order_info的字段大致是：主键id、订单编号、买家id、卖家id、图书id、交易金额、订单状态（0待付款/1已付款/2已完成/3已取消/4退款）、下单时间、支付时间、完成时间。
这里有个细节值得注意：订单表里要把买家id和卖家id都存下来，因为一次交易涉及两个用户，如果只存买家id再通过图书表反查卖家id，查询效率低不说，一旦图书被删除或状态变更，订单历史就查不到了。数据冗余一点没关系，保证订单的独立性更重要，这也是经验。
交易流程建议这样走：用户点击“立即购买”创建订单，初始状态为待付款；点击“确认支付”后状态改为已付款，此时图书状态同步变为“已售出”，防止别人重复下单；卖家确认发货或双方线下完成交易后，买家点击“确认收货”，订单状态变为已完成。这里做不做在线支付？我建议用“模拟支付”逻辑，就是点击支付直接弹窗提示“支付成功”，把精力留给核心业务，论文里写“本系统使用模拟支付方案”就能交代过去。
2.4 辅助表：分类、评论、收藏
分类表book_category就是简单的树形结构也行、扁平结构也行：id、父级id、分类名称、排序。教材、教辅、文学小说、考试资料、计算机书籍，这些常见分类在一开始通过SQL脚本初始化进去，后台管理页面提供增删改查接口。
评论表和收藏表属于增强功能，有时间就做。评论表字段：id、图书id、用户id、内容、回复目标id、创建时间。收藏表字段：id、用户id、图书id、创建时间，加上联合唯一索引保证同一用户不会重复收藏同一本书。这些功能不用太复杂，能跑通、能展示在页面上、能在论文里写清楚表结构就行。
数据库这块还有个容易被忽视的点：所有表都要有create_time和update_time两个字段，MyBatis Plus的自动填充功能可以帮你维护这两个字段，不需要手动set值。论文里的ER图、数据库设计说明，写起来也更规范、更完整。
3. 项目搭建与关键代码实现
讲完设计层面的东西，接下来进入实操环节。我会把从零搭建项目到核心接口实现的完整步骤走一遍，这部分是我觉得整个项目最值得收藏的内容，照着操作基本不会卡壳。
3.1 用Spring Initializr快速创建项目
创建Spring Boot项目的时候，我不建议去官网手动下载压缩包，直接在IDEA里新建Spring Initializr项目最方便。但如果你的IDEA版本里面没有“Spring Initializr”这个选项，那是工具版本的问题，可以直接访问Spring官网的初始化页面，填好Group和Artifact之后点击Generate下载zip包，然后解压导入IDEA。
关键的依赖选择上，这里给一份我验证过的清单：
Spring Web MyBatis Plus Framework（如果没有这个选项，后期手动加依赖） MySQL Driver Lombok Validation如果你打算做前后端分离，再加一个Spring Security或者Sa-Token做认证授权。但这里有个坑要提前说：Spring Security的过滤器链规则配置有些学习成本，如果你之前没用过，建议用Sa-Token或者JWT配合拦截器来实现登录认证，逻辑更直观，也更容易在论文里写清楚。
后续的代码生成环节，MyBatis Plus Generator可以一次性生成实体类、Mapper接口、Service接口、ServiceImpl实现类、Controller控制器，配合模板引擎还能生成Vue页面。没有用过的同学可能会觉得这一套很复杂，其实花二十分钟跑一次就熟了，生成出来的代码虽然有些冗余，但是作为毕设的代码量支撑完全够用，答辩时演示也说得过去。
pom.xml文件这里需要特别注意版本冲突的问题。我见过太多学生把Spring Boot版本升到3.x，然后发现MyBatis Plus的旧版本不兼容，报各种ClassNotFound异常。如果你不熟悉Spring Boot 3和Jakarta命名空间的迁移，老老实实用Spring Boot 2.7.x加JDK 8，这是目前网上教程最多、踩坑最少的方案。
3.2 统一返回结果与全局异常处理
这块是项目里最有“工程感”的部分，也是很多初学者容易忽略的地方。第一个要做的，是定义统一的返回结果类Result<T>，包含code、message、data三个字段。所有Controller接口的返回值都用它包一层，前端拿到数据后根据code判断是否成功，整个项目的接口风格就统一了。
public class Result<T> implements Serializable { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }配合全局异常处理器@RestControllerAdvice，把业务异常、参数校验异常、数据库异常分别处理，返回对应的错误码和提示信息。这样一来，前端不需要处理各种奇怪的异常堆栈，只需要统一弹出message字段里的信息给用户看。我在项目里还习惯加一个BusinessException自定义异常，业务代码里直接throw new BusinessException("这本书已售出")，全局处理器拦截并包装成统一的错误响应，代码会干净很多。
3.3 用户登录与JWT认证
登录模块我推荐用JWT做无状态认证，不依赖Session，前后端分离下体验很好。流程是：用户提交用户名和密码，后端验证通过之后生成一个token返回给前端，前端存在localStorage里，每次请求在请求头带上Authorization: Bearer <token>，后端通过拦截器解析token判断用户身份。
JWT本身不复杂，核心代码就是生成和解析。用io.jsonwebtoken库的Jwts.builder()生成，里面放入用户id、用户名、角色、过期时间，用密钥签名；解析的时候用Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody()取出相关信息。
这里要特别提醒一个安全细节：JWT的密钥不要硬编码在代码里，把密钥放到application.yml的配置项中，通过@Value注解读取。过期时间建议设置成24小时，太短会导致用户频繁登录，太长又不安全。对于毕设来说，24小时完全够用。
拦截器配置的时候要注意放行路径：登录接口、注册接口、图书列表接口这些肯定要放行；但发布图书、下单购买、个人信息查询这些接口必须拦截。不能全放行也不能全拦截，这个边界得想清楚。用Spring MVC的WebMvcConfigurer的addInterceptors方法注册拦截器，顺便把静态资源路径也放行了，不然前端页面访问不到。
3.4 图书发布与图片上传
图书发布是整个系统最复杂的表单，字段多，还带文件上传。前端页面上要有一个表单，里面包含书名、作者、ISBN、售价、成色下拉框、所属分类下拉框、描述文本域和封面图上传组件。提交的时候用multipart/form-data格式，也就是FormData对象，一个请求同时携带JSON字段和图片文件。
后端接收的时候这样写：
@PostMapping("/book") public Result<?> publishBook(@RequestParam("cover") MultipartFile cover, BookInfoDTO dto, @RequestAttribute("userId") Long userId) { // 保存文件到本地 String coverUrl = fileService.upload(cover); // 组装book对象 BookInfo book = new BookInfo(); BeanUtils.copyProperties(dto, book); book.setCover(coverUrl); book.setPublisherId(userId); book.setStatus(0); // 待审核 bookService.save(book); return Result.success(null); }图片上传的FileService实现时，注意一个关键点：文件名不能直接使用用户上传的原始文件名，那样既容易重名覆盖，又有路径穿越的安全风险。正确的做法是生成UUID作为新文件名，保留原始文件的后缀名，存储到一个按日期分目录的文件夹里。
文件上传大小默认是1MB，很多学生上传图片的时候会报错，就是没改配置。要在application.yml里设置：
spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB3.5 图书列表查询与条件搜索
图书列表页是用户打开系统后第一个看到的核心页面。列表查询接口支持分页、按分类筛选、按关键词搜索、按价格区间过滤、按发布时间排序，条件一多，代码就容易写乱。我的习惯是构建一个BookQueryDTO查询对象，所有筛选条件都放在这个DTO里，然后在Service层动态拼接查询条件。
public PageResult<BookInfo> queryBookPage(BookQueryDTO query) { LambdaQueryWrapper<BookInfo> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(BookInfo::getStatus, 1); // 只查在售 if (StringUtils.hasText(query.getKeyword())) { wrapper.and(w -> w.like(BookInfo::getTitle, query.getKeyword()) .or().like(BookInfo::getAuthor, query.getKeyword()) .or().like(BookInfo::getIsbn, query.getKeyword())); } if (query.getCategoryId() != null) { wrapper.eq(BookInfo::getCategoryId, query.getCategoryId()); } if (query.getMinPrice() != null) { wrapper.ge(BookInfo::getPrice, query.getMinPrice()); } if (query.getMaxPrice() != null) { wrapper.le(BookInfo::getPrice, query.getMaxPrice()); } wrapper.orderByDesc(BookInfo::getCreateTime); Page<BookInfo> page = new Page<>(query.getPageNum(), query.getPageSize()); bookInfoMapper.selectPage(page, wrapper); return new PageResult<>(page.getTotal(), page.getRecords()); }这块的代码不难，难的是对查询条件的理解，比如搜索功能要支持书名模糊搜索、作者搜索，还能搜ISBN号。like查询在数据量大时性能不太好，但对毕设级的数据量来说完全不是瓶颈，答辩的时候如果老师问性能优化，你就说“可以结合全文检索引擎或加索引优化”，不用真的去实现。
3.6 下单与订单状态流转
下单接口是整个交易系统最关键的一环，它涉及两个核心问题：超卖和状态同步。这里说个最简但有效的实现方式：下单接口只用两步，第一步校验图书状态是否为在售，第二步把图书状态改为已售出并创建订单。要用UPDATE ... SET status = 2 WHERE id = ? AND status = 1这样的原子更新，保证同一个瞬间只有一个人能买到这本书。
用MyBatis Plus写这个逻辑时，可以直接用LambdaUpdateWrapper：
boolean update = bookService.update(new LambdaUpdateWrapper<BookInfo>() .eq(BookInfo::getId, bookId) .eq(BookInfo::getStatus, 1) .set(BookInfo::getStatus, 2)); if (!update) { throw new BusinessException("图书已下架或已被购买"); }这一小段代码里其实藏着数据库事务和并发控制的原理，论文的“核心功能实现”一章可以大讲特讲，答辩的时候老师问到并发问题，直接用这段代码来回答就行。如果还觉得不够深，可以加个@Transactional注解保证创建订单和更新图书状态在同一个事务里，任何一个失败就整体回滚。
订单状态流转上，要保证操作权限：买家能查看自己的订单、确认收货、取消未付款订单；卖家只能查看出售记录，不能代替买家确认收货。这些判断可以统一封装在OrderService里，通过@RequestAttribute("userId")拿到当前登录用户id，在执行操作前校验当前用户是否为订单的买家或卖家，不匹配直接抛异常。
4. 前端页面搭建与接口联调
前端不管用Vue还是Thymeleaf，页面结构都逃不掉那几个核心模块：登录注册页、首页图书列表、图书详情页、发布图书页、个人中心、订单管理、后台管理。如果你是前后端分离开发，我建议用Vue 3加上Vite脚手架，Element Plus做UI组件库，Axios做HTTP请求封装，路由用Vue Router。
4.1 Vue项目初始化和目录组织
创建Vue项目用npm create vite@latest命令，选择Vue模板后一路回车。装依赖的时候，核心的依赖就三个：vue-router、pinia（或者直接用Vuex也行）、axios，UI库按需引入Element Plus。
项目的目录结构建议这样组织：
src/ ├── api/ # 所有后端接口封装 │ ├── user.js │ ├── book.js │ └── order.js ├── router/ # 前端路由配置 ├── views/ # 页面组件 │ ├── Login.vue │ ├── Register.vue │ ├── Home.vue │ ├── BookDetail.vue │ ├── PublishBook.vue │ └── admin/ ├── components/ # 公共组件 └── utils/ # 工具函数4.2 Axios请求封装与登录态管理
Axios拦截器是前端项目里第一个要写的工具代码。请求拦截器里统一把localStorage里的token塞进请求头，响应拦截器里统一处理code不为200的情况，要跳转登录页的跳转登录页，要弹错误提示的弹提示。
// api/request.js import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const request = axios.create({ baseURL: '/api', // 通过vite代理转发到后端 timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) if (res.code === 401) { router.push('/login') } return Promise.reject(new Error(res.message)) } return res }, error => { ElMessage.error('网络请求失败') return Promise.reject(error) } ) export default requestbaseURL用/api相对路径，然后在vite.config.js里配置代理，把请求转发到Spring Boot的8080端口。这样就完美解决了开发阶段的跨域问题，部署阶段也不用改前端代码。
4.3 首页图书列表和详情页
首页用栅格布局展示图书卡片，每个卡片上显示封面、书名、价格和成色。用Element Plus的el-card组件包裹，搭配el-row和el-col实现响应式布局。搜索框放在页面顶部，支持按关键词搜索、按分类筛选。
图书详情页的技术点主要是：调用详情接口获取数据、展示图书基本信息、判断当前用户是否为发布者（如果自己是发布者就不显示“购买”按钮）、显示评论区。
4.4 后台管理页面
管理员的后台页面，主要功能是用户管理和图书审核。这个页面不要求花哨，用Element Plus的el-table组件展示数据列表，加上分页组件，操作列放“通过”“驳回”“删除”按钮即可。统计报表如果要做，用echarts引入柱状图、饼图组件，展示图书分类占比、每日新增用户数，这个在论文的“系统测试”和“系统展示”章节非常加分。
4.5 前端打包与部署
开发完成之后，前端执行npm run build，会在dist目录生成静态文件。部署的时候有两种方式：第一种是把dist目录复制到Spring Boot项目的src/main/resources/static下面，然后启动后端，直接访问8080端口就能看到页面。这是最省事的部署方式，适合答辩前不熟悉服务器操作的同学。第二种是前后端完全分离部署，前端用Nginx托管静态文件，后端跑在8080端口，通过Nginx配置反向代理转发/api请求，这样更接近企业真实环境，论文的“部署说明”一章也能写得更有深度。
我个人的建议是：本地演示用第一种方式，论文里可以写第二种方式，然后再补一段Nginx配置。这样既不用在答辩现场折腾环境，又能展示你对部署的理解。
5. 代码调试、常见问题与避坑经验
做项目的过程中一定会踩坑，有些坑你已经踩过了，有些还没踩到。我根据带项目积累下来的经验，把最经典的几个问题整理出来，每个问题后面都附了解决方案。
5.1 CORS跨域请求报错
前后端分离开发时，“跨域”是遇到概率最高的报错。现象是浏览器控制台报Access-Control-Allow-Origin错误。解决方案有两种，后端加一个CorsConfig配置类，放行所有来源；或者前端在Vite里配置代理。我推荐第二种方式，因为上线部署的时候前后端同域部署，代理配置不用改，而后端放开所有来源会有安全风险，答辩时如果被问到，解释起来也麻烦。
5.2 MyBatis Plus查询字段映射问题
当实体类的属性名和数据库字段名不一致时，容易查询出null值或者报错。比如数据库字段是publisher_id，Java属性是publisherId，MyBatis Plus的自动驼峰转换默认是开启的，通常没问题。但如果字段名对不上，可以用@TableField("publisher_id")注解显式指定映射。这个属于细节问题，排查起来还挺费时间的，建议创建表的时候就直接用下划线命名，实体类用驼峰命名，省去后续麻烦。
5.3 图片上传后访问404
这种问题大多不是代码逻辑错误，而是虚拟路径映射没配好。在Spring Boot里自定义WebMvcConfigurer，重写addResourceHandlers方法映射静态资源，或者干脆把上传目录放在项目内的upload文件夹，然后通过spring.web.resources.static-locations配置添加路径。最简单的做法是项目内创建一个upload目录，启动时确保目录存在，代码里用System.getProperty("user.dir")获取当前项目路径，拼接出绝对路径保存文件。
5.4 数据库连接配置和时区问题
MySQL 8.0连接串一定要加上时区参数，否则会报The server time zone value ... is unrecognized。JDBC连接串写成：
spring: datasource: url: jdbc:mysql://localhost:3306/second_hand_book?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai如果不加characterEncoding=utf8，存中文会乱码；不加serverTimezone，某些版本的JDBC驱动在连接时会报时区错误。这几个参数都是血泪教训，配数据源的时候直接按这个写就不会出问题。
5.5 JWT Token过期后请求报错
Token过期后，后端拦截器会解析失败，抛异常。如果不做特殊处理，前端只会在控制台看到一个500错误。比较好的方案是后端统一返回401状态码，前端拦截器发现401就跳转到登录页，让用户重新登录。在全局异常处理器里捕获ExpiredJwtException，返回Result.error(401, "登录已过期")，然后前端如果检测到code为401或HTTP状态码为401就清理本地存储并跳转路由。
5.6 浏览器上传图片时Gitee/GitHub图片外链失效
做毕业设计的时候，很多同学喜欢把图片上传到图床或者GitHub上，结果写论文的时候发现图片链接全挂了。我建议所有图片都存本地，论文截图直接用本地图片，系统里的图片路径也是后端本地地址。腾讯云COS或者阿里云OSS这类对象存储虽然好用，但需要开通服务、配置密钥，对于毕业设计来说有些重了，除非你的论文里专门写了“云存储方案设计”这一章，不然不推荐引进来给自己增加工作量。
5.7 关于“源码+论文”组合的交付物整理
最后说一句和代码无关但非常重要的建议：答辩之前，把项目的交付物整理清楚。不要只提交一个代码压缩包就完事。一份完整的毕设交付物应该包含：源码目录（前后端分开）、数据库脚本SQL文件、项目部署说明文档（包含启动步骤、账号密码、JDK版本等）、论文Word文档、答辩PPT。数据库脚本一定要单独提供，很多同学把建表语句埋在代码里或者根本没有，评委老师想在本地跑一下你的系统，第一步就卡住了。另外，README文件里写上默认管理员账号密码，比如admin/admin123，方便快速演示。
6. 项目复盘与升级方向
到这里，一个完整的基于Spring Boot的校园二手书交易管理系统就已经从设计、实现到部署全部走完了。回头看一下整个技术栈：Spring Boot提供基础框架，MyBatis Plus负责数据持久化，MySQL存数据，Redis可以做缓存和验证码存储，JWT管理登录态，Vue搭建前端页面。这套组合作为毕业设计来说，覆盖面足够、难度适中、工作量可见。
如果你的时间还有富余，我建议往下面几个方向加点料。第一个，增加Redis缓存，把图书分类、热门图书列表缓存起来，代码里加个@Cacheable注解，论文里可以写“基于Redis的缓存策略优化”，这个提升非常明显。第二个，增加消息推送，比如用户收藏的图书被别人买走时、自己发布的图书被下单时，系统产生站内通知，可以用WebSocket实现实时推送，复杂度和工作量适中。第三个，增加数据统计模块，用ECharts画出图书分类占比、交易金额趋势、用户活跃度的图表，管理端的数据看板就成型了，论文里也能多放几张页面截图。
补充一点，如果你想深挖源码层面的东西，推荐把Spring Boot的自动配置原理和MyBatis Plus的分页插件原理搞明白。面试和答辩中，这两个点是高频考点，也是拉开差距的地方。Spring Boot的spring.factories机制其实就是它的核心——自动把装配好的xxxAutoConfiguration类注入到Spring容器里；MyBatis Plus的分页插件本质上是基于MyBatis的拦截器机制，在SQL执行前改写SQL，追加LIMIT语句。能把这个讲清楚，比背一百道面试题都管用。
这个项目做完，你收获的不只是一个能通过答辩的系统，而是一整套从前端到后端、从设计到部署的完整开发链路认知。以后再遇到什么“校园XX管理系统”“XX交易平台”的题目，直接复用这套框架，换个业务域名、调调表结构，很快就能搭出一套新系统。这大概就是做毕设最大的价值。
本文还有配套的精品资源，点击获取
