1. 项目概述与核心需求拆解1.1 为什么图书销售系统是毕业设计的“经典样本”在线图然销售系统这个题目在计算机毕业设计选题里已经算得上“常青树”了。选它的人多不是因为它容易混日子而是因为这个业务场景能覆盖毕业设计里几乎所有的核心考核点前后端数据交互、用户权限控制、商品多维检索、购物车状态管理、订单状态流转、数据库事务一致性。一套做下来基本把 Web 开发主线的知识都过了一遍而且书这个商品天然适合在线销售——它有封面、有分类、有库存、有单价数据特征丰富做出来的界面和演示效果都很好看不会像“员工管理系统”那样干巴巴的。很多人担心这个题目太普通答辩时会被老师挑刺。我的看法恰恰相反题目普通不代表做不出亮点。同样的图书销售系统有人只做了 CRUD有人做出了订单超时取消、销量榜单、用户行为记录、图片上传预览、数据可视化报表。差距不在题目而在你对业务闭环的理解和执行深度。这个项目本质上是“电商系统的图书垂直版”只要电商核心链路完整它就是一套合格的毕业设计。1.2 系统角色与核心业务流程在线图然销售系统主要涉及两类角色前台用户和后台管理员各自的工作流清晰分开这也是为什么它适合作为面试或答辩演示项目——角色边界越清楚越能体现出系统设计的模块化意识。前台用户的核心路径是注册登录 → 浏览首页推荐 → 搜索或按分类筛选图书 → 进入详情页 → 加入购物车 → 结算生成订单 → 模拟支付 → 查看订单状态 → 确认收货 → 发表评论。这条路径覆盖了商品流和信息流的完整循环。后台管理员的核心路径是图书上架与维护 → 分类管理 → 处理用户订单发货、取消 → 用户管理 → 查看销售统计。订单状态我建议用一组固定状态码管理待支付、已支付待发货、已发货、已完成、已取消不要用字符串散着写否则后面统计时会非常痛苦。这里有一个容易被忽略的设计点订单状态机。很多初学同学把订单状态当成一个普通字段想改就改结果出现“已取消的订单还能发货”这种笑话。我建议在代码里用一个状态流转常量类统一管理并给每个状态定义允许跳转的方向比如只有待支付能转已取消待支付能转已支付已支付才能转已发货。这个设计在答辩时讲出来是明显的加分项。2. 技术选型为什么是SpringBoot2.1 SpringBoot相比传统SSM/SSH的选型优势如果是五六年前做这类毕设的主流方案还是 SSMSpring SpringMVC MyBatis需要手写大量 XML 配置光整合配置文件就能劝退一批人。现在用 SpringBoot最直观的感受是“少写一半配置文件”。SpringBoot 的自动配置机制把常用的数据源、事务管理器、Web MVC 配置都内置好了你只需要在application.yml里写上数据库连接和少量个性化配置项目就能跑起来。更关键的是SpringBoot 的生态成熟度远高于传统 SSM。比如做分页MyBatis-Plus 官方提供了分页插件一行配置就能用做登录拦截SpringBoot 的 HandlerInterceptor 配合注册配置类几行代码搞定做单元测试spring-boot-starter-test直接拉入场景启动器。对于毕业设计这种工期紧张、一个人要搞定前后端所有环节的场景SpringBoot 能把开发期的时间成本压缩到传统配置方式的三分之一以下。从答辩角度讲SpringBoot 也是目前企业主流技术栈的基础。如果面试官或答辩老师问到“你了解微服务吗”“你知道自动配置原理吗”SpringBoot 项目能让你顺理成章地延伸出 SpringCloud、分布式、自动装配等话题。相比之下如果还在用 SSH 做毕设技术上确实显得滞后了。2.2 前端方案与数据访问层选型搭配很多同学纠结前端选什么。这里我直接把两种主流方案的优劣摆出来对比一下大家按自己的精力选。方案技术栈优势劣势适合人群前后端分离Vue3 Element Plus Axios交互体验好界面美观答辩演示效果佳需要处理跨域、接口联调工程量稍大有一定前端基础、时间充裕服务端渲染Thymeleaf Bootstrap单应用部署简单不用考虑跨域学起来快页面交互受限大型项目后期维护麻烦前端薄弱、追求快速完成从毕业设计实际效果看我更倾向于前后端分离。并不是说 Thymeleaf 不好而是现在图书销售类毕设要展示的图片多、购物车交互频繁Vue 的响应式数据绑定写起来更顺手Element Plus 自带的表格、表单、弹窗组件能让后台管理界面看起来专业很多。当然如果你时间紧张选 Thymeleaf 也能做出不错的效果核心逻辑是一样的。数据访问层我用 MyBatis-Plus原因很简单单表 CRUD 它自带方法就能搞定复杂查询用 LambdaQueryWrapper 写条件非常优雅配合分页插件后基本不需要手写 SQL。有人会推荐 Spring Data JPA但 JPA 对数据库表结构有很强的侵入性映射关系绕来绕去对新人并不友好。MyBatis-Plus 保留了 SQL 的控制权出问题也好排查更适合毕设这种需要“快速且可控”的开发场景。版本上我建议 SpringBoot 2.7.x MyBatis-Plus 3.5.x稳定成熟网上资料最多遇到问题基本都能搜到答案。3. 系统设计与数据库建模3.1 功能模块划分与权限控制系统功能模块我从实际开发角度拆分如下用户端注册登录、首页推荐、图书列表、分类筛选、关键词搜索、图书详情、收藏、购物车管理、订单确认、模拟支付、个人中心、订单管理、图书评论。管理端后台登录、图书管理增删改查、上下架、封面上传、分类管理、订单管理发货、取消、查看明细、用户管理禁用、启用、评论审核、销售统计。权限控制部分用户端用 JWT 令牌管理员接口同样用 JWT 但额外校验角色标识。登录拦截器注册时放行路径包括登录注册接口、图书列表、图书详情、图片访问等公开资源其余以/api/user/**、/api/admin/**开头接口一律校验令牌。这里有个容易被忽略的地方图书封面图片上传后要能公开访问所以图片静态映射路径必须加入放行名单否则前端页面始终加载不出图片。3.2 核心数据库表结构与字段设计数据库是整个项目的地基表结构设计好了后期很多功能都是顺势而为。以下是我在项目中实际使用的核心表清单表名作用关键字段说明user用户信息id、username、password、nickname、avatar、phone、address、statuscategory图书分类id、name、parent_id、sortbook图书信息id、name、author、isbn、publisher、category_id、cover、price、stock、sales、status、descriptioncart_item购物车项id、user_id、book_id、quantity、checkedorders订单主表id、order_no、user_id、total_amount、status、consignee、phone、address、pay_time、create_timeorder_item订单明细id、order_id、book_id、book_name、book_cover、price、quantity、subtotalcomment图书评论id、user_id、book_id、content、rating、create_time其中订单相关的两张表拆成“主表 明细表”是必须的因为一个订单可能包含多本图书如果合并成一张表会导致大量重复的订单信息和冗余数据统计订单数量、金额时极其痛苦。3.3 字段类型与设计细节的经验之谈这里分享一些踩过坑后得出的设计经验直接照着用能省不少事金额字段一律用BigDecimal而不是double或float。浮点数在计算金额时会产生精度误差比如 0.1 0.2 在二进制里并不等于 0.3。图书价格总价、订单金额都要用 BigDecimal并且在 Java 层使用BigDecimal.valueOf()传入字符串形式的值。密码字段存储的是 BCrypt 加密后的哈希串长度约 60 位所以 varchar 要给足 64 或 128别只给 20 位。库存与销量采用冗余设计book 表里同时有stock和sales下单成功时库存减 N、销量加 N这两个操作放在同一个事务里避免数字对不上。订单号order_no不用自增 id 充当因为外部可见的订单号不能泄露业务量。我用的方案是yyyyMMddHHmmss 递增序列 随机数保证并发下基本不重复。逻辑删除与物理删除图书被删除后历史订单明细里还需要保留快照信息所以图书表用逻辑删除字段deleted而购物车记录在订单创建后直接物理删除因为它是临时数据。每张表都加上create_time和update_time使用 MyBatis-Plus 的字段自动填充功能插入和更新时自动赋值省去手动 set 的一堆重复代码。4. 核心功能实现与关键逻辑4.1 登录态管理JWT 拦截器设计用户登录成功后服务端生成 JWT 令牌返回给前端前端存储在 localStorage 中后续每个请求在请求头携带Authorization: Bearer token。后端拦截器从请求头解析令牌验证通过后将用户 ID 存入请求上下文供 Controller 使用。生成令牌的代码核心如下String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();注意签名密钥要保存在服务端配置里不要硬编码在前端代码中。拦截器里解析失败时统一返回 401 状态码和错误信息前端 Axios 响应拦截里对 401 做统一跳转登录页处理这样用户登录过期时体验是连贯的。选 JWT 而不是 Session 的理由在答辩时可以这样回答服务端状态无状态化适合前后端分离架构后端可以水平扩展而不需要共享 Session 存储。不过这里也有一个隐藏的坑JWT 一旦签发在过期前无法主动失效所以如果你做了“管理员禁用用户”功能用户仍然能凭旧令牌访问接口。解决办法是在拦截器里再查一次用户状态判断是否被禁用或者引入 Redis 黑名单机制毕设做到前一步已经够用。4.2 购物车加购与订单事务实现购物车加购逻辑要考虑到“同一个用户重复添加同一本书”的情况。标准的实现是先按user_id book_id查购物车表如果记录已存在数量加 1如果不存在插入新记录数量为 1。这块代码量不大但容易忽略对图书状态的检查——图书已下架或被删除时不能加入购物车前端要提示“图书已下架”。下单是整个系统中事务性最强的操作一定不能拆成多条独立更新语句。我的核心流程如下Transactional(rollbackFor Exception.class) public String createOrder(Long userId, ListCartItemVO cartItems, OrderRequest request) { // 1. 生成订单号 String orderNo generateOrderNo(); // 2. 计算订单总金额逐项读取图书价格用数据库价格而不是前端传的价格 BigDecimal totalAmount calculateTotalAmount(cartItems); // 3. 插入订单主表状态为待支付 Orders order buildOrder(orderNo, userId, totalAmount, request); orderMapper.insert(order); // 4. 插入订单明细 for (CartItemVO item : cartItems) { orderItemMapper.insert(buildOrderItem(order.getId(), item)); // 5. 扣减库存条件更新防止超卖 int updated bookMapper.deductStock(item.getBookId(), item.getQuantity()); if (updated 0) { throw new BusinessException(图书库存不足); } bookMapper.increaseSales(item.getBookId(), item.getQuantity()); } // 6. 清空购物车中已结算的项 cartItemMapper.deleteByUserIdAndBookIds(userId, cartItems); return orderNo; }这里最核心的两点需要重点理解。第一价格为什么不用前端传的值前端页面的价格可以被用户手动修改如果把金额直接按前端传入值计算整个订单金额体系就崩溃了。正确做法是后端根据购物车项里的 book_id 重新查询数据库价格再计算总价。第二库存扣减为什么用条件更新如果不加条件判断并发请求同时下单时可能出现库存扣成负数的情况。UPDATE book SET stock stock - #{quantity} WHERE id #{bookId} AND stock #{quantity}这种写法利用数据库行锁确保扣减安全配合事务注解能避免最基本的超卖问题。答辩时能讲清楚这个细节比泛泛而谈“我用事务保证一致性”要有说服力得多。4.3 图书检索、分类筛选与分页实现图书列表页是用户浏览的主要入口要做到多条件组合查询。搜索关键词、分类 ID、价格区间、上架状态、排序规则这些条件用 MyBatis-Plus 的 LambdaQueryWrapper 可以写得很舒服LambdaQueryWrapperBook wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), Book::getName, keyword) .eq(categoryId ! null, Book::getCategoryId, categoryId) .eq(Book::getStatus, 1) .orderByDesc(Book::getCreateTime);分页插件配置好后直接调用Page对象执行查询即可。这里提醒一句排序和分页写在一起时排序字段一定要加在 wrapper 上而不是查询后再用 Java 手动排序否则数据量稍大一点就会出现性能问题而且分页结果顺序不稳定。4.4 后台数据统计与管理功能要点后台除了基础 CRUD最值得花精力做的是销售统计模块。一张订单明细表就能支撑不少统计口径按日统计订单数、按图书分组统计销量 Top10、按分类统计销售额占比。用 MyBatis 自定义 SQL 查询时可以直接返回 Map 或实体对象前端用图表库渲染成柱状图、饼图演示效果非常好。图书封面上传也是毕设中比较常见的功能点。上传后的文件不要直接存数据库的 BLOB 字段而是保存到服务器磁盘的指定目录数据库中只存相对路径。然后配置一个静态资源映射把/upload/**路径映射到磁盘目录前端就能直接通过 URL 访问图片。我见过不少同学把图片渲染不出来归咎于跨域查了半天发现只是路径映射没配置。5. 实操过程与踩坑记录5.1 环境准备与项目启动配置开发环境推荐采用以下组合JDK 8 或 JDK 11、Maven 3.6、MySQL 5.7 或 8.0、Redis非必需、IDEA。项目创建时直接使用 Spring Initializr 生成基础骨架勾选 Web、MySQL、MyBatis、Validation 等依赖。application.yml里有几个配置项我单独提出来说因为这些都是新手容易踩坑的地方spring: datasource: url: jdbc:mysql://localhost:3306/bookstore?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password servlet: multipart: max-file-size: 10MB max-request-size: 10MB数据库连接串里的serverTimezoneAsia/Shanghai一定要加否则 MySQL 8.x 默认时区与本地不一致时会报The server time zone value异常。characterEncodingutf8mb4保证中文和特殊字符比如表情不会乱码。文件上传大小限制如果不配默认只有 1MB图书封面稍大一点就会上传失败这个坑很多人要遇到过一次才会想起来。5.2 高频问题与排查思路实录我在实践过程中总结了一张问题排查表基本都是新手做到后半段容易卡住的地方问题现象可能原因排查与解决方法前端请求后端接口报 404请求路径或请求方法不匹配查看控制台映射日志检查 RequestMapping 路径与方法类型登录后刷新页面又回到登录页JWT 未保存或路由守卫判断逻辑错误检查前端登录成功后是否存储 tokenAxios 请求头是否携带 token图书封面图片加载不出来静态资源映射未配置或图片路径前多斜杠检查 ResourceHandler 注册确认相对路径与拼接后的完整路径下单成功但库存没有减少事务未生效或扣减条件写错检查 Transactional 是否加在 public 方法上检查 WHERE 条件是否包含库存判断分页后数据总数为 0分页插件未配置或 Page 参数顺序不对确认 MyBatis-Plus 分页拦截器已注册注意 current 与 size 参数上传文件后无法访问Multipart 配置缺失或静态映射错误在配置类中重写 addResourceHandlers并确认本地目录存在其实排查思路最核心的一条是“先确认接口层再确认页面层”。比如前端报错先用 Postman 直接调后端接口确认后端没问题后再去查前端代码能省掉大量互相怀疑的时间。项目做到后期绝大多数问题都集中在路径错误、参数没传对、响应结构对不上这三种情况。5.3 数据安全与一致性注意事项图书销售系统虽然只是毕设但代码习惯要往工程化标准靠这里强调几条硬性规范密码绝不存明文使用 BCryptPasswordEncoder 加密。登录校验时调用matches()方法而不是直接比对字符串。接口层做参数校验用 Validated 注解配合 NotNull、Min 等注解避免前端传来的数量为负数或为空。不要裸写 SQL 字符串拼接。用 MyBatis 的 #{} 预编译形式能有效防止 SQL 注入。后端接口要做统一的异常处理用 RestControllerAdvice 捕获业务异常和全局异常返回统一结构如{code: 500, message: 库存不足}而不是直接把堆栈信息抛给前端。金额计算相关的代码统一收敛到一个工具类方法里禁止在 Controller 里散落 BigDecimal 运算方便统一维护精度规则。6. 毕业设计展示与答辩准备6.1 十分钟演示路线设计答辩演示时千万不能上来就登录管理员后台一顿操作那是很多同学容易踩的坑。一个优秀的演示顺序应该模拟真实用户的购物路径从网站首页开始展示轮播图、推荐图书区域然后执行一次搜索演示分类筛选进入详情页加入购物车再登录账号走完结算流程。管理员端放到后半程展示重点讲订单发货处理、图书上下架和销售统计图表。演示前一定要准备几组“化妆数据”至少 20 本图书分布在 5 个以上分类中下单账号里预留几张不同类型状态的订单比如待支付、已发货、已完成各一单。这样可以随时切到账单项下展示不同状态下的界面变化。我第一次演示时吃过亏提前只造了一本数据结果搜索和分类筛选看起来跟没实现一样。数据是功能的放大镜数据越多越充分系统显得越完整。6.2 答辩常见问题与应答思路答辩老师通常会围绕技术选型、数据库设计、核心逻辑三个方向提问。我把高频问题和推荐回答方式整理成下表问题普通回答加分回答为什么选 SpringBoot好用、写代码快自动配置降低了集成成本内置容器便于独立部署生态适合快速迭代同时为以后扩展微服务打基础订单表为什么拆成主表和明细表方便存储多个商品符合数据库范式减少冗余每个订单关联多条商品信息明细表还能独立做销量统计主表专注于订单整体状态如何防止库存超卖下单时扣库存事务内执行条件更新UPDATE book SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}数据库行锁保证并发安全JWT 和 Session 有哪些区别JWT 无状态Session 有状态JWT 不需要服务端存储适合分布式场景但无法主动失效所以对于禁用的极端场景需要搭配黑名单或状态校验系统有哪些可扩展的地方还没想过可以引入 Redis 缓存热门图书、基于用户行为的推荐算法、订单超时自动取消的定时任务、第三方接口接入还有一个答辩时的禁忌千万不要说“这里我用了网上找的模板”“这个功能很难我当时没实现”。哪怕功能确实简单也要把它的设计意图讲出来。毕设答辩的核心不是证明你做出了多么高难度的系统而是证明你理解自己在做什么知道每个设计决策背后的原因。把上面这几个问题想透答辩就已经很稳了。最后再分享一个小技巧论文和项目展示里画清楚业务流程图比贴大段代码更打动人。你可以用 Word 里自带的图形工具画一张简单的用户下单时序图把“加购→提交订单→扣库存→生成订单→模拟支付→更新状态”这条线标出来答辩时先讲业务图再讲代码实现效果会好非常多。我见过不少代码写得不错的同学因为演示顺序混乱、讲解没有主线最后分数平平真的很可惜。
1. 项目概述与核心需求拆解1.1 为什么图书销售系统是毕业设计的“经典样本”在线图然销售系统这个题目在计算机毕业设计选题里已经算得上“常青树”了。选它的人多不是因为它容易混日子而是因为这个业务场景能覆盖毕业设计里几乎所有的核心考核点前后端数据交互、用户权限控制、商品多维检索、购物车状态管理、订单状态流转、数据库事务一致性。一套做下来基本把 Web 开发主线的知识都过了一遍而且书这个商品天然适合在线销售——它有封面、有分类、有库存、有单价数据特征丰富做出来的界面和演示效果都很好看不会像“员工管理系统”那样干巴巴的。很多人担心这个题目太普通答辩时会被老师挑刺。我的看法恰恰相反题目普通不代表做不出亮点。同样的图书销售系统有人只做了 CRUD有人做出了订单超时取消、销量榜单、用户行为记录、图片上传预览、数据可视化报表。差距不在题目而在你对业务闭环的理解和执行深度。这个项目本质上是“电商系统的图书垂直版”只要电商核心链路完整它就是一套合格的毕业设计。1.2 系统角色与核心业务流程在线图然销售系统主要涉及两类角色前台用户和后台管理员各自的工作流清晰分开这也是为什么它适合作为面试或答辩演示项目——角色边界越清楚越能体现出系统设计的模块化意识。前台用户的核心路径是注册登录 → 浏览首页推荐 → 搜索或按分类筛选图书 → 进入详情页 → 加入购物车 → 结算生成订单 → 模拟支付 → 查看订单状态 → 确认收货 → 发表评论。这条路径覆盖了商品流和信息流的完整循环。后台管理员的核心路径是图书上架与维护 → 分类管理 → 处理用户订单发货、取消 → 用户管理 → 查看销售统计。订单状态我建议用一组固定状态码管理待支付、已支付待发货、已发货、已完成、已取消不要用字符串散着写否则后面统计时会非常痛苦。这里有一个容易被忽略的设计点订单状态机。很多初学同学把订单状态当成一个普通字段想改就改结果出现“已取消的订单还能发货”这种笑话。我建议在代码里用一个状态流转常量类统一管理并给每个状态定义允许跳转的方向比如只有待支付能转已取消待支付能转已支付已支付才能转已发货。这个设计在答辩时讲出来是明显的加分项。2. 技术选型为什么是SpringBoot2.1 SpringBoot相比传统SSM/SSH的选型优势如果是五六年前做这类毕设的主流方案还是 SSMSpring SpringMVC MyBatis需要手写大量 XML 配置光整合配置文件就能劝退一批人。现在用 SpringBoot最直观的感受是“少写一半配置文件”。SpringBoot 的自动配置机制把常用的数据源、事务管理器、Web MVC 配置都内置好了你只需要在application.yml里写上数据库连接和少量个性化配置项目就能跑起来。更关键的是SpringBoot 的生态成熟度远高于传统 SSM。比如做分页MyBatis-Plus 官方提供了分页插件一行配置就能用做登录拦截SpringBoot 的 HandlerInterceptor 配合注册配置类几行代码搞定做单元测试spring-boot-starter-test直接拉入场景启动器。对于毕业设计这种工期紧张、一个人要搞定前后端所有环节的场景SpringBoot 能把开发期的时间成本压缩到传统配置方式的三分之一以下。从答辩角度讲SpringBoot 也是目前企业主流技术栈的基础。如果面试官或答辩老师问到“你了解微服务吗”“你知道自动配置原理吗”SpringBoot 项目能让你顺理成章地延伸出 SpringCloud、分布式、自动装配等话题。相比之下如果还在用 SSH 做毕设技术上确实显得滞后了。2.2 前端方案与数据访问层选型搭配很多同学纠结前端选什么。这里我直接把两种主流方案的优劣摆出来对比一下大家按自己的精力选。方案技术栈优势劣势适合人群前后端分离Vue3 Element Plus Axios交互体验好界面美观答辩演示效果佳需要处理跨域、接口联调工程量稍大有一定前端基础、时间充裕服务端渲染Thymeleaf Bootstrap单应用部署简单不用考虑跨域学起来快页面交互受限大型项目后期维护麻烦前端薄弱、追求快速完成从毕业设计实际效果看我更倾向于前后端分离。并不是说 Thymeleaf 不好而是现在图书销售类毕设要展示的图片多、购物车交互频繁Vue 的响应式数据绑定写起来更顺手Element Plus 自带的表格、表单、弹窗组件能让后台管理界面看起来专业很多。当然如果你时间紧张选 Thymeleaf 也能做出不错的效果核心逻辑是一样的。数据访问层我用 MyBatis-Plus原因很简单单表 CRUD 它自带方法就能搞定复杂查询用 LambdaQueryWrapper 写条件非常优雅配合分页插件后基本不需要手写 SQL。有人会推荐 Spring Data JPA但 JPA 对数据库表结构有很强的侵入性映射关系绕来绕去对新人并不友好。MyBatis-Plus 保留了 SQL 的控制权出问题也好排查更适合毕设这种需要“快速且可控”的开发场景。版本上我建议 SpringBoot 2.7.x MyBatis-Plus 3.5.x稳定成熟网上资料最多遇到问题基本都能搜到答案。3. 系统设计与数据库建模3.1 功能模块划分与权限控制系统功能模块我从实际开发角度拆分如下用户端注册登录、首页推荐、图书列表、分类筛选、关键词搜索、图书详情、收藏、购物车管理、订单确认、模拟支付、个人中心、订单管理、图书评论。管理端后台登录、图书管理增删改查、上下架、封面上传、分类管理、订单管理发货、取消、查看明细、用户管理禁用、启用、评论审核、销售统计。权限控制部分用户端用 JWT 令牌管理员接口同样用 JWT 但额外校验角色标识。登录拦截器注册时放行路径包括登录注册接口、图书列表、图书详情、图片访问等公开资源其余以/api/user/**、/api/admin/**开头接口一律校验令牌。这里有个容易被忽略的地方图书封面图片上传后要能公开访问所以图片静态映射路径必须加入放行名单否则前端页面始终加载不出图片。3.2 核心数据库表结构与字段设计数据库是整个项目的地基表结构设计好了后期很多功能都是顺势而为。以下是我在项目中实际使用的核心表清单表名作用关键字段说明user用户信息id、username、password、nickname、avatar、phone、address、statuscategory图书分类id、name、parent_id、sortbook图书信息id、name、author、isbn、publisher、category_id、cover、price、stock、sales、status、descriptioncart_item购物车项id、user_id、book_id、quantity、checkedorders订单主表id、order_no、user_id、total_amount、status、consignee、phone、address、pay_time、create_timeorder_item订单明细id、order_id、book_id、book_name、book_cover、price、quantity、subtotalcomment图书评论id、user_id、book_id、content、rating、create_time其中订单相关的两张表拆成“主表 明细表”是必须的因为一个订单可能包含多本图书如果合并成一张表会导致大量重复的订单信息和冗余数据统计订单数量、金额时极其痛苦。3.3 字段类型与设计细节的经验之谈这里分享一些踩过坑后得出的设计经验直接照着用能省不少事金额字段一律用BigDecimal而不是double或float。浮点数在计算金额时会产生精度误差比如 0.1 0.2 在二进制里并不等于 0.3。图书价格总价、订单金额都要用 BigDecimal并且在 Java 层使用BigDecimal.valueOf()传入字符串形式的值。密码字段存储的是 BCrypt 加密后的哈希串长度约 60 位所以 varchar 要给足 64 或 128别只给 20 位。库存与销量采用冗余设计book 表里同时有stock和sales下单成功时库存减 N、销量加 N这两个操作放在同一个事务里避免数字对不上。订单号order_no不用自增 id 充当因为外部可见的订单号不能泄露业务量。我用的方案是yyyyMMddHHmmss 递增序列 随机数保证并发下基本不重复。逻辑删除与物理删除图书被删除后历史订单明细里还需要保留快照信息所以图书表用逻辑删除字段deleted而购物车记录在订单创建后直接物理删除因为它是临时数据。每张表都加上create_time和update_time使用 MyBatis-Plus 的字段自动填充功能插入和更新时自动赋值省去手动 set 的一堆重复代码。4. 核心功能实现与关键逻辑4.1 登录态管理JWT 拦截器设计用户登录成功后服务端生成 JWT 令牌返回给前端前端存储在 localStorage 中后续每个请求在请求头携带Authorization: Bearer token。后端拦截器从请求头解析令牌验证通过后将用户 ID 存入请求上下文供 Controller 使用。生成令牌的代码核心如下String token Jwts.builder() .setSubject(userId.toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();注意签名密钥要保存在服务端配置里不要硬编码在前端代码中。拦截器里解析失败时统一返回 401 状态码和错误信息前端 Axios 响应拦截里对 401 做统一跳转登录页处理这样用户登录过期时体验是连贯的。选 JWT 而不是 Session 的理由在答辩时可以这样回答服务端状态无状态化适合前后端分离架构后端可以水平扩展而不需要共享 Session 存储。不过这里也有一个隐藏的坑JWT 一旦签发在过期前无法主动失效所以如果你做了“管理员禁用用户”功能用户仍然能凭旧令牌访问接口。解决办法是在拦截器里再查一次用户状态判断是否被禁用或者引入 Redis 黑名单机制毕设做到前一步已经够用。4.2 购物车加购与订单事务实现购物车加购逻辑要考虑到“同一个用户重复添加同一本书”的情况。标准的实现是先按user_id book_id查购物车表如果记录已存在数量加 1如果不存在插入新记录数量为 1。这块代码量不大但容易忽略对图书状态的检查——图书已下架或被删除时不能加入购物车前端要提示“图书已下架”。下单是整个系统中事务性最强的操作一定不能拆成多条独立更新语句。我的核心流程如下Transactional(rollbackFor Exception.class) public String createOrder(Long userId, ListCartItemVO cartItems, OrderRequest request) { // 1. 生成订单号 String orderNo generateOrderNo(); // 2. 计算订单总金额逐项读取图书价格用数据库价格而不是前端传的价格 BigDecimal totalAmount calculateTotalAmount(cartItems); // 3. 插入订单主表状态为待支付 Orders order buildOrder(orderNo, userId, totalAmount, request); orderMapper.insert(order); // 4. 插入订单明细 for (CartItemVO item : cartItems) { orderItemMapper.insert(buildOrderItem(order.getId(), item)); // 5. 扣减库存条件更新防止超卖 int updated bookMapper.deductStock(item.getBookId(), item.getQuantity()); if (updated 0) { throw new BusinessException(图书库存不足); } bookMapper.increaseSales(item.getBookId(), item.getQuantity()); } // 6. 清空购物车中已结算的项 cartItemMapper.deleteByUserIdAndBookIds(userId, cartItems); return orderNo; }这里最核心的两点需要重点理解。第一价格为什么不用前端传的值前端页面的价格可以被用户手动修改如果把金额直接按前端传入值计算整个订单金额体系就崩溃了。正确做法是后端根据购物车项里的 book_id 重新查询数据库价格再计算总价。第二库存扣减为什么用条件更新如果不加条件判断并发请求同时下单时可能出现库存扣成负数的情况。UPDATE book SET stock stock - #{quantity} WHERE id #{bookId} AND stock #{quantity}这种写法利用数据库行锁确保扣减安全配合事务注解能避免最基本的超卖问题。答辩时能讲清楚这个细节比泛泛而谈“我用事务保证一致性”要有说服力得多。4.3 图书检索、分类筛选与分页实现图书列表页是用户浏览的主要入口要做到多条件组合查询。搜索关键词、分类 ID、价格区间、上架状态、排序规则这些条件用 MyBatis-Plus 的 LambdaQueryWrapper 可以写得很舒服LambdaQueryWrapperBook wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), Book::getName, keyword) .eq(categoryId ! null, Book::getCategoryId, categoryId) .eq(Book::getStatus, 1) .orderByDesc(Book::getCreateTime);分页插件配置好后直接调用Page对象执行查询即可。这里提醒一句排序和分页写在一起时排序字段一定要加在 wrapper 上而不是查询后再用 Java 手动排序否则数据量稍大一点就会出现性能问题而且分页结果顺序不稳定。4.4 后台数据统计与管理功能要点后台除了基础 CRUD最值得花精力做的是销售统计模块。一张订单明细表就能支撑不少统计口径按日统计订单数、按图书分组统计销量 Top10、按分类统计销售额占比。用 MyBatis 自定义 SQL 查询时可以直接返回 Map 或实体对象前端用图表库渲染成柱状图、饼图演示效果非常好。图书封面上传也是毕设中比较常见的功能点。上传后的文件不要直接存数据库的 BLOB 字段而是保存到服务器磁盘的指定目录数据库中只存相对路径。然后配置一个静态资源映射把/upload/**路径映射到磁盘目录前端就能直接通过 URL 访问图片。我见过不少同学把图片渲染不出来归咎于跨域查了半天发现只是路径映射没配置。5. 实操过程与踩坑记录5.1 环境准备与项目启动配置开发环境推荐采用以下组合JDK 8 或 JDK 11、Maven 3.6、MySQL 5.7 或 8.0、Redis非必需、IDEA。项目创建时直接使用 Spring Initializr 生成基础骨架勾选 Web、MySQL、MyBatis、Validation 等依赖。application.yml里有几个配置项我单独提出来说因为这些都是新手容易踩坑的地方spring: datasource: url: jdbc:mysql://localhost:3306/bookstore?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password servlet: multipart: max-file-size: 10MB max-request-size: 10MB数据库连接串里的serverTimezoneAsia/Shanghai一定要加否则 MySQL 8.x 默认时区与本地不一致时会报The server time zone value异常。characterEncodingutf8mb4保证中文和特殊字符比如表情不会乱码。文件上传大小限制如果不配默认只有 1MB图书封面稍大一点就会上传失败这个坑很多人要遇到过一次才会想起来。5.2 高频问题与排查思路实录我在实践过程中总结了一张问题排查表基本都是新手做到后半段容易卡住的地方问题现象可能原因排查与解决方法前端请求后端接口报 404请求路径或请求方法不匹配查看控制台映射日志检查 RequestMapping 路径与方法类型登录后刷新页面又回到登录页JWT 未保存或路由守卫判断逻辑错误检查前端登录成功后是否存储 tokenAxios 请求头是否携带 token图书封面图片加载不出来静态资源映射未配置或图片路径前多斜杠检查 ResourceHandler 注册确认相对路径与拼接后的完整路径下单成功但库存没有减少事务未生效或扣减条件写错检查 Transactional 是否加在 public 方法上检查 WHERE 条件是否包含库存判断分页后数据总数为 0分页插件未配置或 Page 参数顺序不对确认 MyBatis-Plus 分页拦截器已注册注意 current 与 size 参数上传文件后无法访问Multipart 配置缺失或静态映射错误在配置类中重写 addResourceHandlers并确认本地目录存在其实排查思路最核心的一条是“先确认接口层再确认页面层”。比如前端报错先用 Postman 直接调后端接口确认后端没问题后再去查前端代码能省掉大量互相怀疑的时间。项目做到后期绝大多数问题都集中在路径错误、参数没传对、响应结构对不上这三种情况。5.3 数据安全与一致性注意事项图书销售系统虽然只是毕设但代码习惯要往工程化标准靠这里强调几条硬性规范密码绝不存明文使用 BCryptPasswordEncoder 加密。登录校验时调用matches()方法而不是直接比对字符串。接口层做参数校验用 Validated 注解配合 NotNull、Min 等注解避免前端传来的数量为负数或为空。不要裸写 SQL 字符串拼接。用 MyBatis 的 #{} 预编译形式能有效防止 SQL 注入。后端接口要做统一的异常处理用 RestControllerAdvice 捕获业务异常和全局异常返回统一结构如{code: 500, message: 库存不足}而不是直接把堆栈信息抛给前端。金额计算相关的代码统一收敛到一个工具类方法里禁止在 Controller 里散落 BigDecimal 运算方便统一维护精度规则。6. 毕业设计展示与答辩准备6.1 十分钟演示路线设计答辩演示时千万不能上来就登录管理员后台一顿操作那是很多同学容易踩的坑。一个优秀的演示顺序应该模拟真实用户的购物路径从网站首页开始展示轮播图、推荐图书区域然后执行一次搜索演示分类筛选进入详情页加入购物车再登录账号走完结算流程。管理员端放到后半程展示重点讲订单发货处理、图书上下架和销售统计图表。演示前一定要准备几组“化妆数据”至少 20 本图书分布在 5 个以上分类中下单账号里预留几张不同类型状态的订单比如待支付、已发货、已完成各一单。这样可以随时切到账单项下展示不同状态下的界面变化。我第一次演示时吃过亏提前只造了一本数据结果搜索和分类筛选看起来跟没实现一样。数据是功能的放大镜数据越多越充分系统显得越完整。6.2 答辩常见问题与应答思路答辩老师通常会围绕技术选型、数据库设计、核心逻辑三个方向提问。我把高频问题和推荐回答方式整理成下表问题普通回答加分回答为什么选 SpringBoot好用、写代码快自动配置降低了集成成本内置容器便于独立部署生态适合快速迭代同时为以后扩展微服务打基础订单表为什么拆成主表和明细表方便存储多个商品符合数据库范式减少冗余每个订单关联多条商品信息明细表还能独立做销量统计主表专注于订单整体状态如何防止库存超卖下单时扣库存事务内执行条件更新UPDATE book SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}数据库行锁保证并发安全JWT 和 Session 有哪些区别JWT 无状态Session 有状态JWT 不需要服务端存储适合分布式场景但无法主动失效所以对于禁用的极端场景需要搭配黑名单或状态校验系统有哪些可扩展的地方还没想过可以引入 Redis 缓存热门图书、基于用户行为的推荐算法、订单超时自动取消的定时任务、第三方接口接入还有一个答辩时的禁忌千万不要说“这里我用了网上找的模板”“这个功能很难我当时没实现”。哪怕功能确实简单也要把它的设计意图讲出来。毕设答辩的核心不是证明你做出了多么高难度的系统而是证明你理解自己在做什么知道每个设计决策背后的原因。把上面这几个问题想透答辩就已经很稳了。最后再分享一个小技巧论文和项目展示里画清楚业务流程图比贴大段代码更打动人。你可以用 Word 里自带的图形工具画一张简单的用户下单时序图把“加购→提交订单→扣库存→生成订单→模拟支付→更新状态”这条线标出来答辩时先讲业务图再讲代码实现效果会好非常多。我见过不少代码写得不错的同学因为演示顺序混乱、讲解没有主线最后分数平平真的很可惜。
