基于Java的球鞋交易平台小程序：从数据库设计到答辩全攻略

做计算机毕设的同学，十个里面少说有三四个会碰电商类项目，而球鞋商城又是这类题目里最典型的方向之一。表面上看就是"用户逛鞋、下单，管理员管商品、发货"，但真动手做的时候，登录鉴权、商品模型、购物车、订单状态、库存扣减、管理后台，每个模块都能抠出一堆细节。这篇就围绕"基于Java的球鞋交易平台小程序"这套常见的毕设题目，把技术选型、数据库设计、核心接口实现、踩坑记录和答辩准备完整过一遍。无论你是拿这个题目做毕设，还是想练手做一个能写进简历的全栈项目，按这条路线走，能少走很多弯路。

1. 项目概述：先搞清楚你要做的是什么

1.1 这套系统的题眼在哪

球鞋商城本质上是一个"用户端 + 管理端 + 后端服务"的电商系统。用户端跑在小程序里，负责商品浏览、分类筛选、搜索、购物车、下单、支付、订单查询和收货地址管理；管理端是网页后台，负责商品上下架、库存管理、订单处理、发货、退款和基础数据统计。一句话概括：让用户在小程序里把鞋买走，让管理员在后台把货管住。

毕设评分一般看四点：功能完整度、代码规范性、文档与演示的条理、以及能不能讲清楚设计理由。这套题目的优点是模块边界清晰，每个功能都能对应到一门课的知识点，比如数据库课的表设计、软件工程的流程图、Web 课的接口开发，方便往课程知识点上靠。缺点也很明显：如果你只做一个 CRUD 套壳，没有任何防御性设计，答辩被追问两句就容易露怯。

球鞋这个品类相比普通图书商城，最大的差异点是尺码。常规商品一个商品一个库存，球鞋必须做到"同一款鞋，不同尺码不同库存"。这就引出了 SKU（规格库存）的概念，也是整个项目业务建模上最值得讲的差异点。把 SKU、快照、库存扣减这几件事想清楚，这个项目的含金量一下就上去了。

1.2 整体技术栈一览

先给总体选型，后面的章节再逐项解释理由：

层次	选型	说明
用户端	小程序原生开发	上手门槛低，毕设不需要跨端
管理后台	Vue + Element UI 或服务端渲染模板	二选一，Vue 在简历上加分
后端	Java + Spring Boot	核心框架，生态成熟，学习资料最多
ORM	MyBatis / MyBatis-Plus	手写 SQL 可控性强，Plus 省样板代码
数据库	MySQL 8.x	免费，本地开发最顺手
缓存	Redis（可选）	做 token 或首页缓存，属于加分项

如果毕业设计题目没有强制指定前端技术，小程序端我建议用原生开发而不是跨端框架。理由后面细说，这里先给结论：毕设求稳，原生那一套工具链最简单，官方文档和网上教程都多，调试也不需要额外配置。

1.3 这篇内容适合谁

适合三类人：

• 准备做此类毕设、想提前知道完整开发路线的在校学生；
• 想用"球鞋商城"练手，把 Java 全栈能力串起来的人；
• 已经写了不少代码但经常在登录、下单、库存这些环节卡住，想看看别人怎么解坑的人。

如果是完全没写过 Java 的小白，建议先去把基础语法、Maven 使用、MySQL 基本操作过一遍再开始，否则大概率卡在环境配置上就放弃了。

2. 技术选型解析：为什么是 Java + Spring Boot + 小程序

2.1 后端框架：Spring Boot 赢在"省事"

大部分高校的 Java Web 课程以 Spring 为主线，题目里带"基于 Java"通常意味着导师默认你用 Spring 技术栈。Spring Boot 对比传统 Spring 最大的优势用一个字概括就是"省"：内嵌容器，不用再单独装 Tomcat；自动配置，不用写一堆 XML 和繁琐的 bean 配置；starter 依赖机制，引入一个依赖就是一组完整能力。

ORM 选型上，实际项目里常见三个流派：

• 纯 MyBatis：SQL 全手写，灵活但代码量大，一张表一套 CRUD 就能写一上午；
• MyBatis-Plus：内置通用 Mapper，单表 CRUD 不用写 SQL，分页、条件构造器都现成，对毕设来说是效率最优解；
• Spring Data JPA：写起来少，但复杂查询的 SQL 控制不灵活，答辩时解释表关联也费劲。

我建议用 MyBatis-Plus，主键策略、逻辑删除、自动填充这些功能都能直接复用，代码量能砍掉三分之一。而且它官方文档很全，出了问题一搜就有答案，不需要去啃源码。毕设项目的时间很紧，把时间花在业务逻辑上，远比花在配置上划算。

2.2 小程序端：原生开发优于跨端框架

市面上有不少跨端框架，可以让一套代码同时发布到小程序、App、H5。但毕设场景下，跨端不是刚需，你只需要在小程序端跑通。原生开发的直观好处有三个：

• 不用担心框架版本和编译器兼容问题，工具链最简单；
• 官方开发者工具的调试体验最直接，页面、网络、存储都能可视化解；
• 相关教程资料数量远多于跨端框架，遇到问题搜起来快。

如果你对前端比较熟，管理后台用 Vue + Element UI 做一套就够，Table、Form、Dialog 这些组件都是现成的，商品管理页基本是拼组件。如果不想引入完整的 Node 构建链路，也可以用服务端渲染模板写后台，一条链路从 Java 到页面模板跑通，对不熟悉前端的同学更友好。管理后台的技术路线可以自由选，不影响后端核心，答辩时讲清楚"为什么这么选"就行。

2.3 开发环境与运行部署

本地开发环境清单：

• JDK 8 或 17，Spring Boot 2.7 以上基本都能跑；
• Maven 3.6+；
• MySQL 8.x，字符集建议 utf8mb4，否则商品名称里有表情或生僻字会乱码；
• 数据库客户端工具，看自己习惯选一个顺手的即可；
• 小程序开发者工具，注册一个小程序测试号就能用。

后端在毕设阶段跑本机就行，小程序开发者工具里勾选"不校验合法域名"即可让真机预览访问本机后端。如果要让别人远程访问，后端放到一台云服务器上，小程序端填写服务器公网地址。这样仅演示足够，不必走到正式发布那一步。

注意：小程序正式发布时，所有网络请求要求 HTTPS 且域名需要备案。毕设答辩一般不需要走到那一步，在开发者工具里能完整体验即可。但如果你计划在线上远程演示，提前把 HTTPS 证书问题考虑进去，别到当天才发现请求全被拦。

Redis 要不要引入？我的态度是：不是必须，但引入了会是加分项。可以用它缓存首页轮播图和热门商品，降低 MySQL 查询压力；也可以用 Redis 存储验证码。如果时间紧张，先用本地内存缓存顶着，答辩时说明"生产环境会替换为 Redis"也是一种合理的演进思路。

3. 系统设计与功能模块拆解

3.1 用户登录与鉴权：小程序独有的登录链路

小程序登录和普通网页登录最大的区别：没有账号密码，靠平台提供的身份标识。完整链路是：

1. 小程序端调用登录 API，拿到一个临时 code；
2. 后端拿 code 请求平台官方接口，换取该用户的 openid（平台内唯一身份标识）；
3. 后端拿 openid 查用户表，不存在就自动给他建一个账号；
4. 后端签发 JWT token 返回小程序端，小程序把 token 存进本地缓存，之后所有请求头里带这个 token；
5. 后端写一个拦截器，统一校验 token，并从中解析出当前用户 id。

链路看着简单，但有几个细节特别容易踩：

• code 只能用一次且有有效期。后端拿不到 openid 时，优先排查是不是 code 被重复使用了；
• openid 是业务真正的用户标识，但不要把它直接当成 userId 存进订单表。openid 是很长的一串字符，作为外键既浪费空间，又会在日志里暴露用户身份。正确做法是 user 表建自增主键 id，openid 单独一个字段，业务表只跟 user.id 关联；
• JWT 密钥放在服务端配置里，不要写死在小程序端代码中，密钥泄露等于整个登录体系失效；
• token 过期时间，演示场景设置 7 天比较省事，避免演示到一半登录态失效，答辩时可以提一句"生产环境会按安全策略调短并配合续期机制"。

3.2 商品模块：分类、SKU、图片怎么建模

商品模块建议拆成四张表：

• category：分类（篮球鞋、跑鞋、板鞋等）；
• product：商品主体（名称、品牌、价格、销量、上下架状态、详情描述）；
• sku：SKU（尺码、库存、以及尺码对应的价格差）；
• product_image：商品图（多图，区分是否为主图）。

球鞋的商品信息必须挂在 SKU 上。比如某款鞋有 40 到 45 六个尺码，每个尺码库存数量不同，详情页用户选尺码时前端要显示"该尺码有货/无货"，后端下单时也必须重新校验一次，不能只信前端判断。

商品接口建议按场景拆分，而不是按表设计：

• 列表接口（分页）：只返回主图、标题、售价、品牌这些 List 页要用的信息，不做多表全字段查询；
• 详情接口：返回商品全部字段 + SKU 列表 + 图片列表，一次请求给前端一个聚合对象。

如果列表接口把详情字段全查出来，网络传输量会白白翻几倍。这是一个基本思维：接口按调用场景裁剪字段。

搜索和筛选：毕设阶段不需要引入搜索引擎，用 MySQL 的 like 查询加分类、品牌、价格区间条件拼接就够。MyBatis-Plus 的条件构造器写动态 SQL 很方便，拼条件时逻辑清晰，也不容易漏字段。

3.3 购物车与订单：状态流转是灵魂

购物车数据存前端还是存后端？建议存后端。原因很实在：用户换设备购物车不丢；管理端可以统计加购数据；订单生成时直接把选中购物车项提交到后端，逻辑统一。代价是"未登录不能加购"，需要加购时引导用户先登录。

订单模块的核心是状态流转，用数字状态字段配合枚举：

• 0 待支付：下单成功但没付款；
• 1 已支付 / 待发货：模拟支付成功后进入；
• 2 已发货：管理后台点击发货；
• 3 已完成：用户确认收货；
• 4 已取消：用户取消，或超时未支付（毕设一般不做超时自动取消，可以口头说明用延迟任务能实现）；
• 5 已退款：管理员处理退款后进入。

下单的时序大致是：

1. 用户从购物车勾选商品，提交结算；
2. 后端校验用户身份、收货地址、商品上下架状态、SKU 库存；
3. 按数据库当前价格计算订单金额，不要信前端传来的价格；
4. 生成订单主表 + 订单明细表；
5. 扣减 SKU 库存；
6. 模拟支付成功后，订单状态置为"已支付"。

第 3 步和第 5 步是关键。后端重新从库取价格，避免用户改前端参数伪造低价；库存扣减用乐观锁，避免并发超卖。具体实现放在第 5 章讲。

3.4 管理后台：不要把 CRUD 做成一坨

管理后台如果只是给五张表各配一个增删改查页面，答辩时非常平淡。至少要体现出三个管理流程：

• 商品生命周期：新增商品（含 SKU 批量生成）→ 上下架 → 库存调整；
• 订单生命周期：按状态筛选 → 查看详情 → 发货 → 退款处理；
• 数据看板：当日/近 7 日订单量、销售额、销量 TOP 10 商品。

数据看板用几条 SQL 就能实现。按日期 group by 订单表统计金额，按商品维度 group by 订单明细统计销量。前端用卡片加简单图表组件展示，整个项目的呈现效果立刻不一样，这也是答辩时最容易拿到"亮点分"的一个模块。

权限上做个简化版：管理员单独一张表，登录后发放管理员 token，后端指定接口校验管理员角色。不需要引入完整的安全框架，拦截器加角色判断在毕设体量下完全够用。

4. 数据库设计：核心表结构与关键约束

4.1 核心表总览

表名	用途	关键字段
user	用户	id, openid, nickname, avatar, create_time
address	收货地址	id, user_id, name, phone, region, detail
category	分类	id, name, sort
product	商品	id, category_id, name, brand, price, sales, status
sku	规格库存	id, product_id, size, stock, price
product_image	商品图	id, product_id, url, is_main
cart	购物车	id, user_id, sku_id, quantity
orders	订单	id, order_no, user_id, address_id, total_amount, status
order_item	订单明细	id, order_id, sku_id, product_name, size, price, quantity
banner	首页轮播	id, image_url, link_type, sort

字段设计有几个原则值得坚持：

• 金额一律 DECIMAL(10,2)，禁止 float/double。浮点数算金额会出现 0.1+0.2 不等于 0.3 的问题，答辩时主动提到这点是加分项；
• 时间字段统一用 datetime，配合 MyBatis-Plus 自动填充，插入时自动写 create_time，更新时自动写 update_time；
• 状态字段用 tinyint 加注释，不要用"待支付"这种字符串存库，扩展性差还容易写错；
• 删除采用逻辑删除，MyBatis-Plus 的 @TableLogic 注解直接支持，避免误删真数据。

4.2 订单与订单明细的快照设计

orders 和 order_item 是一对多关系。订单主表存总金额、状态、收货信息快照；明细表存每件商品的商品名、尺码、单价快照。为什么叫快照？因为商品后来可能改名、改价甚至下架，历史订单里不能跟着变——用户看到的历史订单，就该是购买时刻的商品信息和价格。所以 order_item 要冗余存 product_name、size、price、image 等字段，而不是每次展示订单再去 join 商品表现查。

这个设计细节值得在答辩时主动讲：先抛问题"如果商品下架了订单怎么展示？"，再引出快照方案，老师会觉得你确实考虑过真实业务场景。

4.3 核心建表 SQL 参考

CREATE TABLE `product` ( `id` bigint NOT NULL AUTO_INCREMENT, `category_id` bigint NOT NULL COMMENT '分类id', `name` varchar(128) NOT NULL COMMENT '商品名称', `brand` varchar(64) DEFAULT NULL COMMENT '品牌', `price` decimal(10,2) NOT NULL COMMENT '售价', `sales` int NOT NULL DEFAULT 0 COMMENT '销量', `status` tinyint NOT NULL DEFAULT 0 COMMENT '0下架 1上架', `deleted` tinyint NOT NULL DEFAULT 0 COMMENT '逻辑删除', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_category_status` (`category_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表'; CREATE TABLE `sku` ( `id` bigint NOT NULL AUTO_INCREMENT, `product_id` bigint NOT NULL COMMENT '商品id', `size` varchar(16) NOT NULL COMMENT '尺码', `stock` int NOT NULL DEFAULT 0 COMMENT '库存', `price` decimal(10,2) DEFAULT NULL COMMENT '尺码差价后的价格', `version` int NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', PRIMARY KEY (`id`), KEY `idx_product` (`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='规格库存表'; CREATE TABLE `orders` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号', `user_id` bigint NOT NULL, `address_id` bigint NOT NULL, `total_amount` decimal(10,2) NOT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消 5已退款', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_status` (`user_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表'; CREATE TABLE `order_item` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_id` bigint NOT NULL, `sku_id` bigint NOT NULL, `product_name` varchar(128) NOT NULL COMMENT '商品名快照', `size` varchar(16) NOT NULL COMMENT '尺码快照', `price` decimal(10,2) NOT NULL COMMENT '单价快照', `quantity` int NOT NULL, PRIMARY KEY (`id`), KEY `idx_order` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

索引设计的思路：订单列表页最常见的查询是"某个用户按状态查订单"，所以建 idx_user_status；商品列表页最常见的是"某分类下查上架商品"，建 idx_category_status。索引不是越多越好，建索引要想清楚查询场景，否则每次写入都是在给索引付维护成本。

5. 实操开发：核心环节的实现细节

5.1 工程初始化与统一响应

创建 Spring Boot 工程后，第一件事不是写业务代码，而是先把地基打好：

• 统一响应体 Result：code、message、data 三个字段；
• 全局异常处理器：业务异常返回约定错误码，系统异常返回 500 并记录日志；
• 拦截器注册：校验 JWT，放行登录接口和商品查询接口；
• 跨域配置：小程序端一般不涉及 CORS，但管理后台如果是独立前端服务，需要配跨域。

统一响应体的价值在联调时体现最明显：前端拿到一个稳定格式，才能写统一的拦截逻辑。约定 code=200 表示成功，401 表示登录失效，小程序端收到 401 就自动跳转登录页。这样所有接口都走同一条错误处理路径，不用每个页面单独兜错。

5.2 登录接口实现要点

登录接口的伪代码：

@PostMapping("/auth/login") public Result<String> login(@RequestBody LoginRequest req) { // 1. 调用平台接口，用 req.getCode() 换 openid String openid = authService.exchangeOpenid(req.getCode()); // 2. 查本地用户 User user = userMapper.selectOne( new LambdaQueryWrapper<User>().eq(User::getOpenid, openid)); if (user == null) { // 3. 新用户自动注册 user = new User(); user.setOpenid(openid); user.setNickname("球鞋用户" + randomSuffix()); userMapper.insert(user); } // 4. 签发 JWT String token = jwtUtil.generateToken(user.getId(), user.getRole()); return Result.ok(token); }

细节提示：openid 字段要建唯一索引，防止并发下同一用户重复注册。JWT 生成时把 userId 放进去，拦截器解析出来放进请求上下文，controller 里通过 @RequestAttribute("userId") 直接取用。

拦截器里的解析逻辑：

String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); } Claims claims = jwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId"));

注意：JWT 解析要单独捕获过期异常，捕获后返回 401，而不是让过期 token 带着脏身份继续往下走。这块写好了，前端登录态的自动刷新逻辑才接得上。

5.3 商品分页列表实现

分页的底层公式是LIMIT offset, size，其中offset = (current - 1) * size。比如每页 10 条，第一页 offset=0，第二页 offset=10。MyBatis-Plus 分页插件封装了过程，但原理自己要清楚，答辩被追问 offset 计算时至少能答上来。

public Page<ProductVO> pageProduct(int current, int size, Long categoryId, String keyword) { Page<Product> page = new Page<>(current, size); LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getStatus, 1); if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } if (StringUtils.hasText(keyword)) { wrapper.like(Product::getName, keyword); } wrapper.orderByDesc(Product::getSales); Page<Product> result = productMapper.selectPage(page, wrapper); // 转 VO，补充主图字段 return convertToVO(result); }

搜索用 like 拼接时注意：%和_是 SQL 通配符，用户如果输入这些字符会被当成通配处理。虽然不至于出安全问题，但搜索结果会异常。简单处理是转义，或接受这个限制并心里有数。演示时没人会刻意输入通配符，但代码里留这个心眼，是专业性的体现。

5.4 下单扣库存：事务与乐观锁

下单是最容易出现并发问题的地方。两个用户同时买同一个尺码的最后一件鞋，如果不做控制，两个人都会下单成功，但库存只有一件，这就是超卖。

解决方案是"事务 + 乐观锁"。在 sku 表加 version 字段，更新时带上旧的 version：

@Transactional public OrderVO createOrder(CreateOrderReq req) { // 1. 校验参数、收货地址、商品状态 // 2. 从库中取商品价格，计算总价 // 3. 生成订单号 String orderNo = generateOrderNo(); for (OrderItemReq item : req.getItems()) { // 4. 扣库存，乐观锁 int rows = skuMapper.reduceStock(item.getSkuId(), item.getQuantity()); if (rows == 0) { throw new BizException("库存不足或已发生变化，请重新加购"); } } // 5. 插入订单主表和明细 // 6. 返回订单号和模拟支付参数 }

reduceStock 对应的 SQL：

UPDATE sku SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{skuId} AND stock >= #{quantity}

更新影响行数为 0，说明库存不够，直接抛业务异常让用户重试。整个过程包在 @Transactional 里，任何一步失败整体回滚，不会出现"订单生成了但库存没扣"或"库存扣了但订单失败"的不一致。

订单号生成：不要用自增 id 当订单号，规则太容易被猜到。简单可靠的方案是 yyyyMMddHHmmss + 6 位随机数，并发不高的毕设场景足够。想更稳一点，在后面拼上用户 id 尾巴，进一步降低重复概率。

模拟支付：毕设一般不接真实支付通道，因为需要商户资质。做法是下单后弹一个"模拟支付"按钮，点击后调后端接口把订单状态改成已支付，同时增加商品销量。这里有个细节：管理后台统计销售额时，必须过滤掉待支付订单，只统计已支付以上状态的订单，否则数字全是错的。

5.5 图片上传与访问

商品图片是毕设里很容易翻车的地方。图片上传建议用本地磁盘存储：后端接收 MultipartFile，生成随机文件名防止冲突，保存到规定目录。访问时使用一个专门映射路径，比如把本地上传目录映射到 /images/**，前端图片地址拼接完整 URL 展示。

存储路径不要用绝对路径写死，改成配置文件里的 upload.dir 项，不同环境迁移方便。图片大小要校验，商品详情图一次传太多容易把请求体撑爆，设置单张大小上限（比如 5MB），超限返回友好提示。

注意：数据库里存的是图片相对路径而不是完整 URL，这样以后换域名、换服务器都不用改库，只要拼接规则变一下就行。

6. 踩坑记录与疑难排查

6.1 高频问题速查表

现象	常见原因	解决思路
登录接口报平台返回错误	code 已失效或参数名不对	确认 code 是一次性的，检查请求参数名是否拼错
真机预览请求本地后端失败	后端监听的是 localhost	后端改为监听 0.0.0.0，真机和电脑连同一局域网，填电脑局域网 IP
图片在手机上显示不出来	图片路径写成本地绝对路径	用后端完整图片访问 URL，并检查开发工具的域名白名单设置
日期显示成时间戳或英文格式	后端默认 JSON 序列化格式不友好	全局配置日期格式化，统一返回 yyyy-MM-dd HH:mm:ss
下单后库存没变化	事务没生效或扣减条件漏了 stock >= qty	检查 @Transactional 是否被同类内部调用绕过，确认 SQL 更新条件
接口 404	controller 路径或映射注解不对	看后端日志中的请求映射列表，对照前端请求路径排查
管理后台跨域报错	前后端独立部署时未配置 CORS	后端统一加跨域配置，或让管理后台与后端同域部署
删除分类后商品列表异常	未处理引用关联	删除前先校验是否有商品关联，必要时改为逻辑删除

6.2 一条实用的排查流程

我自己遇到问题，习惯先做三件事，顺序固定：

1. 打开开发者工具的 Network 面板，先看请求有没有发出去，再看返回的状态码和响应体；
2. 看后端控制台日志，接口进去了没有、SQL 打出来没有、有没有抛异常；
3. 用接口调试工具直接复制请求调用后端，排除小程序端因素。

定位顺序永远是"请求是否到达后端"开始，逐层往后推。不要一上来就怀疑框架有 bug，实际上 99% 的毕设问题出在路径写错、参数没传、状态没更新这三类。先把这三类排查完，再往深处想。

6.3 常规文档不会写的小细节

• 开发阶段把后端日志里的 SQL 打印打开，联调效率翻倍。MyBatis-Plus 里把日志实现配成标准输出即可，能看到每次请求执行的完整 SQL；
• 小程序端每个页面要做加载态和空状态。后端接口再稳，网络抖动时白屏在答辩现场非常难看；
• 管理后台的删除操作加确认弹窗，防止演示时手滑把商品误删；
• 答辩前全局搜一遍硬编码地址、测试数据、多余日志，该清的清掉；
• 数据库备份：答辩前把 MySQL 数据目录拷一份到移动硬盘，万一电脑出问题，不至于现场翻车。

7. 答辩与演示的准备要点

7.1 演示脚本怎么准备

演示环节最怕冷场和手忙脚乱，建议按一条主线走：

1. 先演示用户端核心闭环：注册登录 → 逛首页 → 搜索或筛选某款鞋 → 查看详情选尺码 → 加购 → 下单 → 模拟支付 → 在订单列表看到已支付；
2. 再切管理后台：登录 → 看销售数据看板 → 处理订单发货 → 改库存 → 回到小程序端刷新，验证商品和库存变化；
3. 最后展示一个边界情况：把某 SKU 库存改成 0，小程序端立刻显示该尺码无货。

整个过程控制在 8 分钟以内。每个操作前先讲"这一步要验证什么"，比闷头点鼠标强得多。演示用的账号、商品数据提前准备好，不要现场临时注册新账号。

7.2 高频追问与应对思路

老师可能问	怎么答
库存并发问题怎么解决？	先讲超卖场景，再讲乐观锁更新 SQL，说明为什么影响行数为 0 就抛异常
为什么用 JWT 而不是 Session？	无状态、适合小程序端、扩容友好，顺带说明 JWT 过期机制
价格为什么用 DECIMAL？	浮点精度问题，举 0.1+0.2 不等于 0.3 的例子
订单状态为什么用数字不用字符串？	数字存储小、索引友好、配合枚举可读性也好
搜索为什么不用搜索引擎？	当前数据量级下 MySQL like 完全够，引入搜索引擎会让系统复杂度大幅上升
支付是真的吗？	真实支付需要商户资质和回调验签，毕设采用模拟支付，但接口设计预留了真实支付回调的对接位

回答时记住一个逻辑：先讲场景，再讲方案，最后讲为什么，不要一上来甩结论。老师追问的往往不是某个 API 怎么调，而是你有没有想过"它为什么这样设计"。

7.3 一点过来人的体会

这个题目我见过很多人做，说句实在话，能拿高分的往往不是代码写得最花哨的，而是那些"每做一个模块都清楚自己在解决什么问题"的人。库存扣减为什么要加条件、订单明细为什么要快照、token 为什么要过期，这些问题哪怕你只是自己在脑子里过一遍，答辩时的底气都不一样。球鞋商城只是个壳，壳里面的电商业务逻辑、并发思想、数据一致性，才是这个题目真正给你的东西。拿到题目先别急着敲代码，把用户、商品、订单、库存这条链路过一遍，想清楚边界和异常，后面的开发就是往框架里填肉的事。最后提醒一句：提前两周把系统完整跑通、录一遍演示视频，比答辩前一晚熬夜改 bug 有用得多。