SpringBoot网上书城毕设实战：需求拆解、库存并发与电子书分发

每年到这个时间点，总会有一批准备毕业设计的同学拿着一串长标题来找我，其中“基于SpringBoot的‘易书’网上书城销售平台”出现频率相当高。这个题目乍一看很长，又是“SpringBoot框架下基于Java的在线图书销售与数字化阅读服务平台”，又是“基于Java技术的互联网书店电商与电子书分发系统”，三种说法叠加在一起，很容易让人以为是一个庞大到做不完的系统。实际上拆开看就三件事：一个能卖纸质书和电子书的电商系统，一套能在线阅读的内容服务，一个给管理员管图书、管订单、管用户的运营后台。

今天我把带学生做这个项目时真实用过的方案、踩过的坑、答辩时被追问的情况全部整理出来。文章里不会堆PPT式的“项目背景”，直接讲怎么拆需求、怎么建表、怎么写核心接口、怎么应付并发和文件存储这些绕不开的问题。无论你是刚拿到题目的应届生，还是想快速搭一套商城系统做课程设计的开发者，这篇文章都应该能让你少走不少弯路。

1. 拆解标题：这个平台到底要交付什么

1.1 三个不同说法，其实是同一套系统的三层能力

“易书”的课题名在不同学校的任务书里有好几种写法，但核心始终是SpringBoot加Java的网上书城。仔细看你会发现，这三个说法分别对应三层能力：

1. 图书销售：标准的B2C电商链路，商品展示、购物车、下单、支付、订单管理。
2. 数字化阅读：电子书的在线阅读，核心是“买了之后能在哪里看、谁能看”。
3. 电子书分发：把电子书文件按订单授权给用户，而不是直接把一个下载链接丢给所有人。

我建议在设计时把它统一成“一条主线、两套商品”：主线是从注册到购买的完整商城链路，两套商品分别是纸质书SKU和电子书SKU。这样的好处非常明显——订单、购物车、库存这些模型全部复用，只需要在订单明细表里加一个商品类型字段，在支付成功后针对电子书做开通权限的差异化处理。把这一点想清楚，整个系统的结构就基本稳定了，后面写代码不会反复改表。

1.2 功能清单的优先级排序：哪些必须做，哪些可以砍

毕设最怕的不是功能少，而是时间全耗在边角料功能上。我通常建议按下面这张表来划分优先级：

很多同学看到别人做了轮播图、做了评论功能就心里发慌，其实真正打动答辩老师的永远是“主链路是否完整、是否有技术深度”。同样是一套商城，把图书库存的并发扣减讲得头头是道，远比多做几个鸡肋模块有价值。电子书在线阅读是题目的亮点，一定要保证它是通的，而且要在演示时重点展示。

1.3 角色与权限模型：别一上来就引入Spring Security

这个系统只有两类人：普通用户和管理员。权限模型用一张用户表加一个role字段就足够了，admin角色访问管理端接口，普通用户访问商城接口。毕业设计阶段我不太建议直接引入Spring Security，原因是它的配置链路长、概念多，滤器链、认证管理器、密码编码器这些东西会占用大量调试时间，而实际效果和自己写一个HandlerInterceptor差不多。

我建议用拦截器加路径前缀的方式：所有管理端接口统一放在 /admin/** 前缀下，拦截器里判断当前登录用户的role是否为管理员，不是就直接返回无权限。前端页面和用户端接口用另一套拦截逻辑，只判断是否登录。这个小设计在答辩时也能讲清楚：基于URL前缀的权限隔离，配合会话存储用户信息。如果你确实想用Spring Security，也不是不行，但请把用户表、密码加密、角色配置一次性配好，不要留半截。

2. 技术选型的理由与数据库设计

2.1 为什么一定是SpringBoot，ORM到底选哪个

这个题目点名了SpringBoot，那技术栈的大方向就定死了，没有太多纠结余地。SpringBoot的好处对毕设来说非常实在：自动配置省去大量XML配置，内嵌Tomcat让项目可以直接以jar包方式运行，Starter生态覆盖了数据库、缓存、模板引擎等几乎所有教学场景需要的组件。用JDK8加SpringBoot 2.7是我带学生时的默认组合，这套组合资料最多、踩坑案例最全，没必要为了追新去用JDK17加SpringBoot 3。

ORM层面，我强烈建议用MyBatis-Plus而不是JPA。原因有三个：

1. 单表CRUD完全不需要写SQL，由BaseMapper直接提供方法，写业务代码的速度快很多。
2. 分页插件好用，分页查询只要调Page对象，不会像原生PageHelper那样偶尔踩分页失效的坑。
3. 答辩被问“你怎么优化SQL”时，你能拿出真正写过的条件更新、复合索引、执行计划来说话，而不是含糊地说“框架自动处理”。

JPA在实体关系映射上确实省事，但一旦涉及多表联查和状态更新，调试成本比MyBatis高不少。对毕设来说，能把每条核心SQL解释清楚，本身就是加分项。

2.2 核心表结构：把状态机想清楚再建表

我见过太多同学一上来就建十几张表，结果订单状态字段存的是“未支付”“已支付”这种中文字符串，后面统计、筛选全部出问题。数据库设计阶段最重要的不是表多，而是状态字段和金额字段设计得规范。

核心表大概是这样：

• user：id、username、password（BCrypt加密存储）、nickname、avatar、role、status、create_time
• category：id、name、parent_id、sort_order
• book：id、category_id、title、author、publisher、isbn、price、cover_img、description、stock、sales、book_type、file_url、status、create_time
• shopping_cart：id、user_id、book_id、quantity、checked、add_time
• order_main：id、order_no、user_id、total_amount、status、receiver_name、receiver_phone、receiver_address、pay_time、create_time
• order_item：id、order_id、book_id、book_title、book_img、book_type、price、quantity
• reading_permission：id、user_id、book_id、order_id、expire_time、create_time

几个关键设计点：

• 订单状态用数字字典，0待支付、1已支付、2已发货、3已完成、4已取消。代码里用常量类或枚举定义，前端再用JS映射成中文显示，永远不会出现“支付成功”和“已支付”对不上的问题。
• 所有涉及金额的字段用BigDecimal，保存到数据库用DECIMAL，绝对不要用double或float，否则商品打九折后出现19.999999这种脏数据，答辩时非常尴尬。
• 图书表要区分book_type，1代表纸质书、2代表电子书、3代表两者都卖。订单明细里也要冗余一份book_type，因为下单后商品信息可能被管理员修改，订单数据不应该跟着变。
• 购物车表给(user_id, book_id)加唯一索引，这样加入购物车时可以直接走“存在则数量加一，不存在则插入”的upsert逻辑。

2.3 电子书文件到底存在哪：别把文件怼进数据库

电子书的文件格式通常有两种处理方式：一种是PDF整本文件，适合“点击在线阅读”这种场景；另一种是按章节拆成HTML片段，存在数据库里，阅读时逐章加载。对毕设的体量来说，我推荐用PDF整本文件加本地磁盘存储的方式。

千万不要把文件的二进制数据放到MySQL的BLOB字段里，数据库会迅速膨胀，查询性能也跟着下降。正确做法是：文件落在服务器磁盘的指定目录，数据库里只存相对路径，比如 ebook/2025/xxx.pdf。上传目录、封面目录和访问前缀统一写到application.yml配置里，比如这样：

upload: ebook-dir: /data/ebook cover-dir: /data/cover visit-prefix: /upload/

然后在SpringBoot的配置类里把磁盘路径映射成URL访问地址：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Value("${upload.ebook-dir}") private String ebookDir; @Value("${upload.cover-dir}") private String coverDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/ebook/**") .addResourceHandler("file:" + ebookDir + "/"); registry.addResourceHandler("/upload/cover/**") .addResourceHandler("file:" + coverDir + "/"); } }

说到“电子书分发”，我的理解是：用户购买电子书后，系统不是直接甩给他一个永久下载链接，而是给这个用户的账号开通这本书的阅读权限。用户在线阅读时，后端校验登录态和购买记录，再返回文件流。这样做既符合题目里的“数字化阅读服务平台”定位，又避免了文件URL彻底裸露在页面源码里。

3. 核心业务链路的实现细节

3.1 图书搜索、分类页与首页热销榜

首页不需要做得多花哨，常规的做法是接口返回多组数据：推荐位图书、新上架图书、热门图书，前端用Tab切换展示。热门图书最省事的算法就是按销量字段倒序取前10，这已经足够撑起“热销榜”这个功能。

搜索是必考功能，接口设计一般是这样的：

SELECT * FROM book WHERE status = 1 AND (title LIKE CONCAT('%', #{keyword}, '%') OR author LIKE CONCAT('%', #{keyword}, '%') OR isbn LIKE CONCAT('%', #{keyword}, '%')) ORDER BY sales DESC

这里要注意，LIKE的前导通配符会让索引失效，全表扫描。但毕设的数据量一般只有几千条，全表扫描也很快，答辩老师问到性能问题时，你只要说出“这里我了解LIKE前置百分号会导致索引失效，目前数据量下全表扫描可接受，如果数据量上升，我会引入全文检索或搜索引擎”这句话，就已经超出他预期了。

图书详情和分类列表这种读多写少的数据，可以考虑加一层Redis缓存。缓存key设计成 book:detail:{id}，过期时间30分钟。更新图书时主动删除对应缓存，保证下次请求回源数据库再刷缓存。这套逻辑非常简单，但“缓存穿透”“缓存雪崩”“缓存更新策略”这些词在答辩时随便挑一个讲都能展开三分钟。

3.2 购物车与订单：库存扣减是整个项目的重头戏

购物车的实现没有太多难点，核心是加购接口：

// 使用INSERT ... ON DUPLICATE KEY UPDATE，依赖user_id + book_id的唯一索引 shoppingCartMapper.insertOrUpdate(new ShoppingCart(userId, bookId, 1));

用户从购物车勾选商品进入结算页面，提交订单时后端要在一个事务里完成以下步骤：

1. 查出购物车中勾选状态的商品列表，校验商品是否仍然上架。
2. 生成订单号，格式可以是时间戳加用户ID加随机数。
3. 对每一件商品执行库存扣减，这是最关键的一步，后面第4节我会详细展开讲踩坑过程。
4. 插入主订单表和订单明细表。
5. 清空已购买的购物车记录。

模拟支付的实现就是弹一个确认支付框，前端点确认后调用支付接口，后端把订单状态从0改成1。如果订单里包含电子书，就在一个事务里同时写入reading_permission表，记录用户对哪本书拥有阅读权限。这里顺便把订单明细里的book_type取出来，判断是否需要开通阅读权限，逻辑集中在一个私有方法里，避免散落各处。

3.3 在线阅读权限的前后端校验

用户在前端点“在线阅读”，浏览器打开阅读页，请求后端的电子书文件接口。这个接口要过三道校验：

第一道是登录校验，由拦截器统一处理，未登录直接返回401。第二道是购买校验，查reading_permission表里有没有这条用户与图书的授权记录。第三道是上架校验，图书状态为下架时不能读。三道全过之后，后端才返回文件内容。

返回PDF文件时，我建议直接设置好Content-Type和Content-Disposition，用Spring的ResponseEntity把文件以资源方式写回：

@GetMapping("/ebook/{bookId}") public ResponseEntity<Resource> readEbook(@PathVariable Long bookId, HttpSession session) { // 校验省略... Resource file = fileStorage.load(ebook.getFileUrl()); return ResponseEntity.ok() .contentType(MediaType.APPLICATION_PDF) .header(HttpHeaders.CONTENT_DISPOSITION, "inline; filename=\"ebook.pdf\"") .body(file); }

注意这里不要用attachment，否则浏览器会直接下载而不是在线预览。PDF预览可以直接依赖浏览器内置的PDF查看器，前端给一个iframe加载这个接口的URL就行，不需要再引第三方PDF插件。文件大的时候用StreamingResponseBody做流式输出，避免一次把整个PDF读进内存，答辩提到这个细节也很加分。

3.4 管理端：图书上架、库存调整与订单发货

管理端功能按最简单的思路做：管理员登录后进入后台，图书列表支持新增、编辑、上下架、修改库存。这里有一条经验：修改库存的接口和用户下单扣库存的接口必须拆开，管理员操作走“增加库存”或“直接设置库存”，用户下单走“扣减库存”，二者不能混用，否则后面排查问题时很难定位是谁把库存改少了的。

上传封面时要做的三件事：

1. 校验文件类型，只允许jpg、png、jpeg，防上传exe或html。
2. 用UUID重命名文件，避免中文文件名乱码和重名覆盖。
3. 限制文件大小，SpringBoot默认上传文件大小上限是1MB，需要在配置里改：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB

订单发货逻辑就一句话：管理员把待发货订单状态从1改成2。用户端订单列表根据状态显示不同按钮——待支付订单显示“去支付”和“取消”，已发货订单显示“确认收货”，完成后可以对电子书进行阅读。

4. 实测中踩过的坑

4.1 并发下单导致库存变负数：完整的排查链路

这个坑我在带学生时几乎每届都会遇到，也是答辩老师最爱的考点。现象很简单：两个账号同时买同一本库存只剩5本的书，订单都提交成功，最后数据库里的库存变成了3甚至负数。

第一版代码很自然，几乎所有新手都会这么写：

1. 先查库存。
2. 判断库存是否大于购买数量。
3. 执行UPDATE减少库存。

问题就出在“先查后改”本身。两个请求同时查到库存为5，都认为够卖，各自减了3，库存变成-1。我先让学生把synchronized关键字加到Service方法上，发现问题依旧——原因在于synchronized锁的是当前进程内的对象，且Spring事务提交发生在方法返回之后，另一个线程可能已经通过了库存检查，读到的是事务提交前的旧快照。

后来把库存检查和扣减合并成一条带条件的UPDATE语句，问题才真正解决：

int rows = bookMapper.deductStock(bookId, quantity); if (rows == 0) { throw new BizException("库存不足"); }

对应的SQL是：

UPDATE book SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}

数据库会保证这条UPDATE是原子操作，UPDATE语句执行时会对命中行加锁，另一个请求的UPDATE必须等前一个提交或回滚，因此不会出现超卖。压测时我用多线程并发跑100次下单，库存数据始终保持正确。

这里还想多说一句：如果是更正规的商业系统，会在库存扣减前先做Redis预扣，再异步扣减数据库，但对毕设来说，一条条件UPDATE足矣。答辩时你只要把“check-then-act的竞态问题”和“原子更新”这两个词说出来，老师就知道你是真懂。

4.2 上传路径写死，部署到Linux后全部404

本地Windows跑得好好的，一部署到Linux服务器，封面图全裂了，PDF也打不开，这类问题我也见了很多次。原因十有八九是代码里写了硬编码路径，比如D:/upload/cover/xxx.jpg，或者File.separator拼接时出了问题。

正确做法是所有路径通过配置注入，数据库里只存相对路径。页面展示封面时，前端拼上访问前缀；后端保存文件时，拼上配置里的物理路径。同时注意环境差异：Windows下目录分隔符是反斜杠，Linux下是正斜杠，全部用Paths.get()或/拼接可以避免这个问题。

另一个经常翻车的地方是addResourceHandlers配了但没生效。排查顺序一般是先确认配置类是否被Spring扫描到，再确认拦截器是否把/upload/**也拦掉了。如果拦截规则写的是addPathPatterns("/**")，那静态资源默认也会进入拦截器，需要在拦截器的excludePathPatterns里放行/upload/**。

4.3 会话过期后前端“点了没反应”

系统运行一段时间后，登录状态过期，用户再点击加购，页面没有任何反应，也不跳登录页。最典型的原因不只是后端拦截了请求，更大的问题是前端AJAX回调里只处理了成功情况，压根没写401分支。

我的做法是后端拦截器对未登录的AJAX请求统一返回一个JSON格式的返回体，而不是直接302跳转HTML页面。然后在前端做一刀切的处理：所有AJAX请求完成后检查返回内容的code，等于401就清掉本地登录数据并跳转登录页。这样不管哪个接口出现会话过期，行为都一致。

更规范一点，给所有接口设计统一返回体Result<T>，包含code、msg、data三个字段。这个设计几乎所有后端同学都听过，但真正做到的少，答辩时把这个亮出来，会显得项目工程化意识很好。

4.4 订单分页越翻越慢

订单列表做到几千条数据时，第100页以后加载明显变慢。原因是分页SQL用了大偏移量的LIMIT，MySQL要把前几万行全部扫描后丢弃，只返回最后那一页。

最直接的改进是给order_main表的user_id和status建复合索引，让条件查询能快速定位。更进一步，可以把分页从LIMIT offset, size改成基于上一页最后一个ID的游标分页，类似WHERE id < lastId ORDER BY id DESC LIMIT 10。游标分页的缺点是不能再自由跳页，但订单列表本来就是从上往下翻，牺牲跳页换性能完全值得。答辩时把这两种方案对比着讲一遍，能明显看出你做过性能思考。

5. 演示与答辩的实操经验

5.1 演示脚本别从登录页开始

毕设演示时间一般只有五到十分钟，很多同学一紧张就从注册账号开始现场操作，结果验证码、邮箱激活、密码强度校验一堆环节卡住，时间全浪费了。我建议提前准备三个固定演示账号，每个账号对应一条演示路径：

路径A（用户主链路）：登录一个已存在的账号，搜索一本书，进详情，加入购物车，结算，确认支付，立即在线阅读PDF。这条链路要一气呵成，最好不要中途等页面刷新太久。

路径B（管理链路）：管理员登录，先演示图书上传和库存修改，再切换到订单管理，把路径A产生的那个订单发货。

路径C（数据亮点）：回到首页展示热销榜，进后台订单列表和统计页面，说清楚哪些表支撑了这些数据展示。

演示前把浏览器缓存清干净，账号密码写在纸上，确认端口和数据库已经启动。我见过不止一次演示现场数据库没启动，服务起不来，打开页面白屏，这种事故在答辩时非常致命。

5.2 答辩老师最爱问的几个问题

根据我近几年听到的答辩现场反馈，这个题目被问最多的问题高度集中：

• “为什么选SpringBoot？”不能只答“因为题目要求”，要说自动装配、内嵌容器、Starter生态带来的开发效率提升，再对比一下传统的SSH配置方式。
• “并发下单怎么防止超卖？”把第4节的条件UPDATE方案完整讲一遍，最好能当场画出流程。
• “电子书为什么不提供下载？”答：不是为了做不了，而是从分发管控角度考虑，在线阅读配合权限校验能有效避免文件地址被爬虫遍历；如果要扩展下载，可以用临时签名链接。
• “支付接口怎么实现的？”坦诚说是模拟支付，真实项目要接第三方支付沙箱，核心是支付回调的验签和幂等处理。
• “密码怎么存储的？”明文存储是绝对红线，说出BCrypt哈希，顺带提一句加盐机制。

这些问题每一个都对应你代码里的一个真实设计，所以写代码的时候就要留好对应痕迹，比如常量类里的订单状态枚举、Service层里那条条件UPDATE SQL，都是你回答问题的底气。

5.3 如果时间和精力还够，可以往这些方向扩展

主链路做完之后，有余力的同学可以考虑三个扩展方向，每个都能成为答辩时的亮点：

第一个是前后端分离，把页面改成Vue加接口形式，后端只提供JSON接口。成本不高，但观感提升非常明显。第二个是订单超时自动取消，用定时任务扫描超过5分钟未支付的待支付订单，回滚库存并且更新状态。如果想让方案更高级，可以提到Redis过期事件或者延迟队列。第三个是简单推荐，根据用户历史购买分类做同类推荐，不需要跑协同过滤算法，一条GROUP BY查询就能撑起来。

这三个方向都做完不现实，挑一个深挖就足够形成论文里的“系统特色”章节了。

带了几届学生做完这个题目，我最大的体会是：商城类毕设永远做不完，但真正重要的是把一条核心链路彻底打通。库存并发那一次踩坑，比写十个页面学到的东西都多；路径配置那一次404，比背一百个框架知识点都值。所以我的建议很简单：别贪多，把用户从注册、浏览、下单、支付、在线阅读这条链路做成肌肉记忆，把并发和文件存储这两个技术难点讲到老师无法追问，这个项目就算真正交卷了。