球鞋购物系统源码拆解：业务边界、数据库设计与订单防超卖

我也算经手过不少电商类的教学项目，但坦白讲，“球鞋购物系统”这类带源码、带数据库、还带文档的完整项目包，恰恰是最容易被低估的。很多人拿到压缩包，第一反应就是赶紧跑起来，结果要么卡在数据库连接上，要么被一堆表关系绕晕，最后只看了个首页就关掉了。

我这里把对这种“源码+数据库+文档”三件套项目包的理解和拆解过程完整写一遍。无论你是想把这个球鞋购物系统跑起来，还是打算照着它的思路自己从零写一套，都可以少走不少弯路。核心就三件事：先搞清楚业务边界，再盯死数据库设计，最后才是业务代码和部署文档。

1. 拿到项目先别慌：先理清球鞋购物系统的业务边界

1.1 项目要解决什么问题

球鞋购物系统本质上是一个垂直品类电商系统，卖的不是普通商品，而是“鞋”。千万别小看这个“鞋”字，它和卖手机、卖图书有本质区别。鞋有尺码，有颜色，有男女款之分，甚至还有不同版本、不同年份的复刻。如果数据库设计得不对，后面做购物车、做下单会非常痛苦。

我从这类项目里提炼出来的核心用户流程是这样的：

• 用户注册登录后，在首页或商品列表里看到在售球鞋；
• 点进详情页，看到球鞋的轮播图、价格、库存、可选尺码和配色；
• 选定“某双鞋的某个尺码和颜色”，加入购物车；
• 购物车结算，填写收货地址，生成订单；
• 模拟支付或直接确认订单，后台能看见订单列表并处理状态。

如果这个系统的定位是课程设计或毕业设计级别，那“支付”一般不会真的接微信或支付宝，而是模拟支付，重点在于订单状态流转和库存扣减。很多刚接触这类项目的人，会纠结“我没法完成真实支付怎么办”，其实没必要，可以做一个支付弹窗或者一个“立即支付”按钮，把订单状态从待支付改成已支付，真正要关注的业务逻辑在别处。

1.2 怎么拆功能模块才能不返工

一个购物系统看似简单，但模块划分如果一开始乱掉，后面写代码会越写越糊涂。我见过有同学把“购物车”和“订单”写到一个Service里，后面加一个字段都要两头改，维护成本非常高。比较合理的划分是这样的：

我们在做球鞋购物系统的时候，模块划分最好保持“一页就是一个模块”的感觉。例如访问 /api/sku/list 是商品列表，/api/cart 是购物车，/api/order 是订单，前端页面也一一对应，不要搞出什么“购物车里的订单”这种模糊概念。

1.3 为什么“SKU”是躲不掉的概念

做球鞋购物系统，如果只是建一张 goods 表，里面放一个“库存”字段，那是远远不够的。假设有一双 AJ1 黑白配色，它有 39 到 45 码，每个码数的库存可能不一样。如果整双鞋只有一个总库存，用户下单选了 42 码，你根本不知道 42 码还有没有货，这就会导致超卖或者库存混乱。

所以，在系统设计阶段一定要引入商品 SPU 和 SKU 的概念：

• SPU，简单理解就是“同一款鞋”，比如“某品牌经典篮球鞋黑红配色”，它本身不可直接下单，只是商品详情页的描述主体。
• SKU，是“具体能够购买的最小库存单元”，比如“某品牌经典篮球鞋黑红配色-42码”，它直接对应价格、库存、SKU编号。

球鞋购物系统能不能经得起别人推敲，就看你这个点做没做对。如果源码里已经分出了 shoe 和 shoe_sku 两张表，那这个项目的底子是好的；如果整张表只靠一个字段表示尺码，那后续涉及下单逻辑的代码基本要推翻重写。

2. 技术选型和工程结构：源码该怎么搭才清晰

2.1 后端选 Spring Boot 还是 SSH/SSM

在“球鞋购物系统”这类项目里，后端技术栈我推荐优先看 Spring Boot。不是因为它花哨，而是它足够标准。现在多数企业和课程设计采用的也是 Spring Boot + MyBatis Plus + MySQL，这套组合的好处是：代码量少、文档多、出错了百度或搜索引擎一搜一大把解决方案。

如果源码里用的是老式 JSP + Servlet，也不用害怕。老项目更容易看出原始 MVC 结构，只是页面和服务端耦合比较重，部署时还需要注意打 war 包和配置 Tomcat。我的个人建议是：如果这套球鞋购物系统是你拿来学习或者二次开发的，优先选 Spring Boot 版本的源码，它能让你把精力集中在业务上，而不是被配置文件折磨。

在使用 Spring Boot 的过程中，有几个版本细节必须提前确认：

• JDK 版本：Spring Boot 2.x 配合 JDK 8 没问题，Spring Boot 3.x 则要求 JDK 17 以上，这两个版本之间的依赖写法差异不小。
• MyBatis Plus 版本要和 Spring Boot 版本匹配，否则可能出现 Invalid bound statement 之类的报错。
• 数据库连接池推荐使用 HikariCP，Spring Boot 默认就带，别自己乱配 Druid 又配错。

2.2 前端框架：Vue 和静态页面的选择

如果是前后端分离，前端我会参考 Vue + Element UI 这种主流组合。球鞋商城页面上一般涉及商品网格、图片放大、购物车角标、弹窗表单等交互，Vue 写起来比原生 JS 舒服得多。Element UI 的好处是表格、表单、弹窗组件都很成熟，管理后台能快速成型。

如果整套代码是单体 JSP 页面，也没有问题，JSP 本身就能支持服务端渲染，商品列表和详情页直接通过 EL 表达式取值。需要接受的缺点就是前后端代码混在一起，修改页面样式时必须要重编译再重启。

在这里想给一个实用建议：不管前端用什么框架，都要在项目里保留一份“接口路径对照表”。比如“商品详情是 GET /api/shoe/{id}，加购是 POST /api/cart/add”，前端和后端都按照这个表格联调。没有这个表格，前端自己改了一个字段名，后端又改了接口结构，最后跑起来页面就会一片空白。

2.3 工程目录能不能一眼看懂

源码的价值不只是能运行，还要能被看懂和复用。我见到过一些项目把 controller 和 mapper 全塞在一个包里，Dao接口混在service里面，这种源码就算功能正常，阅读体验也会很差。

一个比较基础的 Spring Boot 工程结构大致是这样：

text复制shoe-shop
├── sql
│   └── shoe_shop.sql
├── server
│   ├── src/main/java/com/shop
│   │   ├── controller
│   │   ├── service
│   │   ├── mapper
│   │   ├── entity
│   │   ├── common
│   │   └── config
│   ├── src/main/resources
│   │   ├── application.yml
│   │   └── mapper
│   └── pom.xml
├── web
│   ├── src
│   │   ├── api
│   │   ├── views
│   │   └── components
│   └── package.json
└── 项目文档
    ├── 需求说明.md
    ├── 数据库设计.md
    ├── 接口文档.md
    └── 部署说明.md

这里的 entity 放数据表对应的实体类，mapper 写数据库操作，service 写业务规则，controller 暴露接口。如果你打算在这个基础上扩展，加一个 payment 模块或者 coupon 模块，也能够很清楚知道该在哪一层写代码。

3. 数据库设计：球鞋系统最花时间的部分

3.1 表结构拆解：从零设计一张可用的球鞋库

我在鼓捣这类电商系统时有个习惯：先写数据库脚本，再写代码。因为数据库表结构一旦确定，接口基本也就定了。对于球鞋购物系统，最简单但完整的表至少需要这几张：

• 用户表 sys_user
• 球鞋商品表 shoe
• 球鞋 SKU 表 shoe_sku
• 购物车表 cart_item
• 订单表 orders
• 订单明细表 order_item
• 收货地址表 receiver_address

先说 shoe 和 shoe_sku。shoe 放商品公共信息，比如名称、副标题、品牌、主图、详情图、状态。shoe_sku 放某一个具体尺码的库存和价格，相当于把原来一个商品的宽表拆成垂直结构，比如这样设计：

mysql复制CREATE TABLE `shoe_sku` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `shoe_id` bigint DEFAULT NULL,
  `color_name` varchar(50) DEFAULT NULL,
  `size` varchar(20) DEFAULT NULL,
  `price` decimal(10,2) DEFAULT NULL,
  `stock` int DEFAULT NULL,
  `sku_code` varchar(64) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_shoe_sku` (`shoe_id`, `color_name`, `size`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里 UNIQUE KEY 非常关键。它的意思是同一双鞋、同一个配色、同一个尺码只能存在一条记录。如果缺少这个唯一约束，你在代码里没写好判断，就可能插入两条一模一样的 SKU 记录，库存直接被拆成两半。

3.2 重点关注：价格不用浮点型，金额必须用 decimal

有非常多项目会在价格字段上踩坑。很多开源的旧代码喜欢把价格写成 float 或 double，看起来没问题，但做运算时会出现 0.1+0.2 不等于 0.3 的情况。卖球鞋单价几十到几千，金额精确度很重要，所以数据库里价格必须用十进制类型。

更合理的做法是 decimal(10,2)，表示最大支持到 99999999.99，对普通球鞋商城完全够用了。前后端传值时，也要统一用“元”作为单位，比如 399.00，不要一会儿前端传“分”，一会儿后端读“元”，这种单位不一致会导致订单金额对不上。

至于用户表，用户名加唯一索引，密码字段不能直接用 varchar(20) 存明文。哪怕只是教学项目，也要有安全意识。密码在注册时建议用 BCrypt 生成哈希后入库，登录时校验哈希值。字段长度不要图省事，varchar(128) 起步，否则 BCrypt 生成的 60 位哈希都存不下。

3.3 订单表怎么设计状态流转

订单表可以这样设计：

mysql复制CREATE TABLE `orders` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_no` varchar(64) NOT NULL,
  `user_id` bigint NOT NULL,
  `total_amount` decimal(10,2) NOT NULL,
  `status` tinyint NOT NULL DEFAULT '0',
  `receiver_name` varchar(50) DEFAULT NULL,
  `receiver_phone` varchar(20) DEFAULT NULL,
  `receiver_address` varchar(255) DEFAULT NULL,
  `remark` varchar(255) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  `pay_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有两个需要注意的点。第一个是订单号不要用数据库自增id直接展示，因为数字型订单号很容易被遍历，也会暴露销量，用时间戳加随机数这样的业务订单号更稳妥。第二个是状态字段，建议用数字状态码而不是直接存中文，我自己比较常用的状态码是：0 待支付、1 已支付/待发货、2 已发货、3 已完成、4 已取消。如果源码里用了字符串状态，数据库查询会多费很多。

订单明细表 order_item 也要保存下单时的商品快照：当时的价格、商品名称、尺码、缩略图。因为商品表的价格和标题后续可能变化，不能让用户翻开历史订单时看到的是今天修改后的名字。

3.4 数据库脚本怎么给最合理

“源码+数据库+文档”中的数据库文件，我见过很多版本，有的是 .sql 后缀，有的是 .bak 后缀，还有的可能是直接用 Navicat 导出的某一段。最稳妥的交付形式是：一份shoe_shop.sql文件，里面建库、建表、插入初始化数据一步到位。

如果数据库脚本里没有建库语句，只有建表，部署的人就要手动去建空库再导入，很容易漏掉字符集。所以我在整理脚本时会习惯性在文件开头加上：

mysql复制CREATE DATABASE IF NOT EXISTS shoe_shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE shoe_shop;

这样做的好处是无论谁来部署，只要执行一次 SQL 脚本，就能得到一个完整的、包含演示数据的数据库，不用自己去折腾库名和字符集。

4. 业务代码怎么实现：登录、加购和下单是关键

4.1 用户登录和登录状态保持

在多数球鞋购物系统源码中，登录一般在 Controller 层接收用户名密码，然后调用 Service。如果系统足够简单，可以用 Session 保存登录状态；如果独立的前后端分离，用 JWT 的更多一些。但不管哪种方式，有一个原则不要丢：用户登录以后才能操作购物车和下单，后端接口必须校验登录状态，不能只看前端“藏着”按钮就觉得安全。

我在写这类接口时的做法是搞一个 @LoginUser 注解或者一个拦截器，在后端统一从 token 或 session 里拿用户 id，而不是让前端每次传 userId。如果每次接口都信任参数里的 userId，那恶意用户完全可以猜别人的 id，然后给自己加购，篡改订单归属，这种漏洞在代码评审时很致命。

用户密码校验推荐用 BCrypt 的 matches 方法判断明文密码和哈希是否匹配，避免把数据库中哈希拿出来反推。登录成功后，把 userId 和 username 放进去。

4.2 商品浏览和购物车

商品列表页看起来只是查一张表，但和 SKU 查询有关联。展示商品时可能只展示主图和最低价，这意味着你要一次性查 SKU 表里的最低价格，SQL 可以分组对每个 shoe_id 取价格最小值，然后在内存里处理，或者直接写一条关联查询。如果源码是简单循环查数据库，数据少时无所谓，数据一大页面就会越来越慢。

购物车模块的难点在加购后重新勾选结算。用户可能昨天加了一双 42 码的鞋，今天店家已经把价格从 899 改成 1299，那么提交订单时就必须以当前价格为准，而不是购物车里的旧价格。我在代码里常用一个处理策略：加购时只存 shoe_id、sku_id、数量，不存价格；到结算下单时去最新查询 SKU 价格和库存，重新计算金额。这样商品改价后订单不会出现错乱。

4.3 下单和扣库存：必须防超卖

球鞋购物系统里，最常见的并发问题就是限量球鞋秒杀或多人同时买同一码。如果代码是这样写的：先查询库存是否够，够就 update 减库存，这在高并发下一定会超卖。两条线程同时查到库存还剩 1，然后各自去减，最后库存变 -1，订单却生成了两个。

要避免这个问题，最简单有效的方法是把“查询并更新库存”做成一件事，用数据库行锁来保护。比如在事务里先执行：

mysql复制SELECT * FROM shoe_sku WHERE id = #{skuId} AND stock >= #{quantity} FOR UPDATE;

FOR UPDATE 的意思是这一行在事务提交前被当前事务锁住，其他事务只能等待。查到记录后，再去执行扣减；如果查不到，直接抛“库存不足”。整个过程必须放在同一个 @Transactional 事务里。

一个典型的错误顺序是：先生成订单，再扣库存。这样如果扣库存失败，订单已经生成，会造成脏数据。更好的顺序是：锁库存、扣库存、生成订单、生成订单明细，最后提交事务。如果中间任何一步异常，整个事务回滚，库存和订单不会出现只成功一半的问题。

4.4 订单状态流转

球鞋购物系统的订单状态和普通电商一致，代码里应当只允许执行合法流转：

• 待支付订单，用户可以取消；
• 待支付订单，可以模拟支付，变成已支付/待发货；
• 待发货订单，管理员点击发货，变成已发货；
• 已发货订单，用户确认收货后变成已完成。

如果用户下单 30 分钟不支付，系统应该自动取消订单并释放库存。不过很多简化版系统没有取消超时逻辑，那至少要在用户主动取消订单时，将 SKU 的库存增加回来，否则用户心仪但不想买的鞋库存会被白白占住。

5. 数据库之外，一套好文档比想象中更重要

5.1 接口文档怎么组织不返工

只要是前后端分离的球鞋购物系统，接口文档就是前端和后端之间的契约。写文档的时候不要把每个字段都描述得特别复杂，但要保证以下几点：

• 接口地址、请求方式、参数类型；
• 请求参数是否必填；
• 返回值结构，尤其是列表和详情分别返回什么。

我自己习惯用表格记录一个接口，例如：

一个简单的接口返回值可以约定成：

json复制{
  "code": 200,
  "message": "success",
  "data": {}
}

前端判断 code 是否等于 200 就知道成功还是失败。如果整个项目所有接口都不统一返回值，前端要到处写兼容逻辑，体验会差很多。

5.2 README 和部署文档应该写什么

很多同学看一篇 README 能踩一下午坑，往往是因为 README 没写清楚环境版本。我整理球鞋购物系统这类项目的时候，README 开头会列一张环境清单：

• JDK 1.8 或 17
• Maven 3.6+
• MySQL 8.0+，字符集 utf8mb4
• Node.js 16+ 和 pnpm/npm

然后按照顺序写五步启动流程：导入数据库、修改配置文件、启动后端、启动前端、访问后台地址。千万不要省掉“修改配置文件”这一步，application.yml 的数据库密码、端口最容易因人而异。只要在文档里写明“将密码改成你自己 MySQL 的密码，否则启动后报 access denied”，就能替使用者挡掉一个最大的坑。

源码项目还容易遇到版本依赖问题，值得在文档里留一个“FAQ”段落，把常见的 Maven 下载慢、前端依赖安装失败、端口占用放进去。这看起来是额外工作，但对使用项目的人来说，价值不亚于源码本身。

5.3 交付时不要漏掉哪些文件

“源码+数据库+文档”三件套，最怕的是其中任何一件不完整。我在检查交付内容时，会按下面这个清单核对：

• 源码压缩包里是否包含隐藏目录或大型依赖包。如果用的是 Git，源码包不要包含 node_modules 和 target 目录，这些可以依赖安装命令自动生成，否则压缩包又大又无效。
• 数据库脚本是否能直接执行。建议在一个全新的 MySQL 实例里执行一遍脚本，确认不会报错。要是脚本里漏掉某个外键，仓库在最后导入时才失败，定位问题就很费劲。
• 文档里的步骤是否按顺序跑通。严格按照文档执行一遍后，如果还能启动并把商品加购、下单，就可以认为这份交付是靠谱的。
• 初始化数据是否足够演示。系统里至少要有一两双鞋、每个鞋有两三个尺码、管理员账号和一个测试用户账号。否则登录后台后看到一片空白，很难判断系统到底有没有问题。

6. 实际运行中我踩过的高频问题

6.1 数据库脚本导入后表不存在

这个问题经常出现。导入 SQL 时报了一堆成功，但启动项目后提示 Table 'shoe_shop.sys_user' doesn't exist。大概率是 SQL 脚本里建表语句前面有 DROP TABLE，但连接 MySQL 后没有执行到最后一个语句，或者导入时选错数据库了。

更常见的场景是：脚本里没有建库语句，你手动建了一个库叫 shoe_shop_test，但脚本建表时用的库名是 shoe_shop，两者一错位，表就跑到了另一个库。所以一个建议：要么用 root 账号执行完整脚本，要么脚本里千万别省略 USE database;。

6.2 数据库连接报错和中文乱码

连接 MySQL 8 时报“Public Key Retrieval is not allowed”，原因是 MySQL 8 默认使用 caching_sha2_password 插件，客户端第一次连接时需要从服务器获取公钥。

解决办法是在 JDBC 连接参数中加上：

text复制allowPublicKeyRetrieval=true&useSSL=false

例如：

yaml复制url: jdbc:mysql://localhost:3306/shoe_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai

至于中文乱码，绝大多数情况是建库字符集不是 utf8mb4，或者连接字符串没有指定 characterEncoding=utf8。在 MySQL 8 中建议尽量统一 utf8mb4，尽量不用老的 utf8，这样既能显示中文，也能存 emoji 表情符（商品名里可能会带的一些特殊符号）。

6.3 并发扣库存导致的“负库存”问题

我在调试无脚本或简化代码时，故意用两个浏览器同时登录两个账号，抢购同一双鞋的同一个 42 码，结果生成了两个订单，库存变成了负数。原因就是扣库存没有按行锁处理。正确的 SQL 应该是类似：

mysql复制UPDATE shoe_sku SET stock = stock - #{quantity}
WHERE id = #{skuId} AND stock >= #{quantity};

这样一句 SQL 本身就能保证“有足够库存才扣减”，返回受影响行数为 1 表示扣减成功，为 0 表示库存不足。如果能把这一句放到事务中，配合必要的行锁，基本能覆盖低并发场景。若真要做高并发秒杀，那就得上 Redis + 消息队列或者其它更重的手段了，这已经超出一般购物系统源码的范围。

6.4 时间字段不对、显示少 8 小时

很多时候后台看到的订单时间和本地差了 8 小时，不是系统 bug，是时区问题。MySQL 连接 string 加 serverTimezone=Asia/Shanghai，后端返回给前端时，前端又按照本地时区解析一次，通常就能对上。如果还是不对，看看实体类的日期类型用了 java.util.Date 还是 LocalDateTime，统一推荐 LocalDateTime，序列化时配上格式，会比较省心。

把一套球鞋购物系统的源码、数据库脚本和文档完整走下来，其实就是在走一个微缩电商项目的核心生命周期。我个人体会最深的是，前端页面和增删改查代码都只是表象，真正决定这个项目质量高低的，是数据库的表设计，以及下单环节的事务和并发控制。拿到源码包以后，与其着急换 logo、改标题，不如先顺着 SQL 脚本把表结构画一遍，再对着 Controller 把主流程走通。很多改了前端就报错、加了需求就翻车的问题，其实在数据库造表那一步就已经埋下隐患了。这个小项目能不能作为面试项目拿出来讲，也看你能否把“为什么这么拆表”这件事讲清楚。