cyeninesky345“基于Spring Boot的运动服装销售系统”这个题目，乍一看是个很标准的Java毕业设计或课程设计选题，但真要把它做得结构清晰、能跑通、能答辩、敢写进简历，其实有不少门道。我做过好几个类似的电商类管理系统，也帮人排查过不少跑不起来的项目，今天就用一篇完整的实战复盘，把这个系统从设计到落地讲透。内容包括表结构怎么设计、订单和库存怎么联动、购物车怎么存、权限怎么做，以及一堆你在学校文档里看不到的坑和优化思路。
1. 项目整体设计与技术选型思路
1.1 为什么选Spring Boot做这类系统
运动服装销售系统本质上是一个典型的“业务管理系统+轻量电商”组合。它的核心功能不外乎商品管理、用户登录、购物车、下单、订单管理、库存扣减，再加一点销售统计。这类系统最大的特点是：业务逻辑清晰、CRUD密集、并发量不高、部署环境相对简单，所以它非常适合Spring Boot。
Spring Boot的优势在这个项目里体现得很直接。第一是自动配置，你不需要像Spring MVC时代那样写一堆XML配置文件，一个application.yml搞定数据源、Redis、MyBatis等大部分配置。第二是内嵌Tomcat，打出来的Jar包直接java -jar就能跑，部署成本几乎为零，这对学生项目或者小团队内部系统来说太友好了。第三是生态成熟，Spring Boot整合MyBatis Plus、Redis、JWT、Swagger这些常用组件基本上都是“加依赖+写配置”两步走，不用从零造轮子。
我见过有人用SSH（Struts2 + Spring + Hibernate）做这种系统，也不排除能用，但它的配置复杂度、版本兼容问题、学习成本都明显偏高，而且现在网上资料也少。用Spring Boot，遇到问题随便一搜就是大把解决方案，这点在开发体验上的差距是非常明显的。
1.2 技术栈和版本选择的实操建议
在这个项目里，我用的是这样一套组合：Spring Boot 2.7.x + MyBatis Plus 3.5.x + MySQL 8.0 + Redis + Maven，JDK用的1.8。这个组合我强烈推荐给做毕设或者练手的同学，原因很简单：Spring Boot 2.7.x是2.x系列的最后一个稳定版本，兼容JDK 8，网上资料最多，遇到问题最好搜。Spring Boot 3.x虽然已经发布很久了，但它强制要求JDK 17，很多同学的电脑上装的还是JDK 8，而且部分老教程里的写法在3.x里会报错，所以没必要在这个阶段给自己增加额外负担。
关于MyBatis Plus，它真的是这类管理系统的效率神器。单表CRUD不用写SQL，自带分页插件，还有代码生成器。有人说“用MyBatis Plus会让SQL能力退化”，这话有一定道理，但你做这个项目主要是为了把业务逻辑跑通，不是来练SQL优化的，能用现成的工具快速实现功能，然后把时间花在订单状态机、库存扣减这类核心逻辑上，才是正确的精力分配。
Redis在这个项目里的定位有两块：一是存登录Token，实现简单的单点登录状态管理；二是缓存首页商品列表和热门商品数据，减少数据库压力。它不算必须项，如果你还没学Redis，用Session或者JWT也行，但既然要做“系统设计”，把Redis加进去会让整个项目的技术含量提升一个档次，面试和答辩时也更有话讲。
前端部分，如果是传统单体应用，直接用Thymeleaf模板引擎就够了，服务端渲染，逻辑简单，适合快速上线。但如果你有Vue基础，想做前后端分离，那可以前端用Vue3 + Element Plus，后端把接口返回统一封装成JSON格式，用JWT做认证，效果会更好看，开发周期会略长一些。这个看个人时间和精力，我下面讲的内容以后端为主，但接口设计部分会考虑到前后端分离的情况。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计与核心表结构拆解
2.1 表结构设计：6张表说清一套电商核心模型
运动服装销售系统的数据模型，说简单也简单，但要设计得合理，还是有几个需要多想一步的点。我这里的落地方案是6张核心表：
用户表（user）、商品分类表（category）、商品表（product）、购物车表（cart_item）、订单表（orders）、订单明细表（order_item）。
先说用户表。字段上除了常规的username、password、nickname、phone、avatar之外，我建议加一个role字段（枚举类型，0表示普通用户，1表示管理员），这样就不用另建一张角色表了，因为这种系统的角色数量非常固定，搞一套RBAC反而过度设计。密码字段存的是BCrypt加密后的hash值，不是明文，这个从第一天开发就要养成习惯。
分类表很简单，id、name、sort_order，再加一个parent_id做无限级分类的预留。其实对运动服装来说，一级分类就够用了，比如上衣、裤装、鞋类、配件，但加上parent_id以后扩展起来会舒服很多。
商品表是核心中的核心，字段比较多：id、category_id、name、subtitle、main_image、detail（富文本详情）、price（BigDecimal）、stock（Integer）、sales（Integer，累计销量）、status（0下架 1上架）、create_time、update_time。有三个地方要特别注意：
- 价格字段一定用
DECIMAL(10,2)，不要用DOUBLE或FLOAT。浮点数有精度损失，金额算错这种问题在电商系统里是绝对不能接受的。Java里对应使用BigDecimal，千万不要用double接数据库的金额字段。 - 库存字段
stock要用Integer且加UNSIGNED约束，同时逻辑上要保证不能为负，这个靠SQL层面的约束和代码层面的校验双重保障。 - 一定要有
main_image（主图）和detail（详情）的区分。运动服装这种商品，用户很看重实物图和尺码细节，主图用于列表展示，详情用于商品页，分开存以后做前端展示会非常顺手。
订单表和订单明细表是另一对核心。订单表orders主要字段有：id（订单号）、user_id、order_no（业务订单号，跟主键id分开）、total_price、status（0待支付 1已支付 2已发货 3已完成 4已取消）、receiver_name、receiver_phone、receiver_address、pay_time、create_time、update_time。订单明细表order_item则记录每一件商品的快照：order_id、product_id、product_name、product_image、current_price（下单时的价格，不是查当前表）、quantity、subtotal。
为什么订单明细里要冗余一份商品名称、图片、价格？原因是商品信息是会变的，用户下单之后你把商品改名了或者调价了，用户查看历史订单时看到的应该还是他下单那一刻的信息，这就是“快照”的概念。很多新手做订单表时只存一个product_id，等查看订单列表时再去关联商品表，结果商品下架了或者价格变了，历史订单显示就错了，这是很经典的