GO厂长在做服饰服装商城这类选题的时候，我第一反应是这其实是个标准的“全能型练手题目”。它不像纯管理系统那样只围绕CRUD转，也不像高并发秒杀系统那样承载太多中间件压力，而是刚好落在“完整业务流程+企业级分层开发”这个区间。你既要用Spring Boot把后端服务搭起来，又要用JavaEE的分层思想把Controller、Service、DAO理清楚，还得处理商品、购物车、订单、用户这些实体之间的关联。很多同学一看到“基于JavaEE”就以为是老套的Servlet+JSP，实际上现在的主流做法是：用Spring Boot作为基础框架，在工程结构上遵守JavaEE的分层规范，再配合MyBatis或MyBatis Plus做持久层，前端用Thymeleaf服务端渲染，或者直接拆成前后端分离。这篇博文就按这个思路，把服饰服装商城的设计与实现完整走一遍，包括技术选型、数据库设计、核心代码实现、以及我实际调试过程中踩过的一堆坑。
这个项目适合谁？正在准备毕业设计的同学、想用Spring Boot做第一个完整Web项目的初学者、以及想系统梳理JavaEE三层架构的开发者。读完你至少能搞明白：一个商城网站从零到上线需要拆成哪些模块、每个模块的核心逻辑怎么落代码、遇到Spring Boot版本、MyBatis报错、事务不回滚这类问题该怎么排查。
1. 项目整体设计与技术选型思路
1.1 为什么是Spring Boot + JavaEE，而不是传统Servlet
先说一个很多人困惑的点：标题里写着“基于JavaEE”，但现在的实际项目几乎不会再用纯Servlet + JSP去写。JavaEE（现在叫Jakarta EE）本身是一整套企业级开发规范，Servlet、JSP、JDBC、JNDI、EJB这些都算，但直接用这些规范写业务代码，开发效率低到让人怀疑人生。Spring Boot本质上是在Spring Framework基础上做了大量自动配置和约定优于配置的封装，它跑的还是JavaEE里的Servlet容器（内嵌Tomcat），但它帮你省掉了XML配置、依赖版本管理、环境部署这些杂事。
所以“基于JavaEE”在毕设语境下，正确理解是：项目采用Java企业级分层架构思想，表现层、业务层、持久层清晰分离，底层运行在Servlet容器上，直接使用JavaEE规范中的相关技术。Spring Boot是这些规范实现的外壳和加速器。这也符合企业里真实项目的组织方式——没有谁在2025年还手写Servlet，但每个Java后端岗位都要求你理解分层、理解请求生命周期、理解事务边界。
用Spring Boot还有一个特别现实的好处：内嵌Tomcat。以前做JavaWeb项目要单独装Tomcat、把war包丢进去、再配数据源，中间任何一个步骤出错，页面就是404或者ClassNotFound。Spring Boot直接在application.yml里配端口和数据源，跑main方法就能起服务，这对毕设和实验室环境来说极其友好。
1.2 版本选型的底层逻辑：Spring Boot、JDK、数据库
版本选型是很多人忽略但是极其关键的一步。我见过太多同学因为Spring Boot版本选太高，导致MyBatis、Druid这些第三方starter出现兼容性问题，一启动就报错。我的建议是别追新，选稳定版。Spring Boot 2.7.18是我个人比较推荐的一个版本，它是2.x系列的最后一个维护版本，兼容JDK 8，各种第三方库的适配资料也最全。Spring Boot 3.x虽然已经发布很久，但它强制要求JDK 17，而且javax.包换成了jakarta.，很多老教程、老依赖直接失效，如果你不是特别清楚这些差异，非常容易被坑。
服饰服装商城这个规模的项目，技术栈这样搭配比较稳：
- JDK：1.8（也就是8），这是目前国内绝大多数中小公司和教程体系默认的版本，稳定到不能再稳定。
- 构建工具：Maven 3.6+，用IDEA自带的也行。
- Spring Boot：2.7.18
- 持久层框架：MyBatis或MyBatis Plus。MyBatis的SQL控制力更强，适合学习；MyBatis Plus能少写很多单表CRUD，适合快速完成项目。两者都可以，我下面的示例以MyBatis为主。
- 数据库：MySQL 5.7或8.0。注意MySQL 8.0的驱动名是com.mysql.cj.jdbc.Driver，5.7也可以用这个驱动，但需要带时区参数。
- 前端模板引擎：Thymeleaf。它是Spring Boot官方推荐的服务端渲染模板，语法以html开头，浏览器直接打开也能看到静态结构，比JSP好调试。
- 权限认证：JWT + Spring Interceptor。JWT做无状态登录，适合前后端分离；如果你做的是Thymeleaf不分离项目，也可以用Session，但JWT在简历上写起来更好看。
- 连接池：Druid或HikariCP。Spring Boot默认HikariCP已经非常好用，加Druid主要是为了看监控页面，非必须。
- 数据库迁移：不强制。毕设用sql脚本初始化表结构就够，别引入Flyway增加学习成本。
这里要强调一个容易被吐槽但很有用的事：如果你用的是IDEA，创建Spring Boot项目时Spring Initializr默认会用最新的Spring Boot 3.x，你要么手动改成2.7.18，要么去阿里云镜像站点创建。不想折腾镜像站的话，直接在pom.xml里覆盖parent版本也行。
1.3 项目功能模块拆解
服饰服装商城网站最核心的价值是“展示商品+完成交易”，我用思维导图的方式在脑子里过一遍，通常会有这些模块：
- 前台用户模块：注册、登录、修改个人信息、查看历史订单。
- 商品展示模块：商品列表、根据分类筛选（男装/女装/童装/鞋靴）、商品关键字搜索、商品详情。
- 购物车模块：加入购物车、修改数量、删除商品、批量结算。
- 订单模块：确认订单、生成订单、取消订单、支付（模拟）、查看订单详情。
- 后台管理模块：管理员登录、商品分类管理、商品上架下架、订单状态管理、用户管理。
- 辅助功能：首页轮播图、Banner管理、公告、分页、图片上传。
这些模块拆完，你会发现它其实就是电商系统的简化版。它不要求你有复杂的优惠券算法，也不要求Redis缓存热点数据（当然你加了会是加分项），但必须有完整的“下订单->减库存->生成支付记录”这条链路，这样才能体现你对业务闭环的理解。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心功能模块与数据库设计
2.1 商城核心业务流程梳理
在动手写代码之前，一定要先梳理业务流程。服饰服装商城的核心链路是这样的：用户浏览商品，把喜欢的商品加入购物车，在购物车里调整数量后提交订单，订单生成后模拟支付，支付成功则商城的库存减少、订单状态变为待发货，后台管理员发货后状态变为待收货，用户确认收货后订单完成。如果有售后需求，可能还有一个退货退款状态。
这个流程里，最需要扣细节的是“提交订单”这一步。提交订单是一个事务操作，它至少要完成三件事：创建订单主记录、创建订单明细记录、扣减商品库存。这三件事必须同时成功或同时失败，否则就会出现订单已创建但库存没扣、或者库存扣了但订单没生成的数据不一致问题。这就是为什么我后面会专门讲Spring的事务管理。
另外要思考一个边界问题：提交订单时用户可能已经离开了页面，商品库存也可能不足。所以代码里要先校验库存，再去扣减，扣减时要判断受影响行数，如果扣减失败就抛出异常回滚整个事务。这一步会涉及乐观锁或者行锁，我建议在库存表里加一个version字段，用乐观锁的方式防止超卖。虽然商城项目并发量不高，但这是面试官非常喜欢问的一个点。
2.2 数据库表设计与关系说明
数据库设计是这种项目的地基。表设计得不好，后面写代码就是一场灾难。我基于这个标题的实际需求，给出一套经过调整后比较合理的设计方案，核心表有这些：
user用户表：id、username、password、nickname、phone、avatar、gender、create_time、update_time、status。注意密码不要存明文，至少用MD5加盐，更稳妥的是BCrypt加密。category商品分类表：id、name、parent_id、sort_order、create_time。服饰分类一般是两级，比如“男装”下面有“T恤”“衬衫”“裤子”，所以保留parent_id字段。product商品表：id、category_id、name、sub_title、main_image、detail_image、price、stock、sales、status（0下架1上架）、create_time、update_time。这里price用decimal(10,2)，别用float/double，否则金额会有精度问题。cart_item购物车表：id、user_id、product_id、quantity、checked、create_time、update_time。购物车是用户维度的数据，主键最好是自增id，同时给user_id建立索引。orders订单主表：id、order_no、user_id、total_price、pay_amount、pay_type、status、receiver_name、receiver_phone、receiver_address、create_time、pay_time、delivery_time、confirm_time。订单状态用int类型比较好维护，0待付款、1已付款待发货、2已发货待收货、3已完成、4已取消。order_item订单明细表：id、order_id、product_id、product_name、product_image、current_price、quantity、total_price。这里有一个细节：订单里必须冗余商品的快照信息（名称、图片、价格），因为商品后来可能改价或下架，但用户的历史订单必须保持下单时的样子。banner轮播图表：id、image、url、sort_order、status、create_time。用来做首页Banner。admin管理员表：id、username、password、name、create_time。
这些表之间的关系也比较清晰：用户和购物车是一对多，订单和订单明细是一对多，商品和分类是多对一。订单表设计的时候一定要把收货人的姓名、电话、地址都冗余进来，不要再去关联用户表取地址，因为用户可能修改地址，但订单不能跟着变。
2.3 核心表结构SQL参考
我直接放一个简化版建表语句，大家在用的时候可以基于这个扩展：
sql复制CREATE TABLE `user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`username` varchar(64) NOT NULL COMMENT '用户名',
`password` varchar(128) NOT NULL COMMENT '密码',
`nickname` varchar(64) DEFAULT NULL,
`phone` varchar(20) DEFAULT NULL,
`avatar` varchar(255) DEFAULT NULL,
`gender` tinyint(1) DEFAULT '0',
`status` tinyint(1) DEFAULT '1' COMMENT '1正常0禁用',
`create_time` datetime DEFAULT CURRENT_TIMESTAMP,
`update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
CREATE TABLE `product` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`category_id` bigint(20) NOT NULL,
`name` varchar(128) NOT NULL COMMENT '商品名称',
`sub_title` varchar(255) DEFAULT NULL COMMENT '副标题',
`main_image` varchar(255) DEFAULT NULL COMMENT '主图',
`price` decimal(10,2) NOT NULL COMMENT '价格',
`stock` int(11) NOT NULL DEFAULT '0',
`sales` int(11) NOT NULL DEFAULT '0',
`status` tinyint(1) DEFAULT '1' COMMENT '1上架0下架',
`create_time` datetime DEFAULT CURRENT_TIMESTAMP,
`update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';
注意一点，utf8mb4是必须的，不然用户昵称里有表情符号就会报错。
3. 核心环节实现与实操记录
3.1 用户注册登录与JWT鉴权实现
先做最基础的用户模块。注册接口的核心逻辑是：从前端拿到用户名和密码，校验用户名是否已存在，密码用BCrypt加密后入库，然后直接返回注册成功。这里不想把逻辑写得过于简单，可以加一个简单的防御：用户名要符合字母数字下划线规则，长度4-20位，密码长度至少6位。
登录接口成功后颁发JWT。JWT的结构是Header.Payload.Signature，生成时至少要在payload里带上userId、username、过期时间。用java-jwt或者jjwt这两个库都行，我更推荐jjwt，API简单，源码清晰。示例配置：
xml复制<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-api</artifactId>
<version>0.11.5</version>
</dependency>
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt-impl</artifactId>
<version>0.11.5</version>
<scope>runtime</scope>
</dependency>
JWT工具类核心代码：
java复制public String generateToken(Long userId, String username) {
return Jwts.builder()
.setSubject(username)
.claim("userId", userId)
.setIssuedAt(new Date())
.setExpiration(new Date(System.currentTimeMillis() + 3600_000))
.signWith(secretKey, SignatureAlgorithm.HS256)
.compact();
}
有了JWT之后，拦截器负责从请求头Authorization里取Token，解析成功就放行，并在请求域里塞入userId。如果不带Token或Token过期，返回401。需要注意拦截器要放行登录、注册、商品列表、商品详情这些无需登录也能访问的接口，我一般用一个排除列表来管理，代码里写清注释。
这里有个特别容易踩的坑：JSON序列化时LocalDateTime会变成一串数组，页面完全没法看。解决方式是在application.yml里配置Jackson的日期格式，或者全局加一个ObjectMapper配置类。我更推荐用配置类，因为还能顺便处理空值、时区问题。
3.2 商品查询、分页与搜索功能
商城主页和商品列表页是用户看到的第一界面。这一块要做的事是：分页展示商品、按分类筛选、按关键字模糊搜索、按销量或价格排序。用MyBatis时，分页可以手写LIMIT，也可以引入PageHelper。PageHelper的使用简单到令人感动，只是在方法执行前调用PageHelper.startPage(pageNum, pageSize)，后面跟的那条SQL查询就会自动带上LIMIT，查询完再用PageInfo封装返回结果。
java复制public PageInfo<ProductVO> getProductList(Integer categoryId, String keyword, Integer pageNum, Integer pageSize, String orderBy) {
PageHelper.startPage(pageNum, pageSize);
List<Product> products = productMapper.selectByCondition(categoryId, keyword, orderBy);
return new PageInfo<>(products);
}
注意PageHelper有个经典连环坑：它只对它后面的第一条查询SQL生效，所以startPage必须紧挨着查询语句，中间不能有其他查询，否则分页会错乱。我在项目里因为在这个类里先查了个分类名称再去查商品，结果分页直接失效，排了半天才发现是这个问题。
搜索功能推荐用MySQL的LIKE查询完成，虽然性能不算最优，但对数据量不大的商城来说完全够用。如果以后想体验Elasticsearch，可以在商品表数据同步到ES之后，用ES的全文检索替换LIKE，但那是加分项，不影响核心功能。商品详情的实现就更简单了，根据id查商品表，再查销量、库存，顺便把相同分类下的推荐商品查出来即可。
3.3 购物车与订单流程实现
购物车的实现比较直白。每个用户有自己的购物车记录列表，加入购物车时先查询购物车里是否已有同一商品，有就数量相加，没有就新增。修改数量时校验不能超过库存上限。删除商品就是根据id删除记录。
订单流程是整个项目的重头戏，从购物车“去结算”开始，到生成订单结束，这里我展示一下核心的Service逻辑，包括事务和库存扣减。
java复制@Transactional(rollbackFor = Exception.class)
public Long createOrder(Long userId, Long addressId, List<Long> cartItemIds) {
// 1. 查询购物车选中的商品明细，并加锁
List<CartItem> cartItems = cartItemMapper.selectByIdsForUpdate(cartItemIds);
if (CollectionUtils.isEmpty(cartItems)) {
throw new BizException("购物车中没有选中商品");
}
BigDecimal totalPrice = BigDecimal.ZERO;
// 2. 遍历校验商品状态、计算总价、扣减库存
for (CartItem item : cartItems) {
Product product = productMapper.selectByPrimaryKey(item.getProductId());
if (product == null || product.getStatus() != 1) {
throw new BizException("商品[" + item.getProductName() + "]已下架");
}
if (product.getStock() < item.getQuantity()) {
throw new BizException("商品[" + product.getName() + "]库存不足");
}
int rows = productMapper.decreaseStock(item.getProductId(), item.getQuantity());
if (rows == 0) {
throw new BizException("商品[" + product.getName() + "]库存扣减失败");
}
totalPrice = totalPrice.add(product.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())));
}
// 3. 生成订单主记录，状态为待付款
Orders order = new Orders();
// ... 设置订单号、收货信息、金额、状态等
orderMapper.insert(order);
// 4. 批量生成订单明细
for (CartItem item : cartItems) {
OrderItem orderItem = new OrderItem();
// ... 拷贝商品快照信息、数量、价格
orderItemMapper.insert(orderItem);
}
// 5. 清空已结算的购物车
cartItemMapper.deleteBatchByIds(cartItemIds);
return order.getId();
}
这里我用了selectByIdsForUpdate，在查询购物车明细时加行锁，同时扣减库存时判断受影响行数，防止库存变成负数。@Transactional(rollbackFor = Exception.class)一定要写，不然Spring默认只回滚RuntimeException，如果你的业务异常是一个继承Exception的类，事务会静默提交，导致数据错乱。
生成订单后，用户点击“支付”，这里只是模拟支付，直接调用支付Service把订单状态从0改为1，更新支付时间，同时把商品销量增加。如果你想让项目更真实，可以写一个支付接口，接收支付方式和订单号，校验订单必须是当前用户且状态为待付款，再更新状态，这就够了。
3.4 后台管理：Banner、商品上架与文件上传
后台管理模块和前台的认证要分开，通常是一套独立的管理员账号体系。管理员登录后，可以对商品分类、商品、Banner、订单进行管理。这里我重点讲两个实现细节。
第一个是Banner管理。首页Banner本质就是一张图、一个跳转链接、一个排序号和一个状态。后台维护这些数据，前台查询接口只查status=1的记录并按sort_order排序。管理端页面上传图片时，需要把图片保存到服务器本地磁盘或对象存储，并返回图片的访问URL。在Spring Boot本地环境，我建议把图片存到项目根目录下的upload/文件夹，然后配置一个静态资源映射，让/images/**能直接访问到磁盘上的文件。
java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/images/**")
.addResourceHandler("file:" + uploadDir + "/");
}
}
第二个是商品上架下架。管理员编辑商品时上传主图，录入价格和库存，点击上架后status变为1，前台立刻能在列表里看到。这里价格校验要注意：必须大于0，库存非负。后台列表本身也要分页，查询条件和前台不一样，需要显示所有状态商品，并支持按商品名称模糊查询。
商品图片上传可以使用MultipartFile接收，转换成UUID文件名，保存到磁盘。这里我踩过的坑是：使用IDEA开发时，Linux服务器和Windows路径分隔符不同，代码里不要写死\或/，用File.separator或者直接用Paths.get()来拼接。
3.5 前端页面的实现方案与静态资源处理
如果你选Thymeleaf做服务端渲染，前端页面结构可以这样规划：layout公共片段（头部、尾部、侧边栏）抽出来，用th:replace复用。页面分为首页、商品列表页、商品详情页、购物车页、结算页、订单列表页、登录页、注册页、后台管理页。Thymeleaf的语法比较简单，th:each循环遍历、th:if判断、th:href动态拼接，几个基础语法能覆盖80%的场景。
如果用Vue + Spring Boot前后端分离，我会单开一套项目结构：前端用Vue3，后端返回JSON。这种方案的难点不是后端逻辑，而是跨域和联调。跨域在后端加一个CorsConfiguration配置类就能解决，或者在Controller上加@CrossOrigin，但要注意如果加了拦截器，跨域预检请求OPTIONS也是会被拦截器拦截的，必须在拦截器里先放行OPTIONS请求，否则前端会一直报CORS错误。
我见过的很多毕设队伍会在“前后端分离”和“服务端渲染”之间纠结。我的建议是：如果你是单人完成、时间又紧，选Thymeleaf更稳，开发、部署、答辩演示都不会出幺蛾子；如果你本身熟悉Vue，想锻炼前后端分离能力，选Vue3 + Axios + Element Plus也行，但无形中会增加至少1到2周的联调时间。
4. 常见问题与排查经验实录
4.1 Spring Boot版本过高引发的依赖兼容问题
热门词里有“springboot版本太高”，这确实是新人最容易踩的坑。Spring Initializr默认生成的是最新稳定版，比如3.x，但你在网上找的教程、依赖、代码片段大多是2.x的。你跟着教程引入MyBatis starter时，教程里写的是org.mybatis.spring.boot:mybatis-spring-boot-starter:2.3.1，这个版本在Spring Boot 3.x下跑不动，因为javax.sql、javax.validation这些包被迁移到了jakarta包名下。具体表现就是启动时各种ClassNotFoundException: javax.servlet.*，或者Invalid value type for attribute 'factoryBeanObjectType'。
解决办法很简单：创建项目时就把Spring Boot版本锁定为2.7.18，JDK选8。如果你已经创建了3.x项目，那就去pom.xml里，把<parent>中的版本改成2.7.18，然后刷新Maven。注意改了版本后，如果用了jakarta.*开头的依赖也要同步改回javax.*。
4.2 MyBatis集成过程中的经典报错
每次提到MyBatis集成，绝对绕不开这几个报错。
第一个是Invalid bound statement (not found)。这个报错的意思是Mapper接口找到了，但找不到对应的XML里写的SQL语句。排查思路是：检查XML文件里的namespace是否和Mapper接口全限定名一致，检查<mapper>标签里的id是否和接口方法名一致，检查接口方法的参数类型和返回值类型是否和XML里的resultType/parameterType匹配，最后检查target/classes目录下有没有生成对应的XML文件。如果XML放在src/main/java下没被复制到classes里，需要在pom.xml里配置resources节点，把**/*.xml加入资源目录。
第二个是Cause: org.apache.ibatis.binding.BindingException: Parameter 'xxx' not found。这是多参数Mapper方法常见问题。解决办法是给每个参数加@Param("xxx")注解，或者在XML里用#{0}、#{1}这样按位置取值，但我推荐前者。
第三个是A query was run and no Result Maps were found for the Mapped Statement这种奇怪错误。一般是因为接口方法返回类型写成了List<Product>，但XML的resultMap没有配置，或者resultType和字段名对不上。数据库字段是下划线风格的create_time，实体类字段是驼峰风格的createTime时，你需要在application.yml里开启驼峰映射：
yaml复制mybatis:
configuration:
map-underscore-to-camel-case: true
这个开关一旦没开，查出来的对象里createTime一直是null，但你在数据库里明明有值，排查半天才发现是映射问题。
4.3 事务失效与循环依赖
Spring Boot项目里事务失效是典型的高级问题。有两个常见场景：
第一个场景是@Transactional加在同一个类内部的非事务方法调用事务方法上。Spring事务是通过代理实现的，同类内部调用的this.createOrder()根本不会经过代理，所以事务完全不生效。解决办法是把事务方法放在另一个Service里，或者用AopContext.currentProxy()这种比较hack的方式。
第二个场景是事务方法里自己捕获了异常并吞掉。比如：
java复制@Transactional
public void createOrder(...) {
try {
// 扣库存、生成订单
} catch (Exception e) {
log.error("create order error", e);
// 没有抛出异常，事务不会回滚
}
}
这样看起来好像“没有炸”，但库存和订单数据已经处于不一致状态了。正确做法是catch里记录日志后重新抛出RuntimeException或业务异常。
循环依赖在毕设里其实不多见，但如果出现了，Spring Boot 2.6之后的版本默认不允许循环依赖，启动直接报错。如果你确实需要临时开启，可以在application.yml里写spring.main.allow-circular-references: true。但更好的做法是重构结构，让Service之间的依赖是单向的，比如OrderService依赖ProductService，ProductService不要反向依赖OrderService。
4.4 JWT拦截器与Swagger冲突处理
热门词里有“springboot jwt 放开swagger”，这是在引入接口文档工具后常见的问题。如果你加了Knife4j或Swagger，访问/doc.html或/swagger-ui/index.html时发现页面打不开，或者打开后接口列表是空的，十有八九是JWT拦截器把所有请求都拦截了。解决办法是在WebMvcConfig里把Swagger相关路径加入排除列表：
java复制registry.addInterceptor(jwtInterceptor)
.addPathPatterns("/**")
.excludePathPatterns(
"/user/login", "/user/register",
"/product/**", "/category/**",
"/doc.html", "/webjars/**", "/v2/api-docs",
"/swagger-resources/**", "/swagger-ui/**", "/error"
);
还有一个细节：如果你的项目同时使用了Spring Boot的静态资源访问，比如上传的图片放在/images/**，而拦截器配置的是/**，那你上传后访问图片也会401。这些静态资源路径也要记得加入排除列表。
4.5 开发环境层面的小坑
我在标题相关的热搜词里看到“idea中springboot项目的application.yml不提示”“vscode如何启动springboot”这类，典型的开发环境问题也顺手整理一下。
IDEA里application.yml不提示，绝大多数情况是IDEA没有把yaml文件识别为Spring配置文件。解决办法是：鼠标右键application.yml，选择“Add as Spring Boot Configuration File”，然后重启IDEA的缓存（File -> Invalidate Caches）。如果还是不提示，检查IDEA版本，社区的免费版对Spring Boot的支持本来就有限，建议用IDEA Ultimate版本，或者安装Spring Boot Assistant插件。
VSCode启动Spring Boot项目，需要安装Java Extension Pack和Spring Boot Extension Pack，然后通过命令面板里的“Spring Boot Dashboard”启动项目。还有一个容易忽略的点：VSCode里如果pom.xml报错，通常是因为Maven的Java版本与项目要求的JDK不一致，需要在settings.json里设置java.configuration.runtimes，把Java 8的路径加进去。
还有一点关于打包部署：如果你用的是Spring Boot 2.7.18 + JDK 8，打包成jar后直接java -jar就能跑，比war包简单得多。如果你的服务器是Docker环境，可以用一个基础镜像加上你构建好的jar文件跑起来。这里不展开Docker命令，但记住一个原则：基础镜像选带JDK的镜像，版本必须和本地Java版本一致，不然容器启动就报UnsupportedClassVersionError。
5. 从完成到实用：后续可以做哪些扩展
如果你按上面的思路把基础商城做完，这个项目已经可以作为毕设或者简历项目交付了。但如果你想让它更有亮点，我觉得可以从这几个方向扩展。
第一个方向是接入Redis缓存。商品详情页的热度通常很高，可以把商品详情缓存到Redis，设置过期时间，后台修改商品时删除对应缓存。这一步能体现你对缓存策略和缓存一致性的理解。
第二个方向是引入消息队列。比如用户下单后发送一条消息，异步去更新销量、发送通知。这种“订单创建成功事件”的处理方式，在简历上写出来会让人眼一亮。但要注意，引入MQ意味着需要额外部署服务，并不是所有毕设环境都支持，自己权衡。
第三个方向是支付回调的模拟。真实电商系统里，支付成功是支付平台异步回调通知服务端的，不是前端点了“支付成功”就结束。你可以模拟一个回调接口，让逻辑更贴近真实业务。这个接口得有幂等性校验，不能被重复调用导致重复增加销量。
我个人经验是，这类的项目不要贪多求全，把核心链路做好做扎实，比堆砌一堆中间件更能体现能力。你的重点永远是把最简单的基础功能实现得可靠、可解释、可扩展。
最后再分享一个我实际做这类项目时的心得：数据库设计再怎么强调都不过分。很多代码上的坑，追根溯源都是表设计不合理导致的SQL复杂、逻辑混乱和边界漏判。比如订单快照字段没冗余，后面订单列表展示就会越写越别扭。你先把表结构设计到“能够顺畅回答评委老师的每一个追问”的水平，代码写起来就会顺很多。