球鞋购物系统设计与实现：数据库建模到订单核心逻辑详解-代码聚汇网

“球鞋购物系统”，这名字一看就是典型的数据库课程设计或者毕业设计题目。说它是购物系统，但它和淘宝京东最大的区别在于：业务范围收窄到球鞋一个品类，核心上要有用户、球鞋商品、库存、购物车、订单这几张表能自圆其说，还要把上架、加购、下单、支付这几个动作跑通。很多同学拿到类似题目后最容易犯的毛病是，把重点全压在“前端页面好不好看”上，结果提数据库一问就哑火。实际上老师最看重的恰恰是：你建的库能不能支撑这套业务、下单时库存怎么扣、订单里的价格信息从哪来。

这篇分享我就围绕“源码库+数据库脚本+设计文档”这套完整交付物来拆解，适合正在做课程设计的学生，也适合想补齐电商类项目基础设计的开发者。我会把数据库表结构怎么设计、后端接口怎么组织、文档怎么写才不容易被答辩问倒，以及实际部署中踩过的坑都列出来。如果你正准备拿这类题目练手或交作业，这篇文章可以直接照着搭骨架。

1. 项目整体拆解：先搞清楚交付物是什么

很多同学拿到任务后第一反应是“赶紧写代码”，但这一步往往是最亏的。课程设计或毕业设计类项目，验收标准通常不是功能多炫，而是“逻辑完整、能跑通、能说清楚”。所谓源码+数据库+文档，本质上是三个相互印证的部分：代码证明系统可用，数据库证明数据模型成立，文档证明你明白自己在做什么。

1.1 为什么这类题目永远不过时

球鞋购物系统这类题目在线下课程里出现率极高，核心原因是它的业务完整度足够做教学案例。它不是一个简单的增删改查，而是包含了电商领域最常见的核心问题：商品规格库存、购物车与订单的联动、下单时的数据一致性、历史订单的数据快照。这些概念放到任何真实电商系统里都是绕不开的。

如果你拿的是“球鞋购物系统”而不是泛泛的“网上商城”，那意味着你的数据设计里至少要体现“球鞋”的品类特征。球鞋有品牌、系列、配色、尺码，同一款鞋不同尺码库存不同，这是它和普通图书商城最大的差异点。很多把球鞋系统做成普通购物商城的方案，失败就失败在商品表直接加了一个“库存”字段，根本没有尺码维度，答辩时老师一问“42码没货但41码有货，你怎么表达？”就卡住了。

1.2 技术栈怎么选才不给自己挖坑

结合我做过的多个类似项目，我只推荐一个最稳的组合：Java 8 + Spring Boot 2.7.x + MyBatis + MySQL 5.7/8.0 + Vue 2 + Element UI。这套组合的好处是网上资料多，遇到报错基本一搜就有解决方案。前端如果要降低工作量，可以直接把编译后的静态资源放到 Spring Boot 的 static 目录下，这样启动一个后端服务就能同时提供页面和接口，部署答辩的时候少很多麻烦。

我也见过用 JSP、Servlet 的经典方案，不是不行，但问题在于现在的主流教程和个人电脑环境对老技术栈并不友好。Tomcat 版本、JSTL 标签库各种依赖很容易把人劝退。至于 Python 系的 Django、Flask，如果你是 Python 方向倒是没问题，但如果是数据库课程设计大概率是 Java 系，所以我不建议你在这时候临时换语言。

选 Java 系的另一个原因是它和数据库交互的生态最成熟。MyBatis 里写动态 SQL、事务注解事务管理都非常直观，方便你在文档里写出“功能实现逻辑”，而不是天天和前端跨域纠缠。

1.3 三份交付物的分工顺序

从我经手项目的经验看，拿到需求后最合理的顺序是：先画数据库模型，再写后端接口，然后做前端页面，最后补文档。为什么要先画数据库？因为表结构一旦确定，后端的实体类、Mapper接口、前端需要展示的字段基本都定下来了。很多人反过来先写页面，做一半发现字段对不上再回去改表，等于白做。

源码的交付重点不是“每行都自己敲”，而是你能讲清楚每个模块入口在哪个文件、核心逻辑在哪几行。数据库的交付重点最好是一个 .sql 文件，打开就能建库建表，自动带上基础数据。文档的交付核心是数据库设计说明和测试运行说明。这三者之间是层层对应的，不要让它们各说各话。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据库设计：把球鞋业务翻译成表结构

如果让我给这个项目分配精力，数据库设计至少要占 40%。数据库设计不过关，后面代码写得再漂亮都没用。老师只要打开你的建表 SQL，扫一眼字段、主外键逻辑，就能判断你到底是认真做了还是从网上随便拖了份代码。

2.1 从下单流程反推需要的核心表

设计数据库之前，先别急着写 CREATE TABLE，先推演用户从点开商品到完成购买经历了哪些步骤。用户登录系统需要用户表，浏览球鞋需要商品表和分类表，看中某款鞋的某个尺码需要记录商品规格和库存，这就要商品规格表。想把商品先放一边稍后买，需要购物车表。结算时生成一笔完整的订单，需要订单表。一笔订单里可能包含多双不同款式的球鞋，还需要订单明细表。用户收到货可以评价，于是再来一张评论表。后台要维护商品上下架和发货，于是管理员角色和角色权限也需要考虑。

这就引出了项目中最少要有的 8 张表：用户表、分类表、球鞋商品表、球鞋规格库存表、购物车表、订单表、订单明细表、评论表。如果你希望首页有轮播图，加一张广告图表也顺理成章。

这里我之所以强调“球鞋规格库存表”，就是前面说的尺码问题。同一款鞋，配色、尺码组合决定了它是一个独立的可售库存单元。在电商领域这叫 SPU 与 SKU 的概念，商品表相当于 SPU，规格表就是 SKU。字段设计里 product 表里可以写“销量”“默认展示价”，但真正的可下单库存和实际成交价应该挂在 sku 表上，否则你没法解释 41 码和 42 码库存差异这件事。

2.2 核心表字段设计逐张拆解

下面给出我认为可以照抄借鉴的核心建表结构。注意这里所有表名我都做了处理，避免和 MySQL 保留字冲突。

用户表，我习惯命名成 sys_user：

sql复制CREATE TABLE `sys_user` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '用户ID',
  `username` varchar(50) NOT NULL COMMENT '用户名',
  `password` varchar(100) NOT NULL COMMENT '密码，BCrypt加密后存放',
  `nickname` varchar(50) DEFAULT NULL COMMENT '昵称',
  `phone` varchar(20) DEFAULT NULL COMMENT '手机号',
  `email` varchar(100) DEFAULT NULL COMMENT '邮箱',
  `role` tinyint NOT NULL DEFAULT '0' COMMENT '角色：0普通用户 1管理员',
  `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：1正常 0禁用',
  `create_time` datetime NOT NULL,
  `update_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

用户名加唯一索引的意义在于登录时要用它做精确查询，同时避免重复注册。密码字段我留了 varchar(100)，因为 BCrypt 加密后的字符串长度是 60 位，别只看当前觉得 32 位够就只给 32。

球鞋分类表：

sql复制CREATE TABLE `category` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL COMMENT '分类名，如篮球鞋、跑步鞋',
  `sort` int NOT NULL DEFAULT '0' COMMENT '排序权重',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='球鞋分类表';

分类表单独拿出来，方便后台维护分类以及首页按分类筛选，如果只把分类名写在商品表里，以后改个名字还得改商品记录，不优雅。

球鞋商品表 product，这是很多人的重点：

sql复制CREATE TABLE `product` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `category_id` bigint NOT NULL COMMENT '所属分类',
  `name` varchar(100) NOT NULL COMMENT '球鞋名称',
  `subtitle` varchar(255) DEFAULT NULL COMMENT '副标题或一句话卖点',
  `brand` varchar(50) DEFAULT NULL COMMENT '品牌',
  `cover_image` varchar(500) DEFAULT NULL COMMENT '主图URL',
  `detail` text COMMENT '富文本详情或图文详情',
  `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：1上架 0下架',
  `sales_count` int NOT NULL DEFAULT '0' COMMENT '销量，冗余统计字段',
  `create_time` datetime NOT NULL,
  `update_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_category` (`category_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='球鞋商品表';

这里要提醒的是：建议不要在该表里放“库存”字段，因为库存粒度在规格上，不在整双鞋上。但销量可以放这里，因为后台首页通常只需要按整款鞋展示一个累计销量，没必要每次实时去统计订单明细表，这是典型的“允许冗余字段换取查询性能”。

规格库存表 sku：

sql复制CREATE TABLE `sku` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `product_id` bigint NOT NULL COMMENT '所属商品',
  `color_name` varchar(30) DEFAULT NULL COMMENT '配色名',
  `size` varchar(10) NOT NULL COMMENT '尺码，如42、42.5',
  `stock` int NOT NULL DEFAULT '0' COMMENT '当前库存',
  `price` decimal(10,2) NOT NULL COMMENT '售价',
  `image` varchar(500) DEFAULT NULL COMMENT '该规格单独的图片',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_product_sku` (`product_id`, `color_name`, `size`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='球鞋规格库存表';

字段中含 decimal(10,2) 而不是 float，是因为价格这种东西用浮点数会出现 0.1+0.2 不等于 0.3 的尴尬问题。球鞋价格多在几千元以内，10 位总长度加 2 位小数已经足够覆盖。唯一索引的意义是不要让同款同配色同尺码出现两条记录。

购物车表建议命名 cart_item：

sql复制CREATE TABLE `cart_item` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `user_id` bigint NOT NULL,
  `product_id` bigint NOT NULL,
  `sku_id` bigint NOT NULL,
  `quantity` int NOT NULL DEFAULT '1',
  `create_time` datetime NOT NULL,
  `update_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_sku` (`user_id`, `sku_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='购物车表';

购物车里冗余了 product_id，查询列表时能少一次 join，但你也可以不加这个字段直接通过 sku 反查商品。设计取舍上没有绝对答案。唯一索引 (user_id, sku_id) 是为了防止同一用户同一尺码被重复添加，它会让“再次加入购物车变成更新数量”这件事从数据库层面得到保证。

订单表 orders：

sql复制CREATE TABLE `orders` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '业务订单号',
  `user_id` bigint NOT NULL,
  `total_amount` decimal(10,2) NOT NULL COMMENT '商品总额',
  `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额，先简单和总额相同',
  `status` tinyint NOT NULL DEFAULT '0' COMMENT '订单状态：0待支付 1已支付 2已发货 3已完成 4已取消',
  `receiver_name` varchar(50) NOT NULL,
  `receiver_phone` varchar(20) NOT NULL,
  `receiver_address` varchar(255) NOT NULL,
  `create_time` datetime NOT NULL,
  `pay_time` datetime DEFAULT NULL,
  `ship_time` datetime DEFAULT NULL,
  `finish_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

订单为什么要订单号？因为自增主键不适合直接暴露给用户，万一被人恶意遍历，就能轻松推算出你这个平台的日单量。所以业务上订单号单独用一个随机生成的字符串或者“时间戳+用户ID+随机数”拼出来的字符串。

订单明细表 order_item：

sql复制CREATE TABLE `order_item` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_id` bigint NOT NULL,
  `product_id` bigint NOT NULL,
  `sku_id` bigint NOT NULL,
  `product_name` varchar(100) NOT NULL COMMENT '商品名称快照',
  `product_image` varchar(500) DEFAULT NULL COMMENT '商品主图快照',
  `product_spec` varchar(100) DEFAULT NULL COMMENT '规格快照，如"黑白/42"',
  `price` decimal(10,2) NOT NULL COMMENT '下单时单价快照',
  `quantity` int NOT NULL COMMENT '购买数量',
  `subtotal` decimal(10,2) NOT NULL COMMENT '小计',
  PRIMARY KEY (`id`),
  KEY `idx_order_id` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

关于快照这事我要单独说一句。很多人设计订单明细时图省事，只存 product_id 和 sku_id，认为到时候需要商品名可以 join 商品表查出来。实际上一旦商品后来改名、下架甚至被删除，你的历史订单详情就会显示不出商品信息。电商系统里订单凭证讲究“当时是什么样就是什么样”，所以必须把商品名称、价格、图片、规格描述作为冗余字段存进明细表。这个设计思路是答辩时最容易出彩的点。

评论表 comment：

sql复制CREATE TABLE `comment` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `product_id` bigint NOT NULL,
  `user_id` bigint NOT NULL,
  `order_id` bigint NOT NULL,
  `content` varchar(500) DEFAULT NULL,
  `rating` tinyint NOT NULL DEFAULT '5' COMMENT '评分1-5',
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品评论表';

2.3 字段类型设计的几个避坑原则

字段类型这事儿，最怕凭空想。第一个坑是用户名和手机号。手机号如果存 int，会直接溢出，甚至显示成负数，所以这类“看起来是数字但其实不参与运算”的值，一定要用 varchar。第二个坑是金额。金额不要用 float 或 double，用 decimal 最稳。第三个坑是时间字段。如果是课程设计，我建议统一用 datetime，比用 int 存时间戳更直观，写 SQL 查询也方便，文档里截图也好看。第四个坑是编码。建库时一定指定 utf8mb4，而不是 utf8，因为 utf8mb4 才能完整支持所有中文和 emoji，如果商品描述里带了个特殊字符，导入时就崩了。

索引也不用加太多，主键索引是必须的，用户名唯一索引来一个，外键关联经常查询的字段加普通索引就够了。要不要物理外键一直有争议，在课程设计里我不反对加上外键约束，因为文档里能多写两句“数据完整性”，但真实的互联网项目通常不加物理外键，靠应用层保证一致性。你要是想显得更专业，可以在文档里提一句“出于性能考虑，项目中使用逻辑外键”。两种说法老师都认。

3. 后端接口与核心业务实现思路

数据库底子打好了，后端代码其实就是把数据操作串成业务动作。一个购物系统后端说复杂也复杂，登录、商品、购物车、订单、库存每个都是话题，但核心其实只集中在几个地方。我挑最容易出问题的模块讲一下实现思路和关键代码风格。

3.1 登录注册模块：密码加密和登录状态要有讲究

用户注册时，密码不能明文写进数据库。如果你还在用 MD5 加密，答辩时也容易显得方法老旧。建议用 Spring Security 里的 BCryptPasswordEncoder，或者直接用 jbcrypt 库，核心代码就一行：

java复制String hashedPwd = BCrypt.hashpw(password, BCrypt.gensalt());

校验的时候用 BCrypt.checkpw(rawPassword, hashedPwd)。这种算法的好处是每次生成的密文不同，但都能正确校验原始密码，安全性比固定 MD5 高不少。

登录状态有两种方案：Session 和 JWT。课程设计如果追求简单，Session + 拦截器完全够用，浏览器帮你管理 cookie，你只需要在拦截器里判断当前 session 有没有用户。但我更建议用 JWT，因为写完以后文档里能写“前后端分离 + 无状态认证”，显得你接触过业界主流方案。用户在登录接口拿到 token 后，前端存到 localStorage，之后每次请求在 Header 里带 Authorization: Bearer token，后端拦截器解析 token 并获取用户 ID。

java复制String userId = Jwts.parser()
        .setSigningKey(SECRET)
        .parseClaimsJws(token)
        .getBody()
        .getSubject();

这段逻辑不需要写得很长，关键是能自圆其说：token 如何生成、如何校验、如何识别管理员。

3.2 商品列表：动态 SQL 比写死条件更灵活

商品模块的查询条件通常包括：分类、品牌、价格区间、关键词搜索。最忌讳的是在 Java 里拼出来一堆 if 然后拼 SQL 字符串，容易产生 SQL 注入。用 MyBatis 的动态 SQL 是最正规的做法：

xml复制<select id="selectProductPage" resultType="com.example.entity.ProductVO">
    SELECT p.*, c.name AS category_name
    FROM product p
    LEFT JOIN category c ON p.category_id = c.id
    <where>
        <if test="categoryId != null">
            AND p.category_id = #{categoryId}
        </if>
        <if test="keyword != null and keyword != ''">
            AND (p.name LIKE CONCAT('%', #{keyword}, '%')
                 OR p.brand LIKE CONCAT('%', #{keyword}, '%')
                 OR p.subtitle LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="minPrice != null">
            AND p.id IN (
                SELECT product_id FROM sku
                WHERE price &gt;= #{minPrice}
            )
        </if>
        AND p.status = 1
    </where>
    ORDER BY p.sales_count DESC, p.create_time DESC
    LIMIT #{offset}, #{pageSize}
</select>

这里为什么价格筛选要写成子查询而不是直接查 product 表的字段？因为你的商品默认展示价如果放在 product 表里，当然可以直接查。但如果售价在 sku 上，某个球鞋可能因尺码不同价格有细微差异，稳妥筛选方式应是“最低价对应的 SKU 存在符合条件区间即可”。子查询保证了语义正确。价格字段建议加普通索引，否则大表下批量查询会有性能隐患。

分页直接用 LIMIT offset 是最直观的，参数传页码 pageNum 和每页条数 pageSize，先算 offset = (pageNum - 1) * pageSize。total 要么单独 count 查询，要么用 MyBatis 的分页插件 PageHelper 自动完成。课程设计里手写一个 count 就够了，别让插件背锅。

3.3 购物车和订单：一张表把战线拉通

购物车的接口其实很套路：加入购物车时先查这个用户的 cart_item 表中有没有同 sku，有就累加数量，没有就插入新记录。返回购物车列表时要 join sku 和 product，把当前 SKU 的库存、售价、商品图和名称一起查出来，方便前端展示。前端调整数量后每次要回传 cartItemId 和新 quantity，后端先判断库存够不够，够则更新，不够则返回提示“库存不足”。

结算下单是最需要考虑周全的动作。用户点击“去结算”后，系统要做的事不是马上生成订单，而是先校验购物车选中的商品是否存在、上下架状态是否正常、每个 SKU 的库存是否满足购买数量。这些校验都通过了，再生成订单主表和订单明细。这个过程的直观写法是：

java复制@Transactional(rollbackFor = Exception.class)
public Long createOrder(Long userId, Long[] cartItemIds, AddressDTO address) {
    // 1. 查出选中的购物车记录
    // 2. 逐条校验商品状态和库存
    // 3. 生成订单号
    // 4. 插入 orders 主表
    // 5. 遍历购物项，插入 order_item 明细
    // 6. 扣减库存：UPDATE sku SET stock = stock - #{num} WHERE id = #{skuId} AND stock >= #{num}
    // 7. 删除已购买的购物车记录
    // 8. 返回 orderId
}

这里 @Transactional 一定要加，因为从生成订单到扣库存是几个写操作，不能出现“订单生成了但因为库存不足导致扣减失败，脏数据还在”的情况。MySQL 的 InnoDB 引擎下事务里出现 RuntimeException 会自动回滚。

3.4 扣库存别用先查后改，一条 SQL 才是王道

扣库存是电商系统里最容易出 bug 的地方。很多人喜欢先 SELECT stock FROM sku WHERE id = ?,然后在 Java 里判断 stock 是否大于要扣的数，再执行 UPDATE sku SET stock = stock - ?。这在单机、低并发下没问题，但一旦两个人同时下单，就可能都读到了同一个 stock，导致最后库存变负数。

为了避免超卖，正确的做法是把“判断库存够不够”和“扣减”合并到一条 SQL 里：

sql复制UPDATE sku
SET stock = stock - #{quantity}
WHERE id = #{skuId} AND stock >= #{quantity}

执行后如果影响行数为 0，说明库存不足，事务直接回滚并提示用户。这里的原理是数据库行锁，UPDATE 在同一行上会串行执行，后执行的人拿不到锁就等前面事务提交，然后发现条件不满足，自然扣不了。这条 SQL 是我认为整个系统里最值得写到文档和答辩材料里的亮点。

如果你为了更严谨，可以在创建订单前先按 skuId 排序所有待扣减项。原理是多个并发事务如果都同时在锁多行库存，锁请求顺序不一致可能会造成死锁。比如事务 A 先锁了 SKU1 再锁 SKU2，事务 B 先锁 SKU2 再锁 SKU1，两边都在等对方释放锁，数据库就会检测到死锁并回滚一个事务。排序后就变成大家都按从小到大加锁，死锁概率大幅降低。

3.5 模拟支付：订单状态机走一遍

课程设计里不太可能接入真实支付渠道，但把状态流做完整是加分项。订单状态的迁移建议为：待支付 0 -> 已支付 1 -> 已发货 2 -> 已完成 3。同时支持待支付状态下的取消操作，取消后需要把对应 SKU 的库存加回去。

模拟支付接口一般传一个 orderId，后端把订单状态从 0 改成 1，并设置 pay_time。管理员发货是把状态从 1 改成 2，并设置 ship_time。确认收货从 2 改成 3。写的时候要注意，每一步都要校验“当前状态是否是我期待的前置状态”，否则用户重复点支付按钮就可能出现状态错乱。最简单的写法：

java复制int affected = orderMapper.updateStatus(
        orderId,
        oldStatus,
        newStatus
);
if (affected == 0) {
    throw new BusinessException("订单状态已变化，请刷新后重试");
}

这里的 update 语句里带上 WHERE status = #{oldStatus}，用影响行数判断是否更新成功，属于乐观锁思路。答辩证问“高并发下订单状态被覆盖怎么办”时，这段话可以直接交差。

4. 前端页面和组织方式：别把形象工程排太满

课程设计的前端不用做到像素级还原，但页面数量要足够覆盖业务模块。很多同学一上来写了一个精美首页，结果后台管理、个人中心都没做，这就是本末倒置。页面是否完整比单个页面是否好看重要得多。

4.1 商城端需要哪些页面

商城端用户视角的页面至少要有：登录/注册页、首页、商品列表页、商品详情页、购物车页、确认订单页、支付结果页、个人中心页、我的订单列表页、订单详情页、评论页。这一串数下来已经 11 张页面了，如果每张都从零手写很耗时，建议直接用 Element UI 这类组件库，表格、分页、弹窗、表单校验都有现成组件。

我推荐一个偷懒但很实用的做法：用 Vue CLI 创建项目，页面路由配好以后，把 axios 封装成一个 request.js，统一处理请求前缀和 token。每个页面调用后端接口时只需要关心业务数据，不用每个请求都写一遍 headers: {Authorization: ...}。

4.2 后台管理端页面别忽略

后台管理页面是很多同学的盲区，因为他们觉得“管理功能是给老师看的，随便做点就行”。但反过来想，老师验收时如果连商品都不能通过页面添加，只能手动改数据库，你系统演示的完整度就大打折扣。

后台管理页面建议包含：登录、仪表盘（统计用户数、球鞋数、待发货订单数）、球鞋管理列表、添加/编辑球鞋弹窗、SKU 库存管理、订单管理列表、订单发货按钮、分类管理、用户管理、评论管理。其实这些页面都只是 CRUD 的变体，但每多一张页面，你的系统截图素材就多一张，文档里能贴的测试内容也就更丰富。

4.3 接口前缀和统一返回结构

前端联调后端时最容易遇到的两个问题是跨域和返回结构不统一。后端可以写一个配置类允许跨域，也可以约定所有接口都以 /api 开头，然后给前端返回统一的 JSON 结构。我建议定义成下面的形式：

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

code 为 200 代表成功，非 200 为业务失败，401 代表未登录。这样前端只需要在 axios 的响应拦截器里统一判断 code，而不是每个接口各写各的返回格式。为了省前端抄代码的时间，后端提供的接口文档可以直接写到项目的 README 里，写清楚每个接口的 URL、请求方式、参数名、返回示例，这比单独开一个文档网站更省事，老师也更容易看到。

5. 文档怎么写才能拿高分并被问到不慌

很多评审老师没时间逐行看代码，他们了解你系统的方式就是读文档+看演示+提问。文档质量直接决定第一印象。

5.1 文档组织的基本框架

一份数据库课程设计文档，至少应该有这些章节：

第一是需求分析。这一章不需要长篇大论，写清楚系统面向的用户角色、主要业务流程即可，建议配一张最简单的用户用例图。

第二是数据库设计。这一章是重中之重，包含 ER 图、关系模式、建表语句、每张表的字段说明。ER 图推荐用 draw.io 画，不追求美观但实体、属性、联系要清楚。字段说明我建议用表格列出来：字段名、类型、约束、说明。不要只丢一段建表 SQL，让老师自己一行行猜。

第三是系统设计。说明前端页面有哪些、后端接口有哪些，核心模块的流程图。下单流程图和登录流程图是老师最爱看的两张图。流程图不用画得很专业，用箭头把步骤串起来即可。

第四是系统实现。核心代码可以贴两到三段，比如扣库存的 SQL、加事务的下单方法、登录鉴权的拦截器。注意代码一定要精简，只贴关键代码，避免整页整页贴代码。

第五是测试结果。放一些运行截图，涵盖前端页面展示和功能效果。每一张截图下面配一句话说明“测试内容：添加球鞋后列表出现新商品”。测试用例可以做成表格，写测试项、操作步骤、预期结果、实际结果。

第六是部署说明。写出 JDK、MySQL、Maven、Node 的版本要求，以及启动步骤：先导入 sql，再改数据库账号密码，再启动后端，最后访问前端地址。这个部分虽然不起眼，但老师如果真的想把项目跑起来，全靠这一段。

5.2 文档里可以提前埋好的亮点

写文档时不要只写“做了什么”，要写“为什么这样做”。开篇时简单提到项目基于“前后端分离模式”，数据库设计时说明“使用规格表处理球鞋尺码和库存”，订单模块中重点解释“采用快照字段保证历史订单的可追溯性”，这三点是区分普通项目和优秀项目的分水岭。

再一个容易加亮点的地方是系统的运行前提。你可以明确给出测试账号，比如管理员 admin/123456，用户 test/123456。不要小看这个小细节，老师登录系统时不用费劲注册，体验立马不一样。

5.3 答辩前先拿这些问题自问

每次带学生准备答辩，我都会让他们先把下面的问题过一遍如果你能顺畅回答，那基本不会被问倒：

为什么用户表的密码字段用 60 个字符？因为 BCrypt 加密结果固定 60 位。为什么订单明细里要冗余商品名称和价格？因为商品信息可能会变化，订单需要的是下单时快照。同一款鞋两个尺码怎么处理库存？通过 SKU 表区分。扣库存为什么用一条 UPDATE 而不是先查再更新？为了避免并发下库存变成负数。怎么判断用户是否管理员？解析 JWT 里的角色字段。事务加在哪个方法上？下单方法，回滚条件是 Throwable 还是 Exception？

这些问题都不是死记硬背的八股，它们全都源于你自己数据库的一个字段、一个注解、一段代码。如果项目真是自己一步步搭的，回答起来完全不需要紧张。

6. 实操中容易踩的坑和排查思路

项目本身不难，但环境问题常常耗掉比你写代码还多的时间。下面这些坑几乎每个用 Spring Boot + MySQL 的人都会至少遇到一个。

6.1 MySQL 连接报错：八成是时区或驱动问题

最常见的是启动后端时报错 java.sql.SQLException: The server time zone value ... is unrecognized。MySQL 8.x 默认时区和驱动要求的时区对不上，解决办法是在 JDBC URL 后面加上时区参数：

properties复制spring.datasource.url=jdbc:mysql://localhost:3306/sneaker_shop?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true

allowPublicKeyRetrieval=true 主要是解决 MySQL 8.0 使用 caching_sha2_password 认证插件时连不上报错的问题。这两个参数加完，90% 的本地连接坑就解决了。驱动版本也要检查一下，Spring Boot 2.7.x 里如果你不加版本号，默认驱动的 com.mysql.cj.jdbc.Driver 才对得上 MySQL 8；老项目里那种 com.mysql.jdbc.Driver 已经过时了。

6.2 SQL 文件导入失败或中文乱码

导入数据库的 SQL 文件如果包含中文，建议在建库语句里显式指定字符集：

sql复制CREATE DATABASE sneaker_shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

如果导入的是 MySQL 8 生成的 SQL，拿到 MySQL 5.7 导入，某些语法可能不兼容。反过来，5.7 的 SQL 导入 8.0 大概率问题不大。最稳妥的办法是在你本机用的 MySQL 版本上重新导出一份 SQL，然后提交到压缩包里。别人拿到的 SQL 文件尽可能和文档里写的环境一致，这能省掉很多演示前才发现跑不起来的尴尬。

6.3 端口被占用和跨域问题

后端默认 8080 端口，前端页面前后分离开发时也要占用一个端口，比如 9090。如果启动时日志显示 Port 8080 was already in use.，在 Windows 上打开命令行执行：

bash复制netstat -ano | findstr 8080

看到 PID 之后进任务管理器结束对应进程，或者直接改 application.yml 里的 server.port。跨域报错的信息是 Access to XMLHttpRequest ... blocked by CORS policy，解决办法是在后端写一个实现 WebMvcConfigurer 的配置类，指定允许的来源 http://localhost:9090。这个配置虽然简单，但你要是不知道有这回事，能卡你半天。

6.4 页面图片打不开、请求 404

很多同学把图片相对路径存在数据库，但真实图片并没有放到项目对应目录。前端拿到 /upload/1.png 直接访问，后端没有做静态资源映射，于是图片全裂。一个简单做法是在后端配置里将本地磁盘目录映射成 /upload/**，同时数据库里保存完整的访问地址。如果项目是纯前端展示，图片也可能直接用外部图床存链接更省事。

404 还有一个原因：接口路径写错了。我建议后端启动后先用 Postman 或 Apifox 测试接口，确认接口本身通了再去调页面。这样可以快速区分问题是出在后端还是前端联调层。

6.5 给自己留一份环境快速启动单

做过几套类似系统之后，我的习惯是在项目根目录放一个 README.md 或者 启动说明.txt，把环境要求、MySQL 版本、JDK 版本、启动顺序都写清楚。这样不仅方便老师验收，也方便一个月后的自己重新打开这个项目。我已经数不清多少次因为换电脑找不到当时的密码和启动流程而想砸键盘了。

最后再分享一点个人心得：这类课程设计项目真正拉开差距的地方不在代码量，而在数据模型合理性和交付物完整度。如果你时间紧张，优先把数据库表结构反复打磨，把订单和库存流程理顺，然后老老实实写清楚文档。源码可以从模仿开始，但数据库设计必须自己推导，因为答辩老师最喜欢问的偏偏就是“这个字段为什么这么设计”“这张表和那张表什么关系”。当你能对着自己的 ER 图把每个关联讲明白，这个项目就算真正过关了。

球鞋购物系统设计与实现：数据库建模到订单核心逻辑详解