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，等查看订单列表时再去关联商品表，结果商品下架了或者价格变了，历史订单显示就错了，这是很经典的设计失误。
2.2 建表SQL里容易踩的坑
直接把我整理过的建表SQL核心片段放出来，方便参考：
sql复制CREATE TABLE `product` (
`id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键',
`category_id` bigint NOT NULL COMMENT '分类ID',
`name` varchar(128) NOT NULL COMMENT '商品名称',
`subtitle` varchar(256) DEFAULT '' COMMENT '副标题',
`main_image` varchar(512) DEFAULT '' COMMENT '主图URL',
`detail` text COMMENT '商品详情HTML',
`price` decimal(10,2) NOT NULL COMMENT '价格',
`stock` int unsigned NOT NULL DEFAULT 0 COMMENT '库存',
`sales` int unsigned NOT NULL DEFAULT 0 COMMENT '累计销量',
`status` tinyint NOT NULL DEFAULT 1 COMMENT '状态 0下架 1上架',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_category_id` (`category_id`),
KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='运动服装商品表';
几个容易踩的坑。
第一个是字符集。MySQL 8.0默认字符集已经是utf8mb4了，但如果你用的是MySQL 5.7，建表时一定要显式指定DEFAULT CHARSET=utf8mb4，否则默认的utf8字符集存不了emoji和一些生僻字。这个不一定会马上出问题，但商品详情里一旦有特殊字符，查出来就是乱码或者报错，排查起来特别费劲。
第二个是update_time用ON UPDATE CURRENT_TIMESTAMP来自动更新，这个设计非常省心。你更新了商品价格、库存，这行记录的更新时间会自动变，不需要在代码里手动set，也无法忘记set。缺点是如果你需要追踪某次具体改了什么，那需要额外做操作日志表，但这个项目级别用不到。
第三个是金额字段。这个我前面强调过，price和total_price一律用decimal(10,2)，Java实体类里对应BigDecimal，没有例外。所有的金额计算，比如购物车勾选商品算总价、下单时加总，都要用BigDecimal的add()方法，不能直接用+。
还有一点，商品表里做一个idx_category_id和idx_status的联合索引其实更科学，因为查询场景通常是“某分类下上架的商品”。单独建两个索引也能用，只是会多一次索引合并，数据量大了以后会有影响。做成KEY idx_category_status (category_id, status)会更好。
3. 核心业务模块的实战实现
3.1 用户登录与权限控制的实现方案
登录模块是最先要做的部分。方案上不要用传统的Session + Cookie，因为前后端如果分离，Session处理跨域会比较麻烦，而且分布式环境下Session共享也是个问题。我用的是JWT（JSON Web Token）方案，Redis做一个简单的黑名单或Token管理。
登录流程是这样的：用户提交用户名和密码，后端校验通过后，用JWT生成一个Token，Token里包含userId和role两个声明，然后设置一个合理的过期时间（我一般用2小时）。生成的Token返回给前端，前端后续的所有请求都把它放在请求头里，后端通过一个拦截器来解析Token，解析成功就把用户信息放到ThreadLocal里，方便业务代码随时获取当前登录用户。
JWT的密钥和过期时间放到application.yml里配置，不要硬编码在代码里。原因很简单，一旦你需要切换环境（开发环境、测试环境、生产环境），改配置比改代码要安全得多，也避免把密钥提交到代码仓库里泄露出去。
关于权限控制，我只做了两级：管理员接口和普通用户接口。实现方式是在拦截器里判断请求路径，/admin/**开头的接口只有role为1的管理员才能访问，其他接口登录即可。这种“约定大于配置”的方式，比写一堆注解更容易理解和维护。
分享一个我踩过的坑：登录接口本身不能加拦截器校验，否则用户在登录前就请求了登录接口，直接拦截器报未认证，死循环了。这个问题看着低级，但几乎每个做JWT的初学者都会遇到。解决办法是在拦截器里配置白名单，把/user/login、/product/list、/product/{id}这些公开接口放行。商品列表和详情是公开的，游客也能看，而不是强制登录才能浏览，这才符合实际场景。
3.2 商品分类、列表查询与缓存优化
商品模块看起来就是普通的CRUD，但做起来有细节。
管理员的商品管理操作包括：新增、编辑、上架、下架、删除。删除这里要注意，不是真的从数据库里删掉，而是优先做逻辑删除。因为商品一旦有订单关联，物理删除会让订单明细变成“查无此商品”的状态。MyBatis Plus内置了逻辑删除功能，只要在实体类的删除字段上加上@TableLogic注解即可，查询时会自动附加deleted=0条件，非常方便。
前台商品列表查询是另一个重点，涉及筛选和搜索。我提供以下几种过滤维度：分类ID、价格区间、销量排序、上架状态（前端只看上架商品）。如果前后端分离，将这些维度设计成查询参数，后端通过MyBatis Plus的QueryWrapper动态拼装SQL条件。如果做搜索引擎或者未来数据量大了，再考虑Elasticsearch或者MySQL全文索引，现阶段用MySQL索引即可。
缓存优化这块，商品列表确实是适合缓存的场景。运动服装的SKU相对稳定，不像秒杀商品那样需要秒级刷新，所以可以把首页的商品列表缓存到Redis里，缓存的Key按“分类+排序方式”区分，比如product:list:1:price_desc，缓存时间设置30分钟。如果后台管理员修改了商品或者上下架，调用一个删除缓存的操作，让缓存主动失效，而不是傻傻等30分钟过期。
但是，我强烈不建议把商品详情页也做成纯缓存。商品详情的属性不复杂，MySQL单表查询也就几毫秒，加了一层Redis缓存反而增加了缓存穿透、缓存雪崩的处理复杂度。这个项目里，商品列表做缓存就够了，详情页直接查库，等你的访问量真正上来了再逐步加缓存，是一个更务实的做法。
3.3 购物车实现：Session方案和Redis方案怎么选
购物车是一个值得好好讲讲的点，因为它的实现方式直接影响到用户体验和代码复杂度。
方案一是存Session里。用户加购物车时，把购物车数据存在服务端Session里，用户未登录也能加购，下单前再提示登录。这个方案最简单，但缺点非常明显：Session一过期，购物车就丢了，用户在别的设备上看不到同一个购物车，不符合主流电商体验。
方案二是存Redis里。购物车本质上是一个映射：用户ID对应的一个商品清单，用户ID作为Key，商品ID和数量存成Hash结构。Redis支持Hash操作，HSET cart:{userId} {productId} {quantity}，查询用了HGETALL一次取回来。Redis的持久化机制保证即使服务重启，购物车数据也不会丢，而且天然支持多端同步。这个方案唯一的门槛是你需要会一点Redis的基本操作，但非常值得学。
我推荐大家直接使用方案二，原因很简单：它让项目在答辩时有了“Redis在业务中的实际应用”这个亮点，而且代码量并没有增加很多。购物车的核心操作无非四个：加购、修改数量、删除单项、清空。每一个操作都对应Redis的一到两个命令，写一个CartService封装一下就可以。
还有一个细节：加购时需要判断库存是否充足，但这里不要直接读一次库存判断一次，因为从判断到扣减中间有并发窗口。正确的做法是：加购时做一次“宽松校验”，即库存大于0就能加入购物车，等到真正提交订单时再做精确的库存扣减。这个分层校验的思路，可以避免购物车环节因为库存问题频繁报错，也不会有超卖的风险——因为超卖的最后防线在订单创建处。
3.4 订单创建与库存扣减的原子性处理
订单模块是整个系统里最核心、也最容易出问题的部分。创建订单时，后端要做的事包括：
- 校验用户是否登录（从Token里拿userId）
- 根据前端传来的购物车勾选记录，组装订单明细数据（商品名称、图片、单价、数量）
- 计算总金额
- 扣减库存
- 生成订单主记录和订单明细记录
- 清除购物车中已下单的商品
- 所有操作在同一个事务里完成
库存扣减的正确姿势是“乐观锁”或者“条件更新”，而不是“先查库存再更新”。这句话是电商后端开发的一条铁律。举个例子：两个用户同时买同一件库存只剩1件的球衣，如果都先查到库存为1，然后都去做库存减1的操作，就会出现两个人都下单成功但库存变成-1的情况，这就是超卖。乐观锁的做法是，在更新库存的SQL里带上库存条件：
java复制boolean success = productService.update(
new LambdaUpdateWrapper<Product>()
.eq(Product::getId, productId)
.gt(Product::getStock, 0) // 库存必须大于0
.setSql("stock = stock - 1")
);
如果这条update返回的影响行数为0，说明库存不够，直接抛异常回滚事务，用户会看到一个友好的“库存不足”提示。这种方式比先查后改快得多，也不需要用Redis分布式锁，因为这个量级的系统根本到不了需要分布式锁的并发程度。
订单号生成也要说两句。不要让主键id直接当订单号对外展示——对外部的订单号应该是随机数或者带时间特征的字符串，避免通过订单号反推用户数量和系统数据规模。我常用的方式是yyyyMMddHHmmss + 4位随机数，真到并发量大的时候可以升级成雪花算法，但现阶段时间戳加随机数完全够用。
订单创建成功后，用户就要进入“待支付”状态。现实项目里支付环节通常对接微信支付或支付宝，但毕设和练手项目一般做的是“模拟支付”，也就是用户点击“确认支付”后，后端直接把订单状态从“待支付”改成“已支付”。在做模拟支付的前提下，要注意订单超时未支付的问题——可以用定时任务扫描超过30分钟未支付的订单，自动将其状态改为“已取消”并恢复库存。Spring Boot里用@Scheduled注解就能轻松实现这个功能，这段代码会让整个系统的完整性大大加分，因为很多人的毕设都漏了“取消订单并回补库存”这个环节，答辩时评委一问就露馅。
3.5 订单列表与销售统计的SQL实践
订单列表前台要做的是：根据当前登录用户查询其订单，每个订单关联查明细。推荐的办法是分两次查询：先查出订单主表的列表（分页），再根据订单号批量查出明细，在Service层手动做组装。不要用SQL嵌套子查询来一次性搞定，因为数据量稍微上来以后，嵌套查询的性能和可读性都会变差。
后台管理端需要按订单状态筛选，比如查看“待发货”订单、“已完成”订单。这种查询比较简单，订单表加一个status索引就够。
销售统计是很多管理系统的点睛之笔。我的统计页包含：总销售额、总订单数、总用户数、总商品数，以及近30天的销售趋势曲线。核心SQL就是SUM(total_price)、COUNT(*)这类聚合函数，再配合DATE_FORMAT(create_time, '%Y-%m-%d')按天分组。这类统计SQL在数据量小的时候性能当然没问题，但你需要注意日期分组查询要带上索引，否则后面订单量大了会越来越慢。
4. 项目配置、接口规范与常用工具
4.1 配置文件里的几个关键设置
application.yml是整个项目的“总控室”，有几个设置是我做这类系统时一定会做好的。
端口和上下文路径：server.port: 8080，这个根据自己需要改，我用8080比较多。注意如果同时起了多个项目，端口要避免冲突。
数据源配置上，MySQL的时区参数很关键。很多同学遇到过“数据库时间跟本地时间差8小时”的问题，多半是连接串上没有加serverTimezone=Asia/Shanghai。这个参数不加，Spring Boot默认会用UTC时区，导致时间错位。
MyBatis Plus的配置，核心两个点：逻辑删除配置和分页插件。分页插件要建一个配置类，把PaginationInnerInterceptor注册为Bean，否则Page对象虽然能查到数据，却拿不到total总条数，列表页的分页组件就罢工了。这个坑特别隐蔽，因为代码不报错，但分页总条数永远是0。
Redis配置要注意的就是连接信息。如果本地没装Redis，应用启动时连接失败的问题前面说过，两种解决思路。但我还是建议直接装一个Redis Desktop Manager可视化客户端，Redis在Windows上的安装也很简单，网上有很完整的教程。Spring Boot整合Redis还需要注意：默认的序列化器是JDK序列化，存进去的Key会带一串转义前缀，看着很丑，而且Redis Desktop Manager里看起来是乱码。解决方法是配置一个RedisTemplate的Bean，把Key的序列化器改成StringRedisSerializer，Value的序列化器改成Jackson2JsonRedisSerializer。这个配置几乎是每个Spring Boot Redis项目的标配。
文件上传配置，主要是商品图片。Spring Boot的spring.servlet.multipart.max-file-size默认是1MB，如果你要传商品主图，1MB肯定不够。一般我会配置成10MB，项目里用到文件上传时这个配置会直接决定你传图会不会报错。
4.2 统一返回格式与全局异常处理
前后端联调时，最怕的就是后端接口返回的数据结构不统一。一会儿返回{code: 200, data: null}，一会儿又变成String，前端处理起来就特别痛苦。所以项目从第一天起就要定义统一的响应格式。
我用的是最常见的三字段结构：code（状态码）、message（提示信息）、data（数据）。写一个Result<T>类，提供Result.success(data)和Result.error(code, msg)等静态方法。200是成功，400是参数错误，401是未登录，500是服务器内部错误。所有Controller的接口都返回这个包装类。
全局异常处理用@RestControllerAdvice注解。Spring Boot对这个支持得非常好，我可以把所有的异常处理集中到一个类里，比如业务异常、参数校验异常、兜底Exception。这个类的存在，保证了接口出错时返回给前端的依然是标准的Result结构，而不是一堆堆栈信息或者Spring默认的错误页。这个设计对提升代码质量观感的作用特别明显，答辩或面试时一谈起“全局异常处理”，专业感马上就出来了。
参数校验上，不要用大段大段的if判断，而是用Java Bean Validation的@NotBlank、@NotNull、@Size注解，配合@Validated触发校验。比如：
java复制public class UserRegisterRequest {
@NotBlank(message = "用户名不能为空")
@Size(min = 3, max = 20, message = "用户名长度为3-20个字符")
private String username;
@NotBlank(message = "密码不能为空")
@Size(min = 6, max = 32, message = "密码长度至少6位")
private String password;
}
这样代码非常清晰，而且校验失败的提示信息会被全局异常处理器捕获，统一返回给前端。Spring Boot的@Validated配合@RestControllerAdvice，可以说是这个框架最省心的组合之一。
4.3 接口文档怎么生成更省事
当初我做这类项目时最头疼的一步就是写接口文档。后来发现一个捷径：集成Springdoc，也就是Spring Boot 2.x版本的OpenAPI（Swagger 3）支持。加依赖、写几行配置，启动项目后访问/swagger-ui.html，所有的接口列表、参数说明、返回结构就自动生成了，还能直接在页面上调试。
Swagger配置有两个细节。第一是需要在配置类里开启@EnableOpenApi，并且配置一个Docket或GroupedOpenApi的Bean，把扫描路径设成Controller包，同时给接口分组，比如前台接口和后台接口分开看，会清爽很多。第二是统一在每个Controller和核心方法上写@Tag和@Operation注解，给出简洁的名称和说明，让前端同学能直接照着自测，不用反复问后端接口怎么调用。对于项目交付和验收来说，这个工具能省下一大堆沟通成本。
4.4 利用模型类与代码生成器减少重复劳动
Spring Boot + MyBatis Plus这类系统里，最枯燥的工作就是写实体类、Mapper接口、Service接口和ServiceImpl实现类。其实MyBatis Plus提供了一个代码生成器（MyBatis-Plus Generator），你只需要配置好数据库连接和输出路径，它就能自动生成整套代码。这意味着表结构设计好后，基础的CRUD代码就已经完成了一半，你只需要专注于写复杂的业务逻辑。
我在项目开发流程里的用法是：先设计好表结构，跑一遍代码生成器生成实体类和Mapper，Service层保留自动生成的模版，再手工往里添加自定义业务方法，比如创建订单、扣减库存、销售统计。这样既保证了基础代码的一致性和正确性，又把有限的时间花在了真正的业务实现上。
另外，不要小看实体类的设计规范。MyBatis Plus里，如果表名和实体类名不一致（比如表名是orders，实体类叫Order），一定要用@TableName("orders")注解显式指定。字段也要和表的列名对应上，驼峰转下划线是MyBatis Plus默认开启的，所以totalPrice自动映射total_price没问题，但如果是orderNo映射order_no，也一样没问题，但反过来如果你在实体类里写了一个SQL查不出来的字段名，那就等着运行时异常吧。这个细微的规范，能避免很多莫名其妙的查询为空、插入报错。
5. 测试、部署与常见问题排查
5.1 接口测试：从Postman到自动化MockMvc
接口写完，一定要测试。我建议的测试路径是：先用Postman验证接口的基本流程，梳理好完整的业务链路（注册用户→登录拿Token→添加商品→加购物车→下单→支付→查订单），把业务走通了再开始联调。
Postman的另一个重要用途是调试需要认证的接口。登录接口会返回一个Token，你需要在Postman的Tests脚本里自动提取这个Token，并设置成环境变量，这样后续请求自动带上。这个操作看起来不起眼，但实际开发中能省下大量手工复制Token的时间，尤其是Token频繁过期的时候，体验完全不一样。
后端的单元测试和接口自动化测试也不要省。Spring Boot提供了spring-boot-starter-test，里面集成了JUnit和MockMvc。用MockMvc可以直接模拟HTTP请求，测试Controller层的接口行为。比如注册接口：
java复制@SpringBootTest
@AutoConfigureMockMvc
public class UserControllerTest {
@Autowired
private MockMvc mockMvc;
@Test
public void registerSuccess() throws Exception {
mockMvc.perform(MockMvcRequestBuilders.post("/api/user/register")
.contentType(MediaType.APPLICATION_JSON)
.content("{\"username\":\"test01\",\"password\":\"123456\"}"))
.andExpect(MockMvcResultMatchers.status().isOk())
.andExpect(MockMvcResultMatchers.jsonPath("$.code").value(200));
}
}
这种测试的好处是，以后改动代码导致接口行为变化，跑一遍测试就能快速暴露问题，不用每次都手工点页面、点Postman。虽然写好测试会多花一些时间，但它是项目质量和可维护性的重要保障。
5.2 项目打包与部署
整个项目开发完后，部署到服务器或本机是最后一步。Spring Boot的部署非常简单：在IDEA的Maven侧边栏里执行mvn clean package -DskipTests，或者直接用mvn package，等打包完成后，target目录下会生成一个Jar包。
在服务器上部署时，通常先上传Jar包，再运行：
bash复制java -jar springboot-sportswear-sales-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod
如果想让它在后台稳定运行，一般配合一个启动脚本，或者挂到systemd服务上。不要直接关掉终端让服务断掉，这样系统挂了都找不到原因。对本地测试来说，直接java -jar执行即可。
一个常见的坑是Jar包启动时端口被占用。如果用8080端口，可以先检查一下有没有其他程序占用：
bash复制netstat -ano | findstr 8080
如果是别的项目占用了，要么杀掉对应进程，要么改配置文件的端口。还有一个常见问题是打包时测试用例没跳过，导致构建失败。如果测试类本身有环境依赖（比如连数据库），打包时直接-DskipTests跳过测试就可以了，测试放到开发阶段跑。
5.3 项目做完了之后怎么继续提升
一个可以跑通的系统只是起点，想让这个项目有足够的“含金量”，下面几个方向你可以按需挑选去完善。
第一，把静态资源上传到对象存储（比如阿里云OSS或腾讯云COS），而不是存本地磁盘。这样图片链接是完整的HTTP地址，部署到服务器后图片也不会丢，也能体现你对实际生产环境的理解。
第二，给订单模块增加一个“取消订单-恢复库存”的逻辑。前面讲了用@Scheduled定时扫描超时未支付的订单，把状态改成已取消，同时把库存加回去。这个细节非常能体现你对业务闭环的理解，答辩时是很好的加分项。
第三，把系统的日志做好。Spring Boot默认用Logback，配置里加上日志输出到文件，生产环境的异常排查就很有依据了。按天滚动日志文件，保留30天，也方便回溯问题。
第四，如果想横向扩展，可以给项目引入Redis缓存访问计数、排行榜，或者结合MQ做订单创建后的异步通知。不过要量力而行，合不合适比用得多不多更重要。
5.4 常见问题与排查技巧速查表
我在帮别人看项目时，收集了几个出现频率特别高的问题，这里整理成一张速查表，按“现象-原因-解法”的思路列出来，方便你遇到问题时直接对照。
启动阶段
-
现象：Spring Boot启动失败，提示
Failed to configure a DataSource。
原因：没有配置数据源或者依赖中引入了DataSource相关组件但没有设置连接信息。
解法：检查application.yml里spring.datasource.url/username/password是否填写，是否漏了MySQL驱动依赖。 -
现象：启动时日志报
Unable to connect to Redis。
原因：本地没有启动Redis服务，或者Redis配置的地址端口不对。
解法：先启动Redis服务（命令行redis-server或桌面工具），再确认配置中的host和port。如果本地没有Redis又暂时不想装，可以先把Redis相关依赖和配置注释掉，应用一样能启动，等需要时再启用。 -
现象：启动很快但访问接口报404。
原因：Controller类所在包不在Spring Boot启动类扫描范围内。
解法：确保启动类放在项目包的根路径，比如com.example.sportswear，所有Controller和Service都放在这个包或者其子包下，让自动扫描生效。
登录与权限阶段
-
现象：登录成功但访问其他接口提示未认证。
原因：Token没有在请求中正确传递，或者拦截器路径配置错误。
解法：确认前端是否在每个请求头加入了Authorization字段，格式为Bearer {token}；检查拦截器配置中排除路径是否正确，比如登录、注册、商品列表等公开接口不能要求Token。 -
现象：JWT Token一重启就失效。
原因：JWT的密钥和过期时间都写在代码里，或者是每次启动时生成新的随机密钥。
解法：把密钥固化在application.yml里，保证每次启动读取的是同一个配置值。
业务逻辑阶段
-
现象：下单后库存变成负数。
原因：没有使用条件更新的乐观锁。
解法：库存扣减使用setSql("stock = stock - 1")配合gt(Product::getStock, 0)条件，并放在事务内执行。 -
现象：订单总金额是乱码的浮点数。
原因：金额用了double或float类型的实体字段。
解法：Java实体类中金额一律用BigDecimal，数据库列用decimal(10,2)。 -
现象：购物车里的商品数量一直对不上。
原因：Redis的Key设计不统一，可能同一个用户在不同页面用了不同前缀的Key。
解法：统一购物车Key的规则，比如cart:{userId}，并且所有读写购物车的方法都通过同一个CartService封装，不要直接在Controller里操作RedisTemplate。
部署与运行阶段
-
现象：本地运行正常，部署到服务器后图片显示不出来。
原因：图片存在本地磁盘的绝对路径，换环境后路径失效。
解法：把图片上传改为对象存储，或使用相对路径并确认服务器的静态资源映射配置正确。 -
现象：
mvn package打包后启动报no main manifest attribute。
原因：pom.xml中没有配置Spring Boot的Maven插件。
解法：添加spring-boot-maven-plugin，并确认主类配置正确。
以上这些问题，我在好几个同学的机器上都遇到过，每次排查到根源，基本都逃不出这几个大类。提前排查一遍，能省下不少折腾时间。
最后再说一点个人习惯：我每写完一个模块，都会顺手整理一下项目的README，把启动步骤、默认账号、核心接口说明写进去。这看起来是小事，但对项目复盘、答辩、放进简历和作品集，都特别加分。做项目不只是把代码跑通，清晰的文档和规范的结构，才是“系统设计”真正体现专业度的部分。