Spring Boot电商系统课程设计：需求、数据库与模块实现全解析

简介这份资源是面向计算机及相关专业本科生、研究生的课程设计文档围绕基于Spring Boot的网上购物商城系统展开帮助读者理解Java、MySQL与B/S结构在电商项目中的落地方式适合正在做课程设计或希望完整走一遍需求分析到系统测试流程的学习者。压缩包内共1个docx文件约3.8MB以课程设计报告形式组织涵盖摘要、系统开发技术、系统分析、数据库设计含E-R图与表结构以及功能、性能、安全三方面的测试内容。文档按用户、商家、管理员三类角色划分功能模块并给出测试结果分析与改进方向可作为撰写报告、梳理模块划分和数据库设计的参考样本。目前已有76人学习适合需要一份结构完整、环节齐全的电商系统课程设计案例的读者对照使用。1. 从一份能跑但不敢交的课设说起每年到课程设计交付季总有一批基于 Spring Boot 的网上购物商城系统卡在同一个地方功能列表拉出来挺长用户注册登录、商品浏览、购物车、下单、后台管理都有可一旦导师问你的订单状态怎么流转商家和用户看到的是不是同一张商品表并发下单库存怎么扣就答不上来。问题不在代码量而在方案没立住——需求、模块边界、数据表、验收口径是散的。这篇方案面向正在做 MySQL 网上购物系统课程设计的人把一套基于 Spring Boot Java MySQL B/S 结构的商城系统从需求分析、总体设计、数据库设计、模块实现一路拆到测试验收结构可以直接照着交细节可以按自己项目改。适合本科课程设计、毕设开题也适合需要一份可交付电商后台方案的从业者参考。2. 需求与角色分析三类用户、四条主流程怎么定课程设计最容易翻车的一步是把功能当需求。功能是有购物车需求是用户从浏览到支付要经过哪些状态、每一步谁负责、失败怎么回退。这套商城系统在需求阶段先把角色和主流程钉死后面所有模块和表结构都从这里推。2.1 三类角色的权限边界系统只有三类角色用户、商家、管理员。角色不是随便分的它决定了登录后进哪个主页、能操作哪些表、接口要不要做数据隔离。角色核心职责可操作模块数据可见范围用户浏览、购买首页、商品信息、购物车、我的地址、我的收藏、订单管理、个人中心仅自己的订单、地址、收藏商家上架、履约商品信息管理、订单管理、我的收藏、个人中心仅自己发布的商品与相关订单管理员平台治理用户管理、商家管理、商品分类、商品信息、收藏管理、系统管理、订单管理全平台这张表看着简单实际是后面接口鉴权、SQL 加where条件的依据。我一般会在需求文档里明确写一句商家查询订单必须带merchant_id过滤管理员才允许全表查。很多课设答辩被问商家能不能看到别人订单答案就藏在这张表里。2.2 四条主流程的状态定义原文给出了注册、登录、购买三条流程图实际交付时还要补一条商家发货。四条流程的关键不是画得多漂亮而是把状态和判断条件写清楚注册流程先查用户名是否存在存在则提示重填不存在再校验密码与必填项通过后写库。登录流程先判用户名再判密码两次判断分开提示避免用户名或密码错误这种模糊反馈影响调试。购买流程未登录先跳登录登录后加购物车提交订单生成待支付记录支付后状态改为已支付。发货流程商家看到已支付订单发货后状态改为已发货用户确认收货改为已完成。订单状态建议固定为五个值待支付、已支付、已发货、已完成、已取消。状态流转只能单向走取消只允许在待支付阶段发生。这条约束写进需求后面订单模块的update语句就有了边界不会出现已发货还能取消的玄学数据。2.3 非功能性需求别只写一句运行稳定原文性能分析提了存储性、易学性、数据准确性、稳定性、可靠性五点落到可验收的指标上我通常这样补单表数据量按课程设计规模控制在万级以内商品表、订单表建索引后列表查询响应在 1 秒内。所有写操作走事务订单生成与库存扣减要么都成功要么都回滚。密码不明文存储至少做一次不可逆摘要。关键接口做参数校验空值、超长、非法字符在进入业务逻辑前拦截。这些指标不需要压测工具手工造 1000 条商品数据点一遍列表页就能验证答辩时也拿得出证据。3. 总体架构与技术选型B/S 三层结构如何落到包结构需求定完下一步是把用什么、怎么分层讲清楚。这套系统选 Java Spring Boot MySQL B/S 结构不是跟风是课程设计场景下维护成本最低的组合。3.1 为什么是 Spring Boot 而不是原生 SSM原生 SSM 要手写一堆 XML 配置课程设计周期短配置排错会吃掉大量时间。Spring Boot 把 Tomcat 内嵌、自动配置、依赖管理都收进起步依赖里启动一个main方法就能跑。原文提到 Spring Data JPA 是一套规范开发时仍用 ORM 映射框架对 JPA 接口开发这样换 ORM 实现不用改业务代码。实际落地时课程设计用 MyBatis-Plus 或 Spring Data JPA 都行关键是持久层接口和业务层分离别在 Controller 里直接拼 SQL。B/S 结构的价值在于客户端零安装浏览器请求、服务器响应、数据库存取三段职责清晰。三层对应到代码就是表现层Controller 页面、业务逻辑层Service、数据访问层Mapper/Repository。这个分层不是形式主义它决定了你改一个功能要动几个文件——分层清楚改订单状态只动 Service 和 Mapper分层混乱改一处崩三处。3.2 包结构与模块划分按角色和业务双维度切包比单纯按技术层切更好维护。我一般这样组织com.example.mall ├── common // 统一返回、异常、常量、工具 ├── config // 拦截器、跨域、密码编码器配置 ├── controller │ ├── admin // 管理员接口 │ ├── merchant // 商家接口 │ └── user // 用户接口 ├── service │ ├── impl ├── mapper // 数据访问 ├── entity // 与表对应的实体 └── dto // 请求/响应对象controller按角色分包是因为三类角色的鉴权规则不同放在一起容易漏加权限判断。dto单独拆出来是为了不让实体类直接暴露给前端——商品实体里有审核状态、商家账号这类字段用户端不该看到。这个结构在答辩时能直接讲我的权限隔离在包层面就有体现。3.3 登录鉴权的落地方式登录顺序图原文画了用户、登录框、身份控制器、用户信息表之间的交互。落到代码课程设计不必上 Spring Security 全套一个拦截器加会话或令牌就够// 登录拦截器按角色校验访问路径 public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String uri request.getRequestURI(); Object role request.getSession().getAttribute(role); // 未登录一律拦回登录页 if (role null) { response.sendRedirect(/login); return false; } // 商家只能访问 /merchant/**管理员只能访问 /admin/** if (uri.startsWith(/admin) !ADMIN.equals(role)) { response.sendError(403, 无权限); return false; } if (uri.startsWith(/merchant) !MERCHANT.equals(role)) { response.sendError(403, 无权限); return false; } return true; } }这段拦截器的关键在路径前缀和角色字符串的对应关系。/admin/**只放管理员/merchant/**只放商家用户端接口默认登录即可访问。参数上role在登录成功时写入会话值统一用大写常量避免前后端大小写不一致导致鉴权失效。失败时返回 403 而不是跳首页是为了让越权访问在测试阶段就暴露出来而不是被静默吞掉。4. 数据库设计从 E-R 图到能建表的字段清单数据库是这套系统最容易被追问的部分。原文给了商品分类、商家、订单、管理员、商品五个实体的 E-R 图但 E-R 图到建表还有一段距离——字段类型、主外键、索引、状态默认值这些才是能跑起来的东西。4.1 核心表结构与字段说明按 E-R 图落成表课程设计规模下六张核心表足够用户表、商家表、管理员表、商品分类表、商品表、订单表再加一张订单明细表承载一个订单多个商品。下面给订单表的关键结构CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 订单主键, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号对外展示, user_id BIGINT NOT NULL COMMENT 下单用户, merchant_id BIGINT NOT NULL COMMENT 所属商家用于商家端过滤, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总价, pay_type TINYINT DEFAULT 0 COMMENT 支付类型0未支付 1在线支付, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, address VARCHAR(255) NOT NULL COMMENT 收货地址快照, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user (user_id), KEY idx_merchant_status (merchant_id, status) ) COMMENT 订单表;几个设计点值得在文档里写明白。第一order_no和主键id分开主键自增用于内部关联订单编号对外展示避免用户从编号推算出订单总量。第二address存的是下单时的地址快照不是外键关联地址表——用户改地址不能影响历史订单这是电商系统的常识也是答辩常问的点。第三idx_merchant_status联合索引对应商家端按状态查自己订单的高频查询建索引前先想清楚查询条件比事后加索引靠谱。4.2 商品表与分类表的关联商品表通过category_id关联分类表商家表通过merchant_id关联商品。原文商品实体图里有审核状态、审核回复、点击次数、赞踩数这些字段课程设计可以保留但不必全做逻辑至少audit_status要有因为管理员审核商品是平台治理的核心动作。商品价格用DECIMAL(10,2)不要用FLOAT金额精度问题在订单汇总时会被放大这是血泪经验。4.3 表间关系与删除策略E-R 图只画了实体属性没画关系基数。实际建表要明确一个用户多个订单一对多一个订单多条明细一对多一个商家多个商品一对多一个分类多个商品一对多。删除策略上商品和用户都不做物理删除用状态字段标记下架或禁用否则历史订单会变成孤儿数据。原文性能分析提到删除数据不能连带删掉还需要的数据指的就是这个——外键约束加逻辑删除比级联删除安全得多。5. 模块实现用户、商家、管理员三条线的关键代码模块实现章要能让人照着写。三条线里用户线覆盖浏览到下单商家线覆盖商品与履约管理员线覆盖治理每条线挑一个最关键的实现点讲透。5.1 用户下单事务里扣库存与生成订单下单是整套系统最容易出问题的地方。用户点提交要做三件事校验库存、生成订单主表、生成订单明细并扣减库存。三件事必须在一个事务里Transactional(rollbackFor Exception.class) public String createOrder(Long userId, ListCartItem items, String address) { BigDecimal total BigDecimal.ZERO; for (CartItem item : items) { // 行锁读取商品防止并发超卖 Product p productMapper.selectForUpdate(item.getProductId()); if (p.getStock() item.getQuantity()) { throw new BizException(商品库存不足 p.getName()); } total total.add(p.getPrice().multiply( BigDecimal.valueOf(item.getQuantity()))); } Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalAmount(total); order.setAddress(address); order.setStatus(0); orderMapper.insert(order); for (CartItem item : items) { orderItemMapper.insert(buildItem(order.getId(), item)); productMapper.decreaseStock(item.getProductId(), item.getQuantity()); } return order.getOrderNo(); }selectForUpdate是行级锁保证同一商品并发下单时库存判断和扣减之间不被插队。rollbackFor Exception.class确保任何异常都回滚不会出现订单生成了库存没扣的脏数据。generateOrderNo用时间戳加随机位课程设计规模下够用。参数上items来自购物车勾选address是前端传入的地址快照服务端要再校验一次非空不能信任前端。5.2 商家商品管理数据隔离不能只靠前端商家端商品列表必须只返回自己的商品。常见错误是前端传merchantId后端直接拿来查——这等于把隔离权交给了前端。正确做法是从会话取当前商家 IDGetMapping(/merchant/products) public PageResultProductVO list(RequestParam(defaultValue 1) int page, RequestParam(defaultValue 10) int size) { Long merchantId SessionUtil.currentMerchantId(); // 强制按当前登录商家过滤忽略前端传入的任何 merchantId return productService.pageByMerchant(merchantId, page, size); }SessionUtil.currentMerchantId()从登录会话取前端传什么都不影响。分页参数给默认值避免空参导致 SQL 报错。这个写法在答辩时可以直接说商家越权查别人商品在我这里走不通因为查询条件不来自请求参数。5.3 管理员治理审核与分类维护管理员线重点是商品审核和分类管理。审核接口只改audit_status和audit_reply两个字段不要整行更新避免覆盖商家正在编辑的其他字段UPDATE product SET audit_status #{status}, audit_reply #{reply} WHERE id #{productId} AND audit_status 0WHERE里带audit_status 0是乐观控制防止重复审核把已通过的商品又打回。分类管理做增删改查即可删除分类前先查该分类下是否有商品有则拒绝删除并提示这条校验放在 Service 层别指望数据库外键报错给用户看。6. 避坑与排查课程设计里最容易翻车的五个点6.1 订单状态乱跳现象测试时发现已发货订单还能被取消或者待支付订单直接变成已完成。原因状态更新接口没校验当前状态前端传什么状态就写什么。解决所有状态变更走统一方法先查当前状态再按允许的流转表判断非法流转直接抛业务异常。状态机哪怕只用if-else写也比裸更新强。6.2 金额用浮点导致对不上现象购物车合计和订单总价差几分钱。原因价格字段用了FLOAT或DOUBLE累加产生精度误差。解决建表时金额统一DECIMAL(10,2)Java 侧用BigDecimal并且multiply和add都走BigDecimal方法不要中途转double。6.3 商家看到别人的订单现象两个商家登录订单列表出现对方数据。原因查询没带merchant_id条件或者条件来自前端参数。解决会话取商家 ID 强制过滤接口层加一条测试用例专门验证越权。6.4 图片上传后刷新就丢现象商品图片上传成功重启服务后访问 404。原因文件存到了项目临时目录重新部署被清掉。解决配置固定上传目录数据库只存相对路径静态资源映射到该目录。课程设计也要养成这个习惯别把文件塞进target。6.5 中文乱码与时间差八小时现象商品名存进去变问号订单时间比实际早八小时。原因数据库连接串没指定字符集和时区。解决连接串加characterEncodingutf8serverTimezoneAsia/Shanghai建库时字符集选utf8mb4。这两个参数写进配置模板新环境直接复制省得每次排查。7. 测试与答辩怎么用一张验收表把方案讲圆课程设计的测试章最容易被写成点了一遍没报错。真正能拿分的做法是把测试用例和需求条目对上让导师看到每个功能都有验证路径。我一般做一张验收表功能、操作步骤、预期结果、实际结果四列覆盖三类角色的核心流程编号测试项操作步骤预期结果T01重复注册用已存在用户名注册提示用户名已存在不写库T02错误密码登录正确用户名错误密码提示密码错误停留登录页T03未登录下单未登录点购买跳转登录页T04库存不足下单购买数量大于库存提示库存不足订单不生成T05商家越权商家A访问商家B订单返回 403 或无数据T06订单状态流转待支付订单依次支付、发货、收货状态按序变更非法流转被拒T07管理员审核审核待审核商品状态更新回复可见测试方法上功能测试手工执行接口层可以用 Postman 或浏览器直接调性能测试不追求压测报告造 1000 条商品数据看列表加载时间即可。安全测试重点看三处密码是否明文、越权是否拦住、SQL 是否拼接。答辩时导师最爱问的也是这三处。答辩陈述有个技巧不要按我用了什么技术讲按用户遇到什么问题、我怎么解决讲。比如讲订单模块先说并发下单可能超卖再说用行锁加事务解决最后展示测试用例 T04 的结果。技术名词是佐证问题和解法才是主线。数据库部分准备好 E-R 图和两张核心表的字段说明被问到为什么订单地址要存快照能答上来基本就稳了。从那以后我每次带课程设计都要求先交验收表再交代码——表填不满说明需求没想清楚代码写得再多也是返工。希望这套结构能帮到你照着改改就能变成你自己的方案。本文还有配套的精品资源点击获取