企业官网建设流程全解析

每年一到毕业设计选题季，就会有一批人被“网上书店系统”这个题目拦住。表面上看，它无非是图书的增删改查加一条订单流程；真上手之后才发现，从建表开始就有取舍：订单要不要拆主表和明细表、库存扣减用乐观锁还是条件更新、购物车存数据库还是 Redis、文件上传打包成 jar 之后为什么路径失效。这篇文章我按实际开发的顺序，把一套基于 SpringBoot 的网上书店系统从选题、技术栈、建表、核心链路到排查问题的完整思路梳理出来。它既兼容“基于 SpringBoot 的在线图书销售平台”这类常规题目，也能覆盖“数字化图书商城系统”的需求，适合准备做这个毕业设计的同学参考，也适合想快速搭一个图书商城练手的前后端开发者。

1. 为什么这个题目年年有人做，却年年有人做砸

1.1 它的业务闭环比单纯CRUD更值得做

图书是一种非常“规矩”的商品：没有尺码、颜色这种复杂的规格组合，价格波动也小，所以网上书店系统是电商类毕设里最合适的入门项目。它和图书管理系统的本质区别在于角色和流程：用户端有注册登录、浏览检索、购物车、下单支付、订单跟踪；管理端有图书上架下架、库存调整、订单发货。前后台串起来就是一条从“用户加购”到“商家发货”的完整业务闭环。

这个闭环恰好覆盖了 SpringBoot 的核心知识点：Web 路由与控制层、Service 事务管理、持久层数据操作、拦截器实现登录鉴权、Redis 做缓存、文件上传处理、Maven 打包部署。拿这套骨架去回答“你会不会 SpringBoot”，比单纯做一个增删改查的薄系统要有说服力得多。

但做砸的恰恰也是因为“完整”二字。很多人一开始雄心勃勃，什么都想加，最后订单、库存、事务这些主干却写得稀烂。毕设验收看的是主干链路是否严谨，不是功能按钮的数量。

1.2 只有一个标题时，先给自己划需求边界

如果拿到的题目只有“网上书店系统”这几个字，没有详细的正文说明，我建议把以下功能当作默认需求边界：

• 用户端：注册登录、图书分类浏览、关键词检索、图书详情、加入购物车、提交订单、模拟支付、订单列表与详情、个人中心。
• 管理端：分类管理、图书管理（含封面上传、上下架、库存调整）、订单管理（发货、取消）、用户管理。
• 可选加分项：首页轮播图、收货地址管理、用户评论、销量排行、数据统计图表。

划边界有个实用技巧：先把前两条做通，再考虑加分项。很多同学把时间花在页面上，结果项目交付时连“下单减少库存”都没做对。记住一句话：网上书店系统的灵魂不在“多漂亮”，而在“从加购到发货这条路是否走得通”。

2. 技术栈选型：不求最新，但求稳和讲得清原理

2.1 SpringBoot 和 JDK 的版本组合别乱选

我接触过的毕设项目里，因为版本问题浪费一周以上的情况经常遇到。SpringBoot 3.x 要求 JDK 17，而很多实验室机器和旧教程默认还是 JDK 8。如果自己电脑环境是 JDK 8，别硬上 SpringBoot 3.x，选择 SpringBoot 2.7.x 是最稳妥的：资料最多、踩坑文章最全、和绝大多数教程天然兼容。

另一个容易被忽略的是 Maven 仓库源。国内网络环境下，最好把 Maven 镜像配置成国内仓库源，否则第一次打包下载依赖就可能劝退一半人。还有 Lombok、MyBatis-Plus 的版本要跟 SpringBoot 2.7.x 匹配，这些细节在搭建项目时一次性配好，比写到一半再回填省事得多。

2.2 持久层选 MyBatis-Plus，是性价比最高的方案

MyBatis-Plus 是当前毕设项目里最常见的持久层方案。它的价值主要体现在三点：条件构造器让动态 SQL 不用再手写那么多 if 标签；分页插件一个配置就能用；代码生成器可以把 entity、mapper、service、controller 全套生成出来，非常适合工期紧张的场景。答辩时如果被问“为什么会用 MP”，你可以回答：它保留了 MyBatis 手写 SQL 的能力，又提供了常用 CRUD 的封装，在业务相对标准的项目中能显著减少样板代码。

如果你对原生 SQL 特别熟，也可以只用 MyBatis；如果选了 Spring Data JPA，也不是不行，但复杂查询和分页调优在现场演示时往往不容易讲清楚。毕设技术选型有一个原则：选一个你能把底层原理讲到老师点头的，而不是选一个看起来最能装的。

2.3 前端形态：前后端分离还是服务端渲染，先想清楚

网上书店系统的前端可以走两条路线：

• 前后端分离：Vue3 + Element Plus + Axios，后端只提供 JSON 接口。这套方案的视觉效果和交互体验明显更现代，演示时更出彩，代价是你要额外处理跨域、Token 传递、打包部署这些环节。
• 服务端渲染：Thymeleaf + Bootstrap + jQuery，页面由 SpringBoot 直接渲染。开发量小、部署简单、不容易出跨域问题，但页面质感相对传统。

从毕设拿分角度，我建议如果时间还剩一个月以上，优先做前后端分离；如果时间紧张且前端基础薄弱，就用 Thymeleaf 把页面做整洁，在答辩时把重点放在后端业务上。无论哪种方案，项目里的页面都要提前准备好真实数据和封面图，空页面在演示时非常减分。

2.4 缓存、登录、文件存储的基础组合

这个项目常用的配套组件我整理成了一张表：

Redis 不是必须的，但我强烈建议引入，哪怕只做验证码缓存和购物车缓存，也能让项目在“性能设计”这件事上有话可说。如果担心部署复杂度，本地装一个 Redis 就行，不需要搞集群。

3. 数据库设计：订单主表和明细表务必拆开

3.1 核心表清单：七张表覆盖完整电商闭环

网上书店系统的数据库设计，我建议按这样的表清单展开：

book 表中的 isbn 建议加唯一索引，这是图书商品天然的业务主键。price 和 stock 分别用 decimal(10,2) 和 int，售价不要用 float。分类表支持 parent_id 是为了以后扩展二级分类，如果不想做分类层级，可以直接只留一个 name 字段。

订单相关的两张表是整个数据库设计的核心。为什么不能把买过的书合并成一个 JSON 字符串塞进订单主表里？因为订单一旦生成，它对商品名称、价格、数量的记录必须是稳定且可拆分的，后续做发货明细、对账、统计都要用结构化数据。拆分主表和明细表是电商系统的标准做法，也是“设计与实现”这类毕设题目最该体现专业度的地方。

3.2 订单快照、逻辑删除、唯一索引这类细节

订单主表里一定要有“快照”概念。用户改地址、图书改价格、图书下架，都不应该影响已经生成的订单。所以 t_order 表里保存接收人姓名、电话、地址，order_item 表里保存下单那一刻的书名和成交价。很多同学把地址通过关联查询去取，一旦用户改了地址订单显示就变了，现场演示时非常尴尬。

所有业务表建议加上 created_time、updated_time、deleted 三个字段，前两个可以用 MyBatis-Plus 的 MetaObjectHandler 自动填充，deleted 用逻辑删除标注。逻辑删除的意义是：订单、用户这类数据不应该真删，否则数据统计和追溯会出问题。但要注意，加了 deleted 字段后，查询要记得统一带上 deleted=0 的条件，MP 的 @TableLogic 会自动处理。

唯一索引方面，cart 表加 user_id + book_id 联合唯一索引，可以防止用户重复加购同一本书导致出现两行脏数据；t_order 表给 order_no 加唯一索引，下单时万一重复插入也能兜底。

3.3 订单状态机：把状态流转提前定义清楚

订单状态的流转应该在建表时就定义清楚，不要写在代码里临时拍脑袋。典型的状态机是这样的：

• 0：待付款，下单成功创建。
• 1：已付款，模拟支付或真实支付成功后进入。
• 2：已发货，管理端点击发货后进入。
• 3：已完成，用户确认收货或系统自动确认后进入。
• 4：已取消，用户待付款状态下取消，或超时未付款取消。

能发生的流转是：0 到 1、0 到 4、1 到 2、2 到 3。其他跳跃都是非法状态。建议在代码里定义一个 OrderStatus 枚举类，把每个状态的含义和允许的流转写清楚，而不是到处散落魔法数字。这样做的好处是，答辩时老师问“订单状态怎么管理”，你可以直接讲出状态机的设计。

3.4 一个很容易踩的坑：order 是 MySQL 保留字

如果你直接写 CREATE TABLE order，等待你的会是语法报错：order 是 MySQL 的保留关键字，用于 ORDER BY 语法。处理办法有两个：表名起成 t_order 或者 orders。我见过有人在这里栽一次，然后花一小时到处找原因，最终只是改了个表名。这个教训很常见，所以我在设计阶段就统一用 t_order 作为订单主表名。

4. 核心业务链路：从登录鉴权到库存扣减的完整实现

4.1 登录态：JWT + 拦截器 + ThreadLocal 的固定组合

前后端分离项目，登录态我推荐用 JWT 加拦截器方案。用户登录成功后，后端签发一个带 userId 和角色信息的 token，前端每次请求在 Authorization 头带上 token，后端拦截器在请求进入 Controller 之前校验 token 并解析出当前用户。

拦截器需要注意两件事。第一，只拦截 HandlerMethod，放行静态资源和预检请求；第二，维护一个白名单，登录、注册、图书列表、图书详情这些不需要鉴权的接口放行，其余接口必须带 token。解析出的用户信息可以放到 ThreadLocal 里，写一个 UserContext 工具类，这样之后的 Controller 和 Service 不需要反复把 userId 当成参数传来传去，下单时直接 UserContext.getUserId() 就能拿到当前用户。

这里有个经验：不要在拦截器里把验证逻辑写得太重。token 的生成和校验封装进 JwtUtil，拦截器只做一件事——没这个 token 就返回 401，有就解析并放行。这样职责清晰，排查问题时也好下手。

4.2 图书检索：条件构造器加物理分页

用户端和管理端都会用到图书查询。用 MyBatis-Plus 的 LambdaQueryWrapper 写动态条件非常舒服：

LambdaQueryWrapper<Book> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StringUtils.hasText(keyword), Book::getTitle, keyword) .eq(categoryId != null, Book::getCategoryId, categoryId) .ge(minPrice != null, Book::getPrice, minPrice) .le(maxPrice != null, Book::getPrice, maxPrice) .eq(Book::getStatus, 1) .orderByDesc(Book::getSales);

分页直接配置 PaginationInnerInterceptor 后，用 MP 自带的分页方法返回 Page 对象，底层会生成 LIMIT 语句，是物理分页而不是把整表查出来内存截断。这部分是答辩常客，建议把“为什么用条件构造器代替手写 if 拼接”和“分页插件原理”两个点提前想好。

4.3 购物车：数据库表还是 Redis Hash，各有什么说法

购物车有两种常见实现。一种是直接建 cart 表，用户加购就是增删改查，简单直观；另一种是把购物车放到 Redis 的 Hash 结构里，以 cart:user:1001 为 key，field 是 bookId，value 是数量，过期时间可以设置比如 30 天。前者实现简单、逻辑大家都懂；后者读写更快、能体现技术水平，但要做持久化策略和库存联动。

我建议不用二选一到底：如果想求稳，做数据库表版本；如果想让项目有亮点，用 Redis Hash 并把“Redis 购物车如何与数据库库存保持一致”作为答辩预备题。还有一个折中做法：购物车存数据库，但把热点图书的详情缓存到 Redis，这样兼顾稳定性与性能话题。

4.4 下单事务：库存扣减为什么必须用条件更新

下单是网上书店系统最核心的方法，涉及校验图书状态、计算总金额、写订单主表、写订单明细、扣减库存、清空购物车多个步骤，必须包在一个事务里：

@Transactional(rollbackFor = Exception.class) public Long createOrder(Long userId, List<CartItemVO> items, Address address) { // 1. 生成订单号并构建 t_order // 2. 遍历 items，逐个校验图书存在、上架、库存充足 // 3. 执行库存扣减 SQL // 4. 写入 order_item 明细快照 // 5. 删除购物车对应条目 return orderId; }

库存扣减这里，最典型的错误是“先查库存再判断再更新”：

Book book = bookMapper.selectById(bookId); if (book.getStock() < quantity) { throw new BusinessException("库存不足"); } bookMapper.updateStock(bookId, book.getStock() - quantity);

这段代码在并发下会超卖：两个请求同时读到库存为 1，都判断库存充足，都去更新，最后库存变成负数。正确做法是把扣减条件写进 SQL，让它成为原子操作：

UPDATE book SET stock = stock - #{quantity}, sales = sales + #{quantity} WHERE id = #{bookId} AND stock >= #{quantity} AND status = 1

如果 UPDATE 影响行数为 0，说明库存不足或图书已下架，直接抛异常让事务回滚。价格问题也要注意：下单金额必须以数据库当前价格为准，不能信任前端传上来的价格。理想做法是下单时重新查库，把 book 表里的最新价格写入明细快照。

4.5 支付模块：先做模拟，再留接口升级

支付对毕设来说是个既关键又敏感的环节。真实对接支付网关需要商户资质，不适合个人毕设，所以大多数同学用模拟支付：下单后订单状态为待付款，页面展示一个“模拟支付成功”的按钮，点击后调用后端接口，把订单状态改成已付款并记录支付时间。

为了让项目更有“工程感”，可以把支付动作抽象成 PaymentService 接口，当前只实现 MockPaymentServiceImpl，在接口注释里写清楚后续可以替换为真实支付网关的沙箱模式。这样答辩时你可以说：支付模块按真实电商系统的结构预留了扩展点，毕设场景用模拟实现，不影响业务链路验证。这样既避免了资质问题，又展示了设计思维。

5. 开发中真实遇到的五个高频问题排查

5.1 上传的图片 404：从本地路径到 jar 包路径的断裂

图书封面是网上书店系统最直观的素材，但图片上传几乎是出现频率最高的返工点。在 IDE 里本地跑没问题，部署成 jar 之后图片全部 404，原因很简单：本地写的是绝对路径比如 D:/upload/，而 jar 在服务器上运行，这个路径可能不存在；就算存在，容器里的工作目录和 IDE 里的也不一样。解决办法是：把上传根目录配置到 application.yml 里，然后用 WebMvcConfigurer 把磁盘目录映射成 /images/** 的虚拟访问路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/images/**") .addResourceLocations("file:" + uploadPath + "/"); } }

数据库里只存相对路径 /images/xxxx.jpg，页面上用相对路径访问，这样无论本地还是服务器，只要 uploadPath 配置正确，图片就能正常回显。

5.2 LocalDateTime 返回给前端变成一串数字

这个坑几乎每个 SpringBoot 项目都会遇到。实体里用了 LocalDateTime，接口返回给前端时，Jackson 默认序列化成类似 [2025, 12, 3, 14, 20, 30] 的数组，前端拿不到期望的 “2025-12-03 14:20:30” 字符串。解决办法是全局配置统一日期格式：

spring.jackson.date-format=yyyy-MM-dd HH:mm:ss spring.jackson.time-zone=GMT+8

或者给时间字段加 @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。建议用全局配置，避免每个字段到处加注解。

5.3 拦截器把静态资源和预检请求都拦了

加了 JWT 拦截器之后，很可能出现这种问题：页面能打开，但图片和 CSS 都不显示，前端一调试发现静态资源请求被拦截器拦下来返回 401。处理办法是拦截器里先判断 handler 是不是 HandlerMethod，不是就直接放行；同时在白名单里把静态资源目录、登录注册接口、上传文件访问路径全部加进去。如果是前后端分离，还要注意 OPTIONS 预检请求必须放行，否则跨域请求直接失败：

if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; }

5.4 两个人同时买最后一本书，库存变成负数

我在 4.4 小节提过条件更新，这里补一个完整的排查思路。假设一本书库存只剩 1，两个用户同时点击购买。如果代码是先查库存再判断再更新，两个请求可能同时读到库存为 1，都通过判断，最后库存变成负数。这种情况不用上分布式锁，在单库单表的前提下，用一条带条件的 UPDATE 就能解决：让数据库自己去判断当前库存是否足够。讲清楚这个问题的本质，其实是讲清楚了“并发下的竞态条件”：check 和 act 之间必须是一个原子操作。

如果老师继续追问高并发场景怎么办，你可以这样回答方向：加乐观锁版本号字段、用 Redis 预扣库存、把下单操作放进消息队列削峰。毕设阶段把条件更新讲透就已经达标，后面的属于扩展话题。

5.5 @Transactional 不生效：三个典型的误用

事务注释不起作用，我排查过很多次，高频原因有三个：一是同类内部方法调用，this.createOrder 内部的 this.deductStock 被调用，而 deductStock 上的 @Transactional 不会被代理感知，只有从外部传入的调用才会走代理对象；二是 @Transactional 加在非 public 方法上，Spring 默认只能代理 public 方法；三是异常被 try-catch 吞掉，事务感知不到异常就不会回滚。

建议是：事务只放在 public 的 Service 方法上，并且不要用 catch 吞掉业务异常，要么继续向上抛，要么先记录日志再重新抛出。想验证事务是否生效，最简单的方法是让扣减库存后故意抛一个 RuntimeException，看订单是否被回滚。

6. 演示与答辩：把工作量讲出来比埋头赶工更重要

6.1 五分钟演示脚本：从注册到确认收货跑通一次

答辩演示最忌讳临场现点、现找数据。我的做法是准备一套完整的演示脚本，流程固定为：

1. 打开首页展示轮播图和分类导航；
2. 注册一个新账号并登录；
3. 按分类找到一本书，进入详情页；
4. 加入购物车，加购另一本书，进购物车改数量；
5. 提交订单、填写收货地址、模拟支付；
6. 切到管理端登录，查订单、点击发货；
7. 回到用户端确认收货，订单完成。

全程控制在 5 到 8 分钟。数据库里提前塞好足够的分类、图书、封面图和一条已发货订单，防止现场临时造数据。另外最好准备一个异常演示：把某本书库存改成 0，然后演示加购或下单时出现“库存不足”的提示，这比一路顺畅更能体现系统考虑到了边界情况。

6.2 答辩高频问题与回答思路

老师对网上书店系统最常问的几个问题，我整理了一套回答思路：

回答原则只有一个：不要背概念，结合自己项目里的具体场景说。比如“我的库存是在 createOrder 这个事务方法里，通过一条条件 UPDATE 解决的”，这句话比十句理论都有说服力。

6.3 交材料之前的最后检查

最后提交之前，一定要在干净环境里验证一遍：数据库脚本能不能从零执行、项目能不能按 README 里的步骤启动、账号密码和演示数据是否齐全。很多毕业设计的代码本身没有问题，输在环境依赖写不清楚。最好把 SQL 初始化脚本放在项目根目录的 sql 文件夹，把启动步骤写进 README，把核心接口的调用方式用简单文档或截图说明。这样无论是老师检查还是后续部署，都能快速上手。

我更倾向建议：演示前把整个项目关机重启一次，按 README 走一遍。这个动作能暴露绝大多数隐藏问题，比任何代码 review 都直接。

最后说点实际的。我见过不少人在这个项目上花几个月，最后卡住的往往不是新技术，而是“订单和库存联动”“图片路径失效”这类基础问题。网上书店系统的含金量不在页面多炫，而在于你能不能把一个电商闭环讲得滴水不漏：从加购到下单，从库存扣减到订单流转，每一步都要有设计、有理由。如果你正打算做这个题，我建议你先花两天时间把表结构和订单状态机定死，再动手写代码。该踩的坑这里列了一些，剩下的要靠你亲手敲一遍才能真正长在心里。