做计算机毕设的同学十个里面少说有三四个会碰电商类项目而球鞋商城又是这类题目里最典型的方向之一。表面上看就是用户逛鞋、下单管理员管商品、发货但真动手做的时候登录鉴权、商品模型、购物车、订单状态、库存扣减、管理后台每个模块都能抠出一堆细节。这篇就围绕基于Java的球鞋交易平台小程序这套常见的毕设题目把技术选型、数据库设计、核心接口实现、踩坑记录和答辩准备完整过一遍。无论你是拿这个题目做毕设还是想练手做一个能写进简历的全栈项目按这条路线走能少走很多弯路。1. 项目概述先搞清楚你要做的是什么1.1 这套系统的题眼在哪球鞋商城本质上是一个用户端 管理端 后端服务的电商系统。用户端跑在小程序里负责商品浏览、分类筛选、搜索、购物车、下单、支付、订单查询和收货地址管理管理端是网页后台负责商品上下架、库存管理、订单处理、发货、退款和基础数据统计。一句话概括让用户在小程序里把鞋买走让管理员在后台把货管住。毕设评分一般看四点功能完整度、代码规范性、文档与演示的条理、以及能不能讲清楚设计理由。这套题目的优点是模块边界清晰每个功能都能对应到一门课的知识点比如数据库课的表设计、软件工程的流程图、Web 课的接口开发方便往课程知识点上靠。缺点也很明显如果你只做一个 CRUD 套壳没有任何防御性设计答辩被追问两句就容易露怯。球鞋这个品类相比普通图书商城最大的差异点是尺码。常规商品一个商品一个库存球鞋必须做到同一款鞋不同尺码不同库存。这就引出了 SKU规格库存的概念也是整个项目业务建模上最值得讲的差异点。把 SKU、快照、库存扣减这几件事想清楚这个项目的含金量一下就上去了。1.2 整体技术栈一览先给总体选型后面的章节再逐项解释理由层次选型说明用户端小程序原生开发上手门槛低毕设不需要跨端管理后台Vue Element UI 或服务端渲染模板二选一Vue 在简历上加分后端Java Spring Boot核心框架生态成熟学习资料最多ORMMyBatis / 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 选型上实际项目里常见三个流派纯 MyBatisSQL 全手写灵活但代码量大一张表一套 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 或 17Spring Boot 2.7 以上基本都能跑Maven 3.6MySQL 8.x字符集建议 utf8mb4否则商品名称里有表情或生僻字会乱码数据库客户端工具看自己习惯选一个顺手的即可小程序开发者工具注册一个小程序测试号就能用。后端在毕设阶段跑本机就行小程序开发者工具里勾选不校验合法域名即可让真机预览访问本机后端。如果要让别人远程访问后端放到一台云服务器上小程序端填写服务器公网地址。这样仅演示足够不必走到正式发布那一步。注意小程序正式发布时所有网络请求要求 HTTPS 且域名需要备案。毕设答辩一般不需要走到那一步在开发者工具里能完整体验即可。但如果你计划在线上远程演示提前把 HTTPS 证书问题考虑进去别到当天才发现请求全被拦。Redis 要不要引入我的态度是不是必须但引入了会是加分项。可以用它缓存首页轮播图和热门商品降低 MySQL 查询压力也可以用 Redis 存储验证码。如果时间紧张先用本地内存缓存顶着答辩时说明生产环境会替换为 Redis也是一种合理的演进思路。3. 系统设计与功能模块拆解3.1 用户登录与鉴权小程序独有的登录链路小程序登录和普通网页登录最大的区别没有账号密码靠平台提供的身份标识。完整链路是小程序端调用登录 API拿到一个临时 code后端拿 code 请求平台官方接口换取该用户的 openid平台内唯一身份标识后端拿 openid 查用户表不存在就自动给他建一个账号后端签发 JWT token 返回小程序端小程序把 token 存进本地缓存之后所有请求头里带这个 token后端写一个拦截器统一校验 token并从中解析出当前用户 id。链路看着简单但有几个细节特别容易踩code 只能用一次且有有效期。后端拿不到 openid 时优先排查是不是 code 被重复使用了openid 是业务真正的用户标识但不要把它直接当成 userId 存进订单表。openid 是很长的一串字符作为外键既浪费空间又会在日志里暴露用户身份。正确做法是 user 表建自增主键 idopenid 单独一个字段业务表只跟 user.id 关联JWT 密钥放在服务端配置里不要写死在小程序端代码中密钥泄露等于整个登录体系失效token 过期时间演示场景设置 7 天比较省事避免演示到一半登录态失效答辩时可以提一句生产环境会按安全策略调短并配合续期机制。3.2 商品模块分类、SKU、图片怎么建模商品模块建议拆成四张表category分类篮球鞋、跑鞋、板鞋等product商品主体名称、品牌、价格、销量、上下架状态、详情描述skuSKU尺码、库存、以及尺码对应的价格差product_image商品图多图区分是否为主图。球鞋的商品信息必须挂在 SKU 上。比如某款鞋有 40 到 45 六个尺码每个尺码库存数量不同详情页用户选尺码时前端要显示该尺码有货/无货后端下单时也必须重新校验一次不能只信前端判断。商品接口建议按场景拆分而不是按表设计列表接口分页只返回主图、标题、售价、品牌这些 List 页要用的信息不做多表全字段查询详情接口返回商品全部字段 SKU 列表 图片列表一次请求给前端一个聚合对象。如果列表接口把详情字段全查出来网络传输量会白白翻几倍。这是一个基本思维接口按调用场景裁剪字段。搜索和筛选毕设阶段不需要引入搜索引擎用 MySQL 的 like 查询加分类、品牌、价格区间条件拼接就够。MyBatis-Plus 的条件构造器写动态 SQL 很方便拼条件时逻辑清晰也不容易漏字段。3.3 购物车与订单状态流转是灵魂购物车数据存前端还是存后端建议存后端。原因很实在用户换设备购物车不丢管理端可以统计加购数据订单生成时直接把选中购物车项提交到后端逻辑统一。代价是未登录不能加购需要加购时引导用户先登录。订单模块的核心是状态流转用数字状态字段配合枚举0 待支付下单成功但没付款1 已支付 / 待发货模拟支付成功后进入2 已发货管理后台点击发货3 已完成用户确认收货4 已取消用户取消或超时未支付毕设一般不做超时自动取消可以口头说明用延迟任务能实现5 已退款管理员处理退款后进入。下单的时序大致是用户从购物车勾选商品提交结算后端校验用户身份、收货地址、商品上下架状态、SKU 库存按数据库当前价格计算订单金额不要信前端传来的价格生成订单主表 订单明细表扣减 SKU 库存模拟支付成功后订单状态置为已支付。第 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_timeaddress收货地址id, user_id, name, phone, region, detailcategory分类id, name, sortproduct商品id, category_id, name, brand, price, sales, statussku规格库存id, product_id, size, stock, priceproduct_image商品图id, product_id, url, is_maincart购物车id, user_id, sku_id, quantityorders订单id, order_no, user_id, address_id, total_amount, statusorder_item订单明细id, order_id, sku_id, product_name, size, price, quantitybanner首页轮播id, image_url, link_type, sort字段设计有几个原则值得坚持金额一律 DECIMAL(10,2)禁止 float/double。浮点数算金额会出现 0.10.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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;索引设计的思路订单列表页最常见的查询是某个用户按状态查订单所以建 idx_user_status商品列表页最常见的是某分类下查上架商品建 idx_category_status。索引不是越多越好建索引要想清楚查询场景否则每次写入都是在给索引付维护成本。5. 实操开发核心环节的实现细节5.1 工程初始化与统一响应创建 Spring Boot 工程后第一件事不是写业务代码而是先把地基打好统一响应体 Resultcode、message、data 三个字段全局异常处理器业务异常返回约定错误码系统异常返回 500 并记录日志拦截器注册校验 JWT放行登录接口和商品查询接口跨域配置小程序端一般不涉及 CORS但管理后台如果是独立前端服务需要配跨域。统一响应体的价值在联调时体现最明显前端拿到一个稳定格式才能写统一的拦截逻辑。约定 code200 表示成功401 表示登录失效小程序端收到 401 就自动跳转登录页。这样所有接口都走同一条错误处理路径不用每个页面单独兜错。5.2 登录接口实现要点登录接口的伪代码PostMapping(/auth/login) public ResultString login(RequestBody LoginRequest req) { // 1. 调用平台接口用 req.getCode() 换 openid String openid authService.exchangeOpenid(req.getCode()); // 2. 查本地用户 User user userMapper.selectOne( new LambdaQueryWrapperUser().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 条第一页 offset0第二页 offset10。MyBatis-Plus 分页插件封装了过程但原理自己要清楚答辩被追问 offset 计算时至少能答上来。public PageProductVO pageProduct(int current, int size, Long categoryId, String keyword) { PageProduct page new Page(current, size); LambdaQueryWrapperProduct 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); PageProduct result productMapper.selectPage(page, wrapper); // 转 VO补充主图字段 return convertToVO(result); }搜索用 like 拼接时注意%和_是 SQL 通配符用户如果输入这些字符会被当成通配处理。虽然不至于出安全问题但搜索结果会异常。简单处理是转义或接受这个限制并心里有数。演示时没人会刻意输入通配符但代码里留这个心眼是专业性的体现。5.4 下单扣库存事务与乐观锁下单是最容易出现并发问题的地方。两个用户同时买同一个尺码的最后一件鞋如果不做控制两个人都会下单成功但库存只有一件这就是超卖。解决方案是事务 乐观锁。在 sku 表加 version 字段更新时带上旧的 versionTransactional 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 对应的 SQLUPDATE 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 更新条件接口 404controller 路径或映射注解不对看后端日志中的请求映射列表对照前端请求路径排查管理后台跨域报错前后端独立部署时未配置 CORS后端统一加跨域配置或让管理后台与后端同域部署删除分类后商品列表异常未处理引用关联删除前先校验是否有商品关联必要时改为逻辑删除6.2 一条实用的排查流程我自己遇到问题习惯先做三件事顺序固定打开开发者工具的 Network 面板先看请求有没有发出去再看返回的状态码和响应体看后端控制台日志接口进去了没有、SQL 打出来没有、有没有抛异常用接口调试工具直接复制请求调用后端排除小程序端因素。定位顺序永远是请求是否到达后端开始逐层往后推。不要一上来就怀疑框架有 bug实际上 99% 的毕设问题出在路径写错、参数没传、状态没更新这三类。先把这三类排查完再往深处想。6.3 常规文档不会写的小细节开发阶段把后端日志里的 SQL 打印打开联调效率翻倍。MyBatis-Plus 里把日志实现配成标准输出即可能看到每次请求执行的完整 SQL小程序端每个页面要做加载态和空状态。后端接口再稳网络抖动时白屏在答辩现场非常难看管理后台的删除操作加确认弹窗防止演示时手滑把商品误删答辩前全局搜一遍硬编码地址、测试数据、多余日志该清的清掉数据库备份答辩前把 MySQL 数据目录拷一份到移动硬盘万一电脑出问题不至于现场翻车。7. 答辩与演示的准备要点7.1 演示脚本怎么准备演示环节最怕冷场和手忙脚乱建议按一条主线走先演示用户端核心闭环注册登录 → 逛首页 → 搜索或筛选某款鞋 → 查看详情选尺码 → 加购 → 下单 → 模拟支付 → 在订单列表看到已支付再切管理后台登录 → 看销售数据看板 → 处理订单发货 → 改库存 → 回到小程序端刷新验证商品和库存变化最后展示一个边界情况把某 SKU 库存改成 0小程序端立刻显示该尺码无货。整个过程控制在 8 分钟以内。每个操作前先讲这一步要验证什么比闷头点鼠标强得多。演示用的账号、商品数据提前准备好不要现场临时注册新账号。7.2 高频追问与应对思路老师可能问怎么答库存并发问题怎么解决先讲超卖场景再讲乐观锁更新 SQL说明为什么影响行数为 0 就抛异常为什么用 JWT 而不是 Session无状态、适合小程序端、扩容友好顺带说明 JWT 过期机制价格为什么用 DECIMAL浮点精度问题举 0.10.2 不等于 0.3 的例子订单状态为什么用数字不用字符串数字存储小、索引友好、配合枚举可读性也好搜索为什么不用搜索引擎当前数据量级下 MySQL like 完全够引入搜索引擎会让系统复杂度大幅上升支付是真的吗真实支付需要商户资质和回调验签毕设采用模拟支付但接口设计预留了真实支付回调的对接位回答时记住一个逻辑先讲场景再讲方案最后讲为什么不要一上来甩结论。老师追问的往往不是某个 API 怎么调而是你有没有想过它为什么这样设计。7.3 一点过来人的体会这个题目我见过很多人做说句实在话能拿高分的往往不是代码写得最花哨的而是那些每做一个模块都清楚自己在解决什么问题的人。库存扣减为什么要加条件、订单明细为什么要快照、token 为什么要过期这些问题哪怕你只是自己在脑子里过一遍答辩时的底气都不一样。球鞋商城只是个壳壳里面的电商业务逻辑、并发思想、数据一致性才是这个题目真正给你的东西。拿到题目先别急着敲代码把用户、商品、订单、库存这条链路过一遍想清楚边界和异常后面的开发就是往框架里填肉的事。最后提醒一句提前两周把系统完整跑通、录一遍演示视频比答辩前一晚熬夜改 bug 有用得多。
做计算机毕设的同学十个里面少说有三四个会碰电商类项目而球鞋商城又是这类题目里最典型的方向之一。表面上看就是用户逛鞋、下单管理员管商品、发货但真动手做的时候登录鉴权、商品模型、购物车、订单状态、库存扣减、管理后台每个模块都能抠出一堆细节。这篇就围绕基于Java的球鞋交易平台小程序这套常见的毕设题目把技术选型、数据库设计、核心接口实现、踩坑记录和答辩准备完整过一遍。无论你是拿这个题目做毕设还是想练手做一个能写进简历的全栈项目按这条路线走能少走很多弯路。1. 项目概述先搞清楚你要做的是什么1.1 这套系统的题眼在哪球鞋商城本质上是一个用户端 管理端 后端服务的电商系统。用户端跑在小程序里负责商品浏览、分类筛选、搜索、购物车、下单、支付、订单查询和收货地址管理管理端是网页后台负责商品上下架、库存管理、订单处理、发货、退款和基础数据统计。一句话概括让用户在小程序里把鞋买走让管理员在后台把货管住。毕设评分一般看四点功能完整度、代码规范性、文档与演示的条理、以及能不能讲清楚设计理由。这套题目的优点是模块边界清晰每个功能都能对应到一门课的知识点比如数据库课的表设计、软件工程的流程图、Web 课的接口开发方便往课程知识点上靠。缺点也很明显如果你只做一个 CRUD 套壳没有任何防御性设计答辩被追问两句就容易露怯。球鞋这个品类相比普通图书商城最大的差异点是尺码。常规商品一个商品一个库存球鞋必须做到同一款鞋不同尺码不同库存。这就引出了 SKU规格库存的概念也是整个项目业务建模上最值得讲的差异点。把 SKU、快照、库存扣减这几件事想清楚这个项目的含金量一下就上去了。1.2 整体技术栈一览先给总体选型后面的章节再逐项解释理由层次选型说明用户端小程序原生开发上手门槛低毕设不需要跨端管理后台Vue Element UI 或服务端渲染模板二选一Vue 在简历上加分后端Java Spring Boot核心框架生态成熟学习资料最多ORMMyBatis / 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 选型上实际项目里常见三个流派纯 MyBatisSQL 全手写灵活但代码量大一张表一套 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 或 17Spring Boot 2.7 以上基本都能跑Maven 3.6MySQL 8.x字符集建议 utf8mb4否则商品名称里有表情或生僻字会乱码数据库客户端工具看自己习惯选一个顺手的即可小程序开发者工具注册一个小程序测试号就能用。后端在毕设阶段跑本机就行小程序开发者工具里勾选不校验合法域名即可让真机预览访问本机后端。如果要让别人远程访问后端放到一台云服务器上小程序端填写服务器公网地址。这样仅演示足够不必走到正式发布那一步。注意小程序正式发布时所有网络请求要求 HTTPS 且域名需要备案。毕设答辩一般不需要走到那一步在开发者工具里能完整体验即可。但如果你计划在线上远程演示提前把 HTTPS 证书问题考虑进去别到当天才发现请求全被拦。Redis 要不要引入我的态度是不是必须但引入了会是加分项。可以用它缓存首页轮播图和热门商品降低 MySQL 查询压力也可以用 Redis 存储验证码。如果时间紧张先用本地内存缓存顶着答辩时说明生产环境会替换为 Redis也是一种合理的演进思路。3. 系统设计与功能模块拆解3.1 用户登录与鉴权小程序独有的登录链路小程序登录和普通网页登录最大的区别没有账号密码靠平台提供的身份标识。完整链路是小程序端调用登录 API拿到一个临时 code后端拿 code 请求平台官方接口换取该用户的 openid平台内唯一身份标识后端拿 openid 查用户表不存在就自动给他建一个账号后端签发 JWT token 返回小程序端小程序把 token 存进本地缓存之后所有请求头里带这个 token后端写一个拦截器统一校验 token并从中解析出当前用户 id。链路看着简单但有几个细节特别容易踩code 只能用一次且有有效期。后端拿不到 openid 时优先排查是不是 code 被重复使用了openid 是业务真正的用户标识但不要把它直接当成 userId 存进订单表。openid 是很长的一串字符作为外键既浪费空间又会在日志里暴露用户身份。正确做法是 user 表建自增主键 idopenid 单独一个字段业务表只跟 user.id 关联JWT 密钥放在服务端配置里不要写死在小程序端代码中密钥泄露等于整个登录体系失效token 过期时间演示场景设置 7 天比较省事避免演示到一半登录态失效答辩时可以提一句生产环境会按安全策略调短并配合续期机制。3.2 商品模块分类、SKU、图片怎么建模商品模块建议拆成四张表category分类篮球鞋、跑鞋、板鞋等product商品主体名称、品牌、价格、销量、上下架状态、详情描述skuSKU尺码、库存、以及尺码对应的价格差product_image商品图多图区分是否为主图。球鞋的商品信息必须挂在 SKU 上。比如某款鞋有 40 到 45 六个尺码每个尺码库存数量不同详情页用户选尺码时前端要显示该尺码有货/无货后端下单时也必须重新校验一次不能只信前端判断。商品接口建议按场景拆分而不是按表设计列表接口分页只返回主图、标题、售价、品牌这些 List 页要用的信息不做多表全字段查询详情接口返回商品全部字段 SKU 列表 图片列表一次请求给前端一个聚合对象。如果列表接口把详情字段全查出来网络传输量会白白翻几倍。这是一个基本思维接口按调用场景裁剪字段。搜索和筛选毕设阶段不需要引入搜索引擎用 MySQL 的 like 查询加分类、品牌、价格区间条件拼接就够。MyBatis-Plus 的条件构造器写动态 SQL 很方便拼条件时逻辑清晰也不容易漏字段。3.3 购物车与订单状态流转是灵魂购物车数据存前端还是存后端建议存后端。原因很实在用户换设备购物车不丢管理端可以统计加购数据订单生成时直接把选中购物车项提交到后端逻辑统一。代价是未登录不能加购需要加购时引导用户先登录。订单模块的核心是状态流转用数字状态字段配合枚举0 待支付下单成功但没付款1 已支付 / 待发货模拟支付成功后进入2 已发货管理后台点击发货3 已完成用户确认收货4 已取消用户取消或超时未支付毕设一般不做超时自动取消可以口头说明用延迟任务能实现5 已退款管理员处理退款后进入。下单的时序大致是用户从购物车勾选商品提交结算后端校验用户身份、收货地址、商品上下架状态、SKU 库存按数据库当前价格计算订单金额不要信前端传来的价格生成订单主表 订单明细表扣减 SKU 库存模拟支付成功后订单状态置为已支付。第 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_timeaddress收货地址id, user_id, name, phone, region, detailcategory分类id, name, sortproduct商品id, category_id, name, brand, price, sales, statussku规格库存id, product_id, size, stock, priceproduct_image商品图id, product_id, url, is_maincart购物车id, user_id, sku_id, quantityorders订单id, order_no, user_id, address_id, total_amount, statusorder_item订单明细id, order_id, sku_id, product_name, size, price, quantitybanner首页轮播id, image_url, link_type, sort字段设计有几个原则值得坚持金额一律 DECIMAL(10,2)禁止 float/double。浮点数算金额会出现 0.10.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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;索引设计的思路订单列表页最常见的查询是某个用户按状态查订单所以建 idx_user_status商品列表页最常见的是某分类下查上架商品建 idx_category_status。索引不是越多越好建索引要想清楚查询场景否则每次写入都是在给索引付维护成本。5. 实操开发核心环节的实现细节5.1 工程初始化与统一响应创建 Spring Boot 工程后第一件事不是写业务代码而是先把地基打好统一响应体 Resultcode、message、data 三个字段全局异常处理器业务异常返回约定错误码系统异常返回 500 并记录日志拦截器注册校验 JWT放行登录接口和商品查询接口跨域配置小程序端一般不涉及 CORS但管理后台如果是独立前端服务需要配跨域。统一响应体的价值在联调时体现最明显前端拿到一个稳定格式才能写统一的拦截逻辑。约定 code200 表示成功401 表示登录失效小程序端收到 401 就自动跳转登录页。这样所有接口都走同一条错误处理路径不用每个页面单独兜错。5.2 登录接口实现要点登录接口的伪代码PostMapping(/auth/login) public ResultString login(RequestBody LoginRequest req) { // 1. 调用平台接口用 req.getCode() 换 openid String openid authService.exchangeOpenid(req.getCode()); // 2. 查本地用户 User user userMapper.selectOne( new LambdaQueryWrapperUser().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 条第一页 offset0第二页 offset10。MyBatis-Plus 分页插件封装了过程但原理自己要清楚答辩被追问 offset 计算时至少能答上来。public PageProductVO pageProduct(int current, int size, Long categoryId, String keyword) { PageProduct page new Page(current, size); LambdaQueryWrapperProduct 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); PageProduct result productMapper.selectPage(page, wrapper); // 转 VO补充主图字段 return convertToVO(result); }搜索用 like 拼接时注意%和_是 SQL 通配符用户如果输入这些字符会被当成通配处理。虽然不至于出安全问题但搜索结果会异常。简单处理是转义或接受这个限制并心里有数。演示时没人会刻意输入通配符但代码里留这个心眼是专业性的体现。5.4 下单扣库存事务与乐观锁下单是最容易出现并发问题的地方。两个用户同时买同一个尺码的最后一件鞋如果不做控制两个人都会下单成功但库存只有一件这就是超卖。解决方案是事务 乐观锁。在 sku 表加 version 字段更新时带上旧的 versionTransactional 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 对应的 SQLUPDATE 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 更新条件接口 404controller 路径或映射注解不对看后端日志中的请求映射列表对照前端请求路径排查管理后台跨域报错前后端独立部署时未配置 CORS后端统一加跨域配置或让管理后台与后端同域部署删除分类后商品列表异常未处理引用关联删除前先校验是否有商品关联必要时改为逻辑删除6.2 一条实用的排查流程我自己遇到问题习惯先做三件事顺序固定打开开发者工具的 Network 面板先看请求有没有发出去再看返回的状态码和响应体看后端控制台日志接口进去了没有、SQL 打出来没有、有没有抛异常用接口调试工具直接复制请求调用后端排除小程序端因素。定位顺序永远是请求是否到达后端开始逐层往后推。不要一上来就怀疑框架有 bug实际上 99% 的毕设问题出在路径写错、参数没传、状态没更新这三类。先把这三类排查完再往深处想。6.3 常规文档不会写的小细节开发阶段把后端日志里的 SQL 打印打开联调效率翻倍。MyBatis-Plus 里把日志实现配成标准输出即可能看到每次请求执行的完整 SQL小程序端每个页面要做加载态和空状态。后端接口再稳网络抖动时白屏在答辩现场非常难看管理后台的删除操作加确认弹窗防止演示时手滑把商品误删答辩前全局搜一遍硬编码地址、测试数据、多余日志该清的清掉数据库备份答辩前把 MySQL 数据目录拷一份到移动硬盘万一电脑出问题不至于现场翻车。7. 答辩与演示的准备要点7.1 演示脚本怎么准备演示环节最怕冷场和手忙脚乱建议按一条主线走先演示用户端核心闭环注册登录 → 逛首页 → 搜索或筛选某款鞋 → 查看详情选尺码 → 加购 → 下单 → 模拟支付 → 在订单列表看到已支付再切管理后台登录 → 看销售数据看板 → 处理订单发货 → 改库存 → 回到小程序端刷新验证商品和库存变化最后展示一个边界情况把某 SKU 库存改成 0小程序端立刻显示该尺码无货。整个过程控制在 8 分钟以内。每个操作前先讲这一步要验证什么比闷头点鼠标强得多。演示用的账号、商品数据提前准备好不要现场临时注册新账号。7.2 高频追问与应对思路老师可能问怎么答库存并发问题怎么解决先讲超卖场景再讲乐观锁更新 SQL说明为什么影响行数为 0 就抛异常为什么用 JWT 而不是 Session无状态、适合小程序端、扩容友好顺带说明 JWT 过期机制价格为什么用 DECIMAL浮点精度问题举 0.10.2 不等于 0.3 的例子订单状态为什么用数字不用字符串数字存储小、索引友好、配合枚举可读性也好搜索为什么不用搜索引擎当前数据量级下 MySQL like 完全够引入搜索引擎会让系统复杂度大幅上升支付是真的吗真实支付需要商户资质和回调验签毕设采用模拟支付但接口设计预留了真实支付回调的对接位回答时记住一个逻辑先讲场景再讲方案最后讲为什么不要一上来甩结论。老师追问的往往不是某个 API 怎么调而是你有没有想过它为什么这样设计。7.3 一点过来人的体会这个题目我见过很多人做说句实在话能拿高分的往往不是代码写得最花哨的而是那些每做一个模块都清楚自己在解决什么问题的人。库存扣减为什么要加条件、订单明细为什么要快照、token 为什么要过期这些问题哪怕你只是自己在脑子里过一遍答辩时的底气都不一样。球鞋商城只是个壳壳里面的电商业务逻辑、并发思想、数据一致性才是这个题目真正给你的东西。拿到题目先别急着敲代码把用户、商品、订单、库存这条链路过一遍想清楚边界和异常后面的开发就是往框架里填肉的事。最后提醒一句提前两周把系统完整跑通、录一遍演示视频比答辩前一晚熬夜改 bug 有用得多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
