董云舟“在线艺术品交易平台”这个题目，在Java后端方向的毕业设计里属于相当经典的电商类选题。它的经典不是因为“艺术品”三个字，而是因为它把电商系统的主链路完整覆盖了：商品展示、用户注册登录、购物车、下单、支付回调、订单管理、后台管理，一个不落。我拿这个题目完整做过一版，也帮人排查过不少类似项目的报错，今天把这些设计思路和落地细节一次讲清楚。如果你正准备拿这个题目练手或者做毕设，看完这篇文章，你至少能少踩八成我自己当初踩过的坑。
先给这个项目定个性：它不属于那种“从零写操作系统的硬核项目”，也不是“三天能糊弄完的玩具”。它的定位是——用主流Java技术栈实现一个业务链路完整、模块边界清晰、代码结构可扩展的Web应用系统。正因为它链路完整，才能训练到从需求分析到数据库设计、从接口开发到部署上线的全流程能力；正因为它业务量级不大，又不会让你陷进某个单一技术点里无法自拔。
这个项目适合三类人：一是准备做毕业设计或课程设计的本科生；二是想通过完整项目提升SpringBoot实战能力的自学者；三是刚进公司做Java开发、想了解标准业务系统是怎么组织代码的新人。配套的源码、讲解视频和设计文档，相当于把从需求到交付的完整过程拆开喂给你，你只需要跟着走一遍，把每个模块的“为什么”想明白，收获会比看十篇零散教程都大。
1. 项目整体设计与思路拆解
1.1 为什么“艺术品交易”这个选题值得做
很多人看到“艺术品”三个字，以为它是个垂直小众的方向。实际上，艺术品的核心交易模型和绝大多数电商系统一模一样：卖家发布商品、买家浏览加购、提交订单、完成支付、商家发货、买家确认收货。你把这个流程理顺了，换成一个卖手机的平台、卖课程的平台，骨架几乎不用动。
但艺术品和普通标品有两个关键差异，这两个差异恰恰是这个项目的亮点所在。第一，艺术品没有标准SKU，一幅画就是一件独立商品，没有“尺码”“颜色”这些规格属性，库存通常就是1，这反而简化了库存模型。第二，艺术品单价高、买家决策周期长，所以购物车、收藏、联系客服这类辅助功能就变得很重要，也让系统功能层次更丰富。
从毕设答辩的角度看，这个选题也比较好讲。答辩老师最怕的是“项目太简单、没东西可问”。艺术品交易平台天然带着“支付流程怎么处理”“并发下单怎么保证库存不超卖”“图片和附件怎么存储”“订单状态怎么流转”这些可深挖的点。你只要把这些问题的答案准备好，答辩环节基本是稳稳的。
1.2 技术选型的核心权衡与取舍
技术栈是这类项目最容易被问崩的地方。很多同学照着网上的源码抄，却说不清为什么用这个不用那个。这里我把核心选型和背后逻辑一起讲透。
后端框架我建议用SpringBoot 2.7.x，不是3.x。原因很实际：2.7.x基于Spring Framework 5.3，默认支持JDK 8，而大多数学校机房、个人电脑安装的还是JDK 8；SpringBoot 3.0开始强制要求JDK 17，且包名从javax.*迁移到了jakarta.*，很多老教程和老代码直接跑不起来。别小看这个差别——你网上搜到的十篇教程里，八篇都是基于JDK 8 + SpringBoot 2.x写的，跟着做不会踩版本坑。如果非要用3.x，就得接受“所有依赖都要换新版本”这个事实，纯属给自己加难度。
ORM层我推荐MyBatis-Plus，理由也很直白：MyBatis的Mapper接口写起来太啰嗦，一张表要配一个XML文件；MyBatis-Plus内置了单表CRUD方法，分页插件也是现成的，能用最少代码把业务跑通，同时保留了手写SQL的能力，多表查询该自己写还是自己写。JPA虽然省事，但复杂的动态查询和关联关系反而不好控制，对新手不友好。
前端方案这里要分情况说。如果你对Vue有基础，就用前后端分离：Vue 2 + Element UI + Axios，接口走JSON。如果你前端能力一般，我强烈建议直接用Thymeleaf服务端渲染，Controller里返回视图名称加Model数据，配合Bootstrap和jQuery，开发效率高很多。毕设的核心评价标准是“系统完整、逻辑清晰”，不是“前端炫酷”，先保证完成度。
其他组件按需引入：Redis主要用于存验证码、Token黑名单或热点数据缓存，单机部署时用它的默认配置即可；文件存储本地路径就行，图片上传后返回一个URL，不需要引入OSS，免得答辩时被追问“你的OSS费用怎么算”“AccessKey泄露怎么办”。支付这块也不要真接支付宝微信，用模拟支付回调，既安全又能把支付流程讲清楚。
1.3 整体模块划分与工程结构
系统从功能上分成两个端：前台用户端和后台管理端。前台包含用户注册登录、艺术品浏览与分类筛选、商品详情、购物车管理、订单提交与支付模拟、收货地址管理、个人中心；后台包含管理员登录、艺术品上下架、分类管理、轮播图管理、订单处理与发货、用户管理。
工程结构上，我建议按功能模块分包，而不是按技术层次分包。也就是不要搞controller、service、mapper这种扁平的包结构，而是按业务域来组织，比如user、artwork、cart、order、common，每个业务包内部再分controller、service、mapper、entity。这样做的最大好处是：改一个功能时，所有相关代码都在同一个包下，不会像无头苍蝇一样到处找文件。等你以后接触微服务工程，会发现这种按业务域分包的方式和微服务的拆分思路是完全一致的。
后端接口按REST风格设计，资源用名词复数表示，比如GET /api/artworks获取艺术品列表、POST /api/orders提交订单、PUT /api/orders/{id}/status修改订单状态。REST风格不是硬性要求，但统一风格会让接口的可读性和维护性高很多，这也是答辩时一个不小的加分项。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心模块拆解与数据模型设计
2.1 用户与权限模块
用户模块是所有系统的基础，但这个基础里也藏着不少坑。注册登录的安全要点主要有三个：密码不能明文存储、登录状态不能只靠前端传userId、后台接口要防止未授权访问。
密码存储用BCrypt加密，不要用MD5或SHA1。原因很简单：MD5是摘要算法，不是为密码存储设计的，它计算速度太快，配合彩虹表几秒钟就能把弱密码撞出来；BCrypt算法自带盐值，且计算速度可以调整，暴力破解成本高得多。Spring Security里内置了BCryptPasswordEncoder，即使你不用整个Spring Security，单独引入spring-security-crypto依赖就能直接用这个加密器。
登录状态这块，推荐用JWT（JSON Web Token）而不是传统Session。JWT的核心机制是：用户登录成功后，服务端生成一个包含用户标识和过期时间的签名Token返回给前端；前端之后每次请求都在Header里带上Authorization: Bearer <token>；服务端通过拦截器解析并校验Token，就知道当前请求是谁发起的。它最大优势是天然适合前后端分离，不需要在服务端维护Session，扩展性好。
不过JWT也有一个坑：服务端签发Token后，在Token过期之前是无法主动让它失效的。所以常见的做法是把Token过期时间设短一点（比如2小时），前端在请求时发现401就跳回登录页，让用户重新登录。有些项目还会用Redis记录Token白名单，但这会引入额外的复杂度，毕设阶段把过期时间控制好就够用了。
权限控制上，这个项目只需要区分普通用户和管理员两种角色。后台所有接口都要验证“当前登录用户是管理员”，可以在拦截器里解析完Token后，把用户信息存到ThreadLocal或RequestContextHolder中，然后在后台Controller里通过@RequireAdmin注解或简单的方法校验来判断。要注意的是，拦截器只校验“是否登录”，角色校验必须放在具体的业务层或专门的注解切面里，否则容易出现“普通用户调管理员接口”的越权漏洞。
2.2 艺术品商品模块
艺术品商品是这个平台的核心交易对象，它的字段设计比普通商品更讲究一些。基础字段包括：作品名称、作者、分类、描述、价格、封面图、详情图集、创作年代、尺寸、材质、版数等。其中“版数”是艺术品特有概念，指限量复制品的总数量和当前编号，这个字段能体现你考虑到了垂直行业特征，答辩时提一句会很加分。
商品状态要单独设计，不能只用一个status字段存0和1。我建议至少有四种状态：草稿（未上架）、已上架、已下架、已售出。已售出状态很重要——艺术品通常是单件或限量的，一件作品被下单并支付后，它就不应该再出现在商品列表里。这个状态位的流转逻辑，正是体现你理解了业务闭环的地方。
商品的图片处理也是这个模块的实操重点。不要直接存Base64字符串到数据库，也不要存MultipartFile对象，正确做法是：上传到服务器本地指定目录，数据库里只存图片的相对路径或URL。上传时要做三件事：校验文件类型（白名单：jpg、png、webp，别用黑名单）、限制文件大小（建议单张不超过5MB）、重命名文件（用UUID或时间戳，防止中文名和重名问题）。图片路径建议按日期分目录存储，比如/upload/2025/06/01/uuid.jpg，这样后续清理和迁移都方便。
商品列表页的查询筛选是接口设计的重点。前端一般需要支持：按分类筛选、按关键字模糊搜索（作品名和作者名）、按价格区间筛选、按上架时间或价格排序。这个用MyBatis-Plus的LambdaQueryWrapper动态拼接条件就能实现，不需要写复杂的XML。不过要注意：多条件组合时，Wrapper的条件要用StringUtils.hasText或ObjectUtil.isNotEmpty判断一下，避免参数为空时拼接出错误的SQL。分页用MyBatis-Plus的Page对象，前端传页码和每页条数，后端返回总条数、总页数和当前页数据列表。
2.3 购物车与订单模块
购物车是一个典型的“关联表”业务，它本质上是用户和商品之间的一张关系表，额外存储了数量、选中状态和加入时间。购物车接口设计比较简单：加入购物车、修改数量、勾选/取消勾选、删除条目、查询我的购物车。但有几个细节要注意：同一个用户对同一件商品重复“加入购物车”，应该做数量的累加而不是插入新记录，这需要在加入前先查询一次，或者在表上建(user_id, artwork_id)唯一索引，用INSERT ... ON DUPLICATE KEY UPDATE来处理。
订单模块是整个系统的核心，也是技术难点最集中的地方。下单流程涉及的步骤包括：校验用户是否登录、从购物车勾选条目生成订单明细、计算订单总金额、扣减商品库存（艺术品库存要置为已售出）、生成订单号和订单记录、清空对应购物车条目。这六个步骤必须在一个数据库事务里完成，任何一个步骤失败，整个下单操作都要回滚。这就是为什么下单Service方法必须加@Transactional注解。
库存扣减这里有一个经典问题——并发超卖。艺术品虽然库存只有1，但如果两用户同时看到一件“在售”艺术品并同时下单，不加控制的话两个订单都能成功。最简单的解决方案是使用数据库的乐观锁：更新库存时加条件WHERE stock > 0（对于库存为1的限量艺术品，就是UPDATE artwork SET status='已售出' WHERE id=? AND status='在售'，然后判断受影响行数，为0说明被抢走了，直接抛异常提示用户）。这个方案不需要引入Redis分布式锁，用数据库自身的原子性就解决了问题，也是面试官最想听到的答案之一。
订单号生成也值得说道。不要用数据库自增ID当订单号，一是会暴露平台订单量，二是多个表关联和后续扩展都不方便。推荐自己生成：时间戳（yyyyMMddHHmmss）+ 用户ID后四位 + 随机数。这样一眼就能看出下单时间，且并发下单时重复概率极低，是一个在答辩时容易讲清楚的实用细节。
2.4 数据库表设计要点
数据表是项目的地基，表设计得好不好，直接决定后面写代码的顺畅程度。这里给出核心表的设计思路，字段以实际代码为准，但结构八九不离十。
用户表t_user：主键id、用户名、密码（BCrypt密文）、昵称、头像、手机号、角色（0普通用户，1管理员）、状态（0禁用，1正常）、创建时间、更新时间。用户名要建唯一索引，这是登录的查询入口。
艺术品表t_artwork：主键id、作品名、作者、分类id、描述、价格（用decimal不用double，金额精度问题不能妥协）、封面图、图集（JSON字符串或逗号分隔）、创作年代、尺寸、材质、版数、库存、状态（0草稿，1在售，2下架，3已售出）、创建时间、更新时间。分类id建普通索引，status建普通索引，列表查询的核心条件就是这两个字段。
购物车表t_cart：主键id、用户id、艺术品id、数量、选中状态、创建时间、更新时间。建(user_id, artwork_id)联合唯一索引，既防止重复数据，也能在加入购物车时用ON DUPLICATE KEY UPDATE实现数量累加。
订单主表t_order：主键id、订单号（唯一索引）、用户id、订单总金额、订单状态（0待支付，1已支付，2已发货，3已完成，4已取消）、收货人姓名、收货人电话、收货人地址、下单时间、支付时间、发货时间、完成时间。订单状态机是这个表的灵魂，后面专门讲。
订单明细表t_order_item：主键id、订单id、艺术品id、艺术品名称（冗余存储，防止商品删除后订单里没名字）、封面图（同样冗余）、成交价格、数量。明细表的艺术品名称和价格一定要冗余下来，这是电商设计的基本常识——订单是快照，商品信息改了也不能影响历史订单。
收货地址表t_address：主键id、用户id、收货人姓名、电话、省市区、详细地址、是否默认。整套表设计里，t_order和t_order_item的主从关系是最值得在答辩时讲清楚的，一个订单对应多条明细，一对多关系在Java里用List<OrderItem>来映射。
3. 关键流程实现与实操记录
3.1 登录鉴权的完整实现
登录鉴权这个功能，网上教程很多，但能一次写对的很少。我按实战顺序把关键代码逻辑理一遍，你对照着自己的项目查漏补缺。
第一步是生成Token。引入jjwt依赖后，写一个JwtUtil工具类，核心方法就三个：generateToken(Long userId, String role)生成Token，parseToken(String token)解析Token，isTokenExpired(String token)判断是否过期。生成时把userId和role放进payload，设置过期时间，用secretKey做HMAC签名。
java复制public String generateToken(Long userId, String role) {
Date now = new Date();
Date expiryDate = new Date(now.getTime() + EXPIRATION_TIME);
return Jwts.builder()
.setSubject(String.valueOf(userId))
.claim("role", role)
.setIssuedAt(now)
.setExpiration(expiryDate)
.signWith(SignatureAlgorithm.HS256, SECRET_KEY)
.compact();
}
第二步是登录接口。Controller接收用户名和密码，Service里先根据用户名查用户，查到后检查状态是否正常，再用BCryptPasswordEncoder.matches(rawPassword, encodedPassword)比对密码。全部通过就生成Token返回，同时返回用户基本信息。
第三步是拦截器鉴权。写一个AuthInterceptor实现HandlerInterceptor接口，在preHandle方法里从请求Header取Token，解析校验通过就把userId和role放进request.setAttribute，然后放行；校验失败直接返回401状态码和统一错误信息。注册到WebMvcConfigurer时注意：登录接口、注册接口、商品列表和详情接口要放行，后台管理相关的接口要加/api/admin/**拦截路径，并单独校验角色。
这里补一句我实际踩过的坑：拦截器里解析Token时，jjwt库在Token过期或签名不对时会抛异常，很多新人直接让异常抛出去，结果Spring默认把异常渲染成一大段错误堆栈返回给前端。正确做法是在preHandle里用try-catch把所有解析异常捕获，统一封装成Result.error(401, "登录状态已过期")返回。这个细节看起来小，但前后端联调时能省非常多沟通成本。
3.2 下单流程与事务控制
下单接口是整个系统里最容易出bug的地方，没有之一。下面是我推荐的下单逻辑实现方式，按步骤拆解：
第一步，从请求参数里拿到购物车条目ID列表或直接拿到艺术品ID、收货地址ID。第二步，遍历查询艺术品，校验状态是否在售，在售才允许下单。第三步，计算订单总金额，累加每个商品的价格乘数量。第四步，扣减库存/锁定艺术品，核心是UPDATE t_artwork SET status = 3, stock = stock - 1 WHERE id = ? AND status = 1，看受影响行数是否大于0。第五步，插入订单主表记录和订单明细表记录，主表生成订单号，明细表一条一条插入。第六步，删除对应的购物车条目。
java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(Long userId, List<Long> cartItemIds, Long addressId) {
Address address = addressMapper.selectById(addressId);
if (address == null || !address.getUserId().equals(userId)) {
throw new BusinessException("收货地址无效");
}
// 1. 查购物车条目和商品
List<CartItem> cartItems = cartItemMapper.selectBatchIds(cartItemIds);
// 2. 计算金额 & 校验商品可售状态
BigDecimal totalAmount = BigDecimal.ZERO;
for (CartItem item : cartItems) {
Artwork artwork = artworkMapper.selectById(item.getArtworkId());
if (artwork == null || artwork.getStatus() != 1) {
throw new BusinessException("商品已下架或已售出");
}
totalAmount = totalAmount.add(artwork.getPrice().multiply(
BigDecimal.valueOf(item.getQuantity())));
}
// 3. 乐观锁扣减库存
int locked = artworkMapper.lockArtwork(cartItems);
if (locked != cartItems.size()) {
throw new BusinessException("部分商品已被抢购，请刷新后重试");
}
// 4. 生成订单
Order order = new Order();
// 设置订单号、金额、状态等
orderMapper.insert(order);
// 5. 插入明细
for (CartItem item : cartItems) {
OrderItem orderItem = new OrderItem();
// 设置关联字段和冗余字段
orderItemMapper.insert(orderItem);
}
// 6. 清空购物车
cartItemMapper.deleteBatchIds(cartItemIds);
return order;
}
这里三个容易忽略的细节：一是@Transactional注解一定要加rollbackFor = Exception.class，否则只对RuntimeException生效，你自定义的BusinessException如果继承的是Exception，事务不会回滚；二是异常一定要在事务方法内部抛出，不能在Controller层try-catch吞掉，否则事务照样不生效；三是订单主表和明细表的插入顺序，一定是主表先插，拿到主键id后再插明细表。
3.3 模拟支付回调与订单状态流转
真实项目接支付宝微信支付，流程会比较长：前端调后端创建支付订单接口，后端返回支付参数，前端拉起收银台，用户支付成功后，支付平台通过异步回调通知后端，后端校验签名后修改订单状态。毕设阶段做演示，直接用“模拟支付”按钮代替。但模拟支付不是随便把订单状态改成已支付，而是要把回调这个核心逻辑模拟出来。
我的做法是：下单成功后，订单状态为“待支付”。前台订单详情页显示“模拟支付”按钮，点击后调POST /api/pay/simulate/{orderNo}接口。这个接口的逻辑是：先根据订单号查订单，校验订单确实属于当前登录用户、状态确实是待支付；然后主动模拟“支付回调处理”，更新订单状态为已支付、记录支付时间；扣减一下商品库存或者确认锁定；最后返回支付成功。
java复制@Transactional(rollbackFor = Exception.class)
public void simulatePay(String orderNo) {
Order order = orderMapper.selectByOrderNo(orderNo);
if (order == null) {
throw new BusinessException("订单不存在");
}
if (order.getStatus() != OrderStatus.PENDING_PAY) {
throw new BusinessException("订单状态不允许支付");
}
order.setStatus(OrderStatus.PAID);
order.setPayTime(new Date());
orderMapper.updateById(order);
}
订单状态机是一个可以拿出来重点讲的设计点。这个项目的订单状态流转建议设计成：
- 待支付：下单成功创建
- 已支付：模拟支付成功后
- 已发货：后台管理员发货后
- 已完成：买家确认收货后
- 已取消：待支付状态超时或用户主动取消
前后端都要校验状态流转的合法性。比如“已支付”的订单不能再次支付，“已发货”的订单不能直接改成“已完成”，必须由买家确认。这些状态流转的控制放在Service层用if判断即可，不用引入太复杂的状态机框架，但逻辑必须严密。
有一点实际经验要提醒你：订单状态字段建议用Integer，不要用String存中文。状态枚举写一个常量类或枚举类统一管理，比如OrderStatus.PENDING_PAY，这样代码里不会出现魔法数字，可读性强很多，答辩时也能说明你注意了代码整洁度。
3.4 前后端接口规范与联调
前后端分离项目最怕接口格式不统一，前端拿不到数据、后端觉得没问题，最后变成一场拉锯战。我的建议是，项目第一天就把统一返回结构定好，后面所有接口都必须遵守。
统一返回结构我建议用这样的格式：code表示业务状态码（200成功，401未登录，403无权限，500系统错误），message表示提示信息，data表示业务数据。写一个通用类Result，提供Result.success(data)、Result.error(code, msg)等静态方法。同时配合全局异常处理器@RestControllerAdvice，把业务异常、参数校验异常、系统异常分别捕获，统一包装成Result返回，前端只用处理一种数据结构。
java复制public class Result<T> {
private Integer code;
private String message;
private T data;
public static <T> Result<T> success(T data) {
Result<T> result = new Result<>();
result.setCode(200);
result.setMessage("success");
result.setData(data);
return result;
}
public static <T> Result<T> error(Integer code, String message) {
Result<T> result = new Result<>();
result.setCode(code);
result.setMessage(message);
return result;
}
}
联调时最容易出现的问题是跨域配置。SpringBoot后端的接口默认不允许跨域调用，前端Vue开发服务器跑在8080端口，后端跑在9090端口，两边一对接就报CORS错误。解决方式是加一个WebMvcConfigurer配置类，重写addCorsMappings方法，允许所有路径跨域、允许所有来源和所有方法。要提醒的是：如果前端是用http访问、后端是https，或者生产环境有Nginx代理，跨域配置还可能带来额外问题，但毕设本地联调阶段，放开跨域限制是最直接的解决办法。
接口联调的另一大坑是参数格式不一致。前端用Axios提交表单数据到后端，默认是application/x-www-form-urlencoded，后端用@RequestParam接收没问题；但如果前端提交的是JSON，就要用@RequestBody接收，且实体类必须有对应的属性和getter/setter。很多人纠结“为什么我用@RequestBody接收不到”或者“为什么前端报400”，八成是Content-Type和后端接收注解不匹配。我建议统一规范：GET请求用@RequestParam或路径变量，POST/PUT请求统一走JSON+@RequestBody，前后端都按这个约定来，联调会顺畅很多。
4. 常见问题与排查技巧实录
4.1 本地启动阶段的经典报错
这个项目在本地跑起来的过程中，报错基本集中在那几个点。我把高频问题整理成一个速查表，你遇到时直接对照排查。
数据库连接失败是最常见的一个。报错信息通常是Access denied for user 'root'@'localhost'或者Communications link failure。前者检查用户名密码是否正确，后者检查MySQL服务有没有启动、端口是不是3306、application.yml里的连接地址有没有写错。另外在MySQL 8.0下，驱动类名要写成com.mysql.cj.jdbc.Driver，旧的com.mysql.jdbc.Driver会有警告但一般也能用，不过建议还是用新版驱动。
时区问题也经常出现，报错是The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。这个在数据库连接URL后面加参数解决：serverTimezone=Asia/Shanghai。如果还不行，就在MySQL里执行SET GLOBAL time_zone = '+8:00'，一劳永逸。
端口冲突是启动时报Port 8080 was already in use。解决方法很多，我习惯在配置里改端口，把后端的启动端口改成9090，避免和前端Vue开发服务器的8080冲突。这个细节看着小，但能避免非常多麻烦。
热词里提到的“SpringBoot版本太高”导致的编译或运行问题，本质上是SpringBoot 3.x和SpringBoot 2.x的兼容性差异引起的。最典型的三个差异：一是JDK版本，3.x必须JDK 17+；二是javax.servlet相关的包名全部改成jakarta.servlet，你代码里如果引用了旧的HttpServletRequest，在3.x下会编译失败；三是Spring Security 6的配置方式全面改了，WebSecurityConfigurerAdapter被废弃。如果你用的是2.7.8版本，这些都不会遇到。我的建议很直接：没有特殊原因就别追新，毕设求稳是第一位的。
4.2 事务与并发相关的坑
事务失效是此类项目里最容易踩又最难发现的坑。你以为加了@Transactional就万事大吉，结果数据写到一半异常了，数据库里却留下了半截数据。我总结了三类引发事务失效的经典场景，你们对照检查：
第一类，方法自调用。同一个类里的方法A调方法B，B上面加了@Transactional，这个事务不会生效。因为Spring事务是通过代理对象实现的，自调用走的是this引用，跳过了代理。解决方法是把B方法放到另一个Service类里，或者自己注入自己，但后者写法比较绕，一般直接拆类更干净。
第二类，异常被catch住了。事务方法内部调用了一个方法，这个方法内部异常被try-catch捕获并处理掉，事务方法正常返回，事务自然就提交了。解决方法是：底层方法只抛异常不处理，由事务方法统一捕获并决定是否回滚，或者抛出RuntimeException让事务管理器感知。
第三类，checked Exception默认不回滚。前面说过，Spring默认只在抛出RuntimeException或Error时才回滚，普通的Exception异常不会触发回滚。这个坑极其隐蔽，因为你在IDEA里看着方法“确实抛异常了”，但数据就是没回滚。解决方法是@Transactional(rollbackFor = Exception.class)，明确告诉Spring所有异常都回滚。
并发场景这里再补充一个点：如果你的项目用了“查询商品数量判空再更新”的两步写法，并发下单时会出现超卖。比如代码先select查库存是否大于0，再update扣减库存，这两步之间如果有两个请求同时通过了查询，就会都执行更新，库存变成负数。正确做法就是前面的“带条件的UPDATE”，把检查和扣减合并成一条原子SQL，数据库会帮你挡住并发。这个解决方案在答辩时值得重点讲，它是“从业务思考落到技术实现”的典范例子。
4.3 安全与权限校验注意点
毕设项目虽然不要求达到金融级别安全，但基本的安全意识要有，因为答辩老师一定会问“你的系统安全吗”。
最基础也最严重的一个漏洞是水平越权。比如普通用户A登录后，直接改URL里的订单ID，比如GET /api/orders/100，就能看到用户B的订单详情。这种问题在你自己写的代码里非常容易漏掉。解决思路是：所有涉及“查某个用户的资源”的接口，都要校验当前登录用户ID和资源归属用户ID是否一致。比如查订单详情，不能只selectById，要selectByIdAndUserId(id, loginUserId)。这层校验写在Service层，不要只靠前端按钮隐藏。
越权漏洞是“改参数就能看到别人的数据”，SQL注入是“在参数里拼接SQL语句直接拖库”。MyBatis-Plus的LambdaQueryWrapper和#{}占位符能防止大部分注入问题，但如果你在某些复杂查询里用了${}拼接，就一定要注意过滤。搜索引擎搜一下“MyBatis ${} #{}区别”，记住一条原则：#{}是预编译占位符，${}是字符串替换，默认能用#{}的地方绝对不用${}。
还有一个容易被忽略的安全点是金额和数量参数。下单时，前端传过来一个商品id和数量，后端如果直接用前端传的金额计算订单总额，那用户把价格改成1分钱就下单成功了。正确做法是：后端根据商品id从数据库查出真实价格来计算总金额，前端传的金额一律不信任。这个点在答辩时经常被问到，回答好了会显得你确实有生产经验。
4.4 答辩演示与后续扩展建议
答辩演示这个环节，很多同学栽在“临场翻车”上。这里给你几个实操建议。第一，准备一套独立的演示数据，不要用你开发时随手造的数据。艺术品名称、价格、图片要像样，一上来让人觉得你确实认真做了。第二，演示流程提前走三遍，从登录到下单到后台发货，每个按钮点哪里、等待几秒，心里要有数。第三，故意准备一个“报错演示”，比如重复支付同一笔订单、访问一个不存在的详情页，展示你系统的异常处理和友好提示，这反而比一直演示成功更有说服力。
答辩问答环节，老师最爱问的问题基本集中在这几类：SpringBoot的自动装配原理是什么、MyBatis-Plus和MyBatis的区别、事务什么时候会失效、JWT和Session的区别、项目有没有考虑并发场景、数据库为什么这样设计。这些问题的答案，在这篇文章里其实都已经覆盖到了。建议你把每个问题写成三句话左右的答案，背熟但不死记，用“我项目里就是这样处理的”来回答，比背定义效果好太多。
至于这个项目本身的后续扩展，我结合自己经验说几条：一是把模拟支付替换成真实的微信支付/支付宝沙箱支付，难度不大但加分明显；二是引入Redis缓存艺术品详情接口，顺便讲讲缓存穿透和缓存击穿；三是加一个简单的推荐功能，根据用户浏览记录推荐同类艺术品；四是做数据统计报表，比如后台展示每日订单量和销售额，前端用ECharts画折线图。无论选哪条，你的项目深度都比“只做基础功能”高一个档次。
结尾
整个项目从零到一做完，我最大的体会是：这类全栈业务系统的难点从来不在某个单一技术点上，而在于把一条完整业务链路的前前后后想清楚。数据库表怎么设计、接口怎么划分、订单状态怎么流转、异常怎么处理，每一步都不难，但每一步都要有逻辑支撑。当初我调下单事务的bug调了一个晚上，最后发现只是异常被try-catch吞了；查越权问题查了半天，发现只是selectById没加用户条件。这些坑一一踩过之后，你对SpringBoot、对Web开发的整体理解，会比你刷十套面试题都管用。
最后再分享一个小技巧：做完项目后，把每个核心模块的“为什么这么做”写成一页纸的笔记，比如“为什么用BCrypt”“为什么订单表要冗余商品名称”“下单为什么用乐观锁”。这页纸不仅是答辩时的答题提纲，更是你面试时最有说服力的项目经验。这个题目的价值，正在于此。