SpringBoot医疗保健品商城毕设实战：从业务设计到高并发扣库存

春日毕业设计旺季又快到了，每年这个时候后台都能收到一堆私信，问 SpringBoot 商城类课题怎么下手。今年问得尤其多的是这个题目——医疗保健品销售系统。说实话，这个题面看起来“平平无奇”，但它恰好踩在了当下最热的两个点上：一是大健康赛道，二是电商交易闭环。和普通图书商城、零食商城相比，保健品系统多了一层医疗属性，商品信息、分类管理、营销玩法都要更严谨，这就让它在毕业设计里既有辨识度，又不至于难到做不完。

这篇内容我会以 SpringBoot 保健品商城为原型，把从业务拆解、技术选型、数据库设计、后端接口实现，到营销模块、并发扣库存、答辩高频问题等一条龙讲清楚。不管你是已经动工一半，还是刚把题目定下来，这篇文章都值得你花二十分钟读完。涉及的代码都是 MyBatis-Plus + SpringBoot 3 这套实用组合，考虑到大部分院校的毕设环境，我会尽量兼顾可复现性。

1. 这个系统到底要解决什么问题——从毕设题面拆解业务全貌

开始写代码之前，我建议你先做一次业务解构，搞清楚题目里的每个形容词都在暗示什么功能。

1.1 “销售系统”“商城平台”“营销管理系统”三个词的实际含义

不少同学看到这个标题会困惑：又是销售系统，又是商城平台，又是营销管理系统，到底是让我做几个系统？

答案是一个系统，但要有多个端。拆开看是这样的：面向 C 端用户的商城前台负责商品的展示、搜索、下单、支付、订单跟踪；隐藏在后面的运营管理后台负责商品上架审核、分类管理、库存维护、订单处理、用户管理、优惠券发放、销售数据统计。这个“后台管理”就是题面里说的“运营平台”和“营销管理系统”的落点。换句话说，如果只做了一套用户的购买页面，没有管理后台，答辩时导师一句“你的运营人员怎么维护商品数据”就能让你卡壳。

保健品这个领域还有一个特殊点：它介于普通商品和药品之间。系统里应当体现这一层差异化——例如商品详情页可以补充适宜人群、食用方法、保健功能、注意事项等字段，后台在发布商品时需要填写更完整的资质相关信息。虽然只是字段层面的扩展，但它契合了“医疗健康产品”这个题眼，也是答辩时很容易展开的功能亮点。

1.2 原型系统的用户角色与核心业务流程

从角色维度划分，系统可以设计成三类用户：

核心业务流程是一条典型的电商闭环：用户注册 → 浏览/搜索商品 → 加入购物车 → 提交订单 → 支付 → 后台发货 → 用户确认收货 → 订单完成。在这条主链路之外，还有一条营销链路：运营配置优惠券 → 用户领取 → 下单抵扣 → 订单金额计算；以及一条数据链路：订单产生 → 统计数据更新 → 后台以图表展示销售趋势。

之所以强调要先画清楚这两条链路，是因为 SpringBoot 商城项目的难点从来不在 CRUD，而在于状态一致性——订单状态怎么流转、库存什么时候扣减、优惠券用了之后怎么防止重复使用，这些问题梳理不清楚，写代码的时候就会处处打补丁。

1.3 功能清单：照着做就不会漏功能

基于以上分析，这里给出一份可以直接当需求文档用的功能清单：

• 用户端：手机号/用户名注册、登录（JWT 鉴权）、个人信息维护、收货地址管理、商品列表与分类筛选、商品关键字搜索、商品详情、购物车增删改、提交订单、模拟支付（支付宝沙箱/余额支付）、取消订单、订单列表与详情、优惠券领取与使用、积分累计与兑换、健康资讯展示
• 管理端：管理员登录、商品分类管理、商品信息管理（含适用人群等字段）、库存管理、订单列表与发货操作、用户管理、优惠券管理（创建/发放/停用）、会员等级配置、销售数据统计（ECharts图表）、运营账号管理
• 系统层面：统一异常处理、参数校验、JWT 拦截器、全局跨域配置、接口数据格式统一封装

这份清单应该能满足绝大部分院校对于毕设功能完整度的要求。如果你学有余力，还能再加一个“健康评测问卷”功能，用户填写问卷后系统推荐合适的保健品，这就是一个非常加分的个性化推荐场景——用简单的标签匹配算法就能实现，不需要上机器学习。

2. 技术选型不是堆砌——SpringBoot 单体架构的克制与理由

毕设选题另一个容易踩的坑是技术选型“过度设计”。有的同学一上来就上微服务、Redis 集群、消息队列，结果是花了整个毕设周期在调环境，业务代码却没写几行。

2.1 为什么 SpringBoot 3 + MyBatis-Plus 是当前最优组合

先从主角 SpringBoot 说起。它最核心的价值是自动配置和起步依赖。传统 SSM 项目里你要手动配置数据源、事务管理器、MyBatis 的 SqlSessionFactory、SpringMVC 的视图解析器，一套组合拳下来配置文件几百行。SpringBoot 把这些全部封装成约定，你只要引入对应的spring-boot-starter-*，框架自动完成装配。这就是为什么它能成为当前绝大多数电商类毕设的首选框架。

MyBatis-Plus 是在 MyBatis 基础上做的增强工具。它保留了 MyBatis 手写 SQL 的灵活性，同时内置了BaseMapper，单表 CRUD 不用写一行 SQL，分页插件也内置了。比如你要查保健品商品列表，只需要：

public interface ProductMapper extends BaseMapper<Product> { }

然后注入 Service 层就能直接使用selectList、selectPage等方法。这种“单表零 SQL、复杂查询手写 XML”的模式，非常适合毕设这种开发周期短、业务复杂度适中的场景。

2.2 配套组件的选型思路：缓存、鉴权、支付、图表

选配套组件时，我会用下面这个标准来衡量：它解决的必须是一个明确的问题，而且替代成本要低。

这里我特别想说一下鉴权方案。很多教程推荐 Spring Security + JWT，但 Spring Security 的过滤器链机制对新手来说理解成本相当高，配置不当容易出现“接口一直被拦截”或“放行失效”的问题。相比之下，Sa-Token 的登录校验就简单直白得多：

// 登录成功后 StpUtil.login(userId); // 校验当前请求是否已登录 StpUtil.checkLogin();

如果你用的是 JWT，自己写拦截器也完全够用，下面这段就是一个很清晰的可复现方案：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { throw new BusinessException(401, "登录状态已过期，请重新登录"); } } throw new BusinessException(401, "未登录，请先登录"); } }

2.3 环境版本怎么搭配才不容易出问题

版本踩坑是 SpringBoot 新手绕不过去的坎。我建议直接采用 SpringBoot 3.x 主线，JDK 17 起步。因为 3.x 是基于 Jakarta EE 的，如果是 SpringBoot 2.x 的教程，javax.*的包名在 3.x 里会直接编译报错。

推荐一套经过验证的版本组合：

• JDK：17
• SpringBoot：3.1.x 或 3.2.x
• MyBatis-Plus：3.5.x（注意要用mybatis-plus-boot-starter且版本适配 SpringBoot3）
• MySQL：8.0
• Redis：6.x/7.x 均可，Windows 环境用 5.x 也够
• Hutool：5.8.x（工具类库，强烈推荐，能让代码量减少三成）
• Lombok：最新版即可

数据库连接池首选内置的 HikariCP，它是 SpringBoot 2.x 之后默认的连接池，性能和稳定性都经过生产级验证，不需要额外引入 Druid，减少一个需要配置的组件就减少一类出问题的概率。

3. 商品、订单、库存三张核心表的表结构设计——后端开发的第一道分水岭

就以我自己的经验来看，表结构设计是拉开毕设质量差距的第一步。很多同学的代码写得很痛苦，不是因为 SpringBoot 难，而是因为数据库表设计不合理，导致后面查询逻辑拧成一团乱麻。

3.1 商品表的扩展字段如何体现“保健”属性

保健品的商品表和普通商品的差异主要在字段上。基础的商品字段已经够多，再加上保健属性的字段，很容易让表看起来臃肿。我的建议是：主表只保留公共字段，保健属性可以用 JSON 字段或者单独的商品详情表存储。

主表的核心字段如下：

这里的suitable_people、health_function、usage_method就是保健品区别于普通商品的关键字段。后台商品表单里把它们做成下拉选择或文本域，前端详情页用图标+文字的形式渲染出来，一眼就能看出这个项目的业务是有真实场景支撑的。

3.2 订单状态机设计：用常量去代替到处散落的魔法数字

订单表是最容易“写乱”的一张表。每个环节都可能改订单状态，如果代码里直接写死数字，比如order.setStatus(1)，过两周你自己都忘了 1 代表什么。

推荐的方案是建一个OrderStatus常量类，把订单状态集中管理：

public interface OrderStatus { /** 待支付 */ Integer PENDING_PAYMENT = 0; /** 已支付，待发货 */ Integer PAID = 1; /** 已发货 */ Integer SHIPPED = 2; /** 已收货，订单完成 */ Integer COMPLETED = 3; /** 已取消 */ Integer CANCELLED = 4; /** 退款中 */ Integer REFUNDING = 5; }

订单状态流转的关键规则有两条，写业务代码时最容易出错：

1. 只有“待支付”状态的订单才能取消或去支付，跨状态操作必须拦截。
2. 用户确认收货只有“已发货”状态才能触发，避免重复确认把状态改成“已完成”。

关于状态校验，我的建议是不要只在 Service 层写一堆 if 判断，更优雅的做法是结合一个小型状态机枚举类。当然，在毕设阶段用常量类 + Service 层判断已经足够了，重点是把校验逻辑集中起来，不要散落到每个 Controller 里。

3.3 订单与商品之间的关联：为什么必须有订单明细表

订单明细表的必要性是不少同学会忽略的。有人图省事，在订单表里加一个product_ids字段，用逗号分隔商品 ID，下单的时候存进去，查订单的时候再拆分出来。

这种设计在余额充足、货品单一的小项目里勉强能用，但在正规系统里完全不可行。订单生成之后，商品价格、名称都可能被运营修改，如果用订单表直接关联商品表的实时价格，用户查看历史订单时显示的可能已经是改价后的数据了，这是不合理的。

正确的做法是订单表只记录订单层级的信息——订单号、总金额、用户ID、状态、支付时间、发货时间、收货地址快照等；商品级信息全部放到订单明细表：

public class OrderItem { private Long id; private Long orderId; // 关联订单 private Long productId; // 商品ID private String productName; // 商品名称快照 private String productImage; // 商品图片快照 private BigDecimal price; // 下单时的单价快照 private Integer quantity; // 购买数量 private BigDecimal totalPrice; // 小计 }

“商品名称快照”这个思路是关键，它不是冗余，而是为了保持订单历史数据的一致性。这个细节在答辩时主动讲出来，导师会认为你真的考虑过实际业务场景。

4. 营销管理模块——保健品商城区别于普通商城的设计胜负手

标题里特别强调“营销管理系统”，这个模块值得你重点发力。从电商产品的角度来说，商城的免费流量池就那么大，要提升复购率和客单价，必须依靠营销工具。

4.1 优惠券系统的数据模型与防重复使用逻辑

优惠券在毕设项目中属于“看起来简单，做起来全是细节”的模块。它的表结构至少涉及三张表：

• coupon：优惠券模板表，包含满减门槛、优惠金额、发行总量、已领取数量
• user_coupon：用户领取记录表，包含用户ID、优惠券ID、状态（未使用/已使用/已过期）
• 也可以考虑增加coupon_scope表做适用范围限制，比如指定商品分类才可用

下单时的核心逻辑是判断一张券能不能用于当前订单。这里有一个特别容易犯的错误：只检查了用户是否领取，没检查使用门槛和有效期。完整判断条件如下：

public boolean isCouponValid(Coupon coupon, UserCoupon userCoupon, BigDecimal orderAmount) { // 1. 必须是未使用状态 if (userCoupon.getStatus() != 0) { return false; } // 2. 必须在有效期内 if (coupon.getEndTime().isBefore(LocalDateTime.now())) { return false; } // 3. 订单金额必须达到使用门槛 if (orderAmount.compareTo(coupon.getMinAmount()) < 0) { return false; } // 4. 是否有分类限制 if (coupon.getLimitCategory() != null && !isCategoryMatch(coupon.getLimitCategory(), orderItems)) { return false; } return true; }

防重复使用的关键是在“用户下单使用优惠券”这个动作上做好并发控制。最简单的做法是在更新用户优惠券状态时加上条件更新：

boolean updated = userCouponService.update( new LambdaUpdateWrapper<UserCoupon>() .eq(UserCoupon::getId, userCoupon.getId()) .eq(UserCoupon::getStatus, 0) // 关键：只能从未使用状态改为已使用 .set(UserCoupon::getStatus, 1) ); if (!updated) { throw new BusinessException("优惠券已被使用"); }

这种“乐观更新”的方式，即便两个请求同时进来，数据库层面的更新条件也保证了只有一个能成功。

4.2 会员等级与积分体系设计：让营销模块形成闭环

积分体系和会员等级是保健品这个高复购产品品类特别适合的营销机制。用户可以靠积分享受折扣、兑换小包装试用装；运营可以根据会员等级做差异化营销。

基础表设计如下：

• member_level：等级配置表，包含等级名称、所需积分下限、折扣率
• user_points：积分余额表，一个用户一条记录
• points_record：积分流水表，增加/扣减明细，保证积分可追溯

积分变动有一个通用规则：增加积分必须写流水，扣减积分必须先查余额。举个例子：

@Transactional(rollbackFor = Exception.class) public void addPoints(Long userId, int points, String orderNo) { // 幂等判断：同一订单不能重复加积分 Integer count = pointsRecordService.count(new LambdaQueryWrapper<PointsRecord>() .eq(PointsRecord::getSourceNo, orderNo)); if (count > 0) { return; } // 增加积分 userPointsService.update(new LambdaUpdateWrapper<UserPoints>() .eq(UserPoints::getUserId, userId) .setSql("points = points + " + points)); // 写流水 PointsRecord record = new PointsRecord(); record.setUserId(userId); record.setChangePoints(points); record.setSourceNo(orderNo); pointsRecordService.save(record); }

“同一订单不能重复加积分”这个幂等判断，就是我在实际项目里踩过的坑——支付平台回调如果重复通知，就会被执行两次，造成用户积分异常增加。在答辩时把这段逻辑讲出来，说服力非常强。

4.3 满减活动和套餐组合：营销配置化的简单落地方式

除了优惠券和积分，保健品商城还可以做满减活动、满赠活动、组合套餐。这些功能如果能做成“配置化”，而不是把规则写死在代码里，就会显得很高级。

我的建议是设计一张promotion活动表：

然后在购物车结算时，统一走一个PromotionCalculator，按照“先算单品价格 → 匹配满减活动 → 叠加优惠券 → 计算最终应付金额”的顺序来处理。这个顺序背后是电商规则里的优先级约定：平台级优惠优先于店铺级优惠，满减和优惠券是否互斥要根据规则决定。

在毕设层面，只要保证逻辑自洽并说明规则即可，不需要过分追求真实世界的所有边界条件。

5. 下单和扣库存：高并发场景下的小型技术改造

下单扣库存是整个后端实现里最容易写崩的地方。这里把演进过程拆开讲讲，你对照自己的实现看卡在哪一步。

5.1 第一步：先能跑通——不加控制的库存扣减

最直接的写法是：

Product product = productService.getById(productId); if (product.getStock() < quantity) { throw new BusinessException("库存不足"); } product.setStock(product.getStock() - quantity); productService.updateById(product);

这是“先查再改”的模式。问题在于：如果两个请求同时查到了库存为 10 的商品，都认为库存够，然后都做了减 1 的操作，最终结果是库存变成 9，而不是 8。这就是并发环境下的经典超卖问题。

在毕设演示时，单机单用户测试几乎不会暴露这个问题，但一旦导师让两个人同时下单，或者用 JMeter 压一下，问题就出来了。与其到时候手忙脚乱，不如提前用下面的方案。

5.2 第二步：对库存字段做乐观锁改造

MyBatis-Plus 对乐观锁有非常好的支持。核心做法是给商品表加上version字段，更新时带上版本号条件：

@Version private Integer version;

然后在配置类里启用乐观锁插件：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor()); return interceptor; } }

这样上面的扣库存代码可以改成：

Product product = productService.getById(productId); if (product.getStock() < quantity) { throw new BusinessException("库存不足"); } product.setStock(product.getStock() - quantity); boolean updated = productService.updateById(product); // 并发时version不匹配会返回false if (!updated) { throw new BusinessException("操作太频繁，请重试"); }

乐观锁解决的是“丢失更新”问题，但要注意它也有局限：如果并发量非常大，很多请求会因为版本号冲突失败后返回提示，用户体验上会显得“抢不到”。不过对这个体量的项目来说，完全足够了。

5.3 第三步：如果需要更好的体验——Redis 原子扣减方案

如果你的毕设想冲刺一下高性能表现，可以用 Redis 做库存预扣减。方案是在商品上架/修改库存时，把库存同步到 Redis：

stringRedisTemplate.opsForValue().set("stock:product:" + productId, String.valueOf(stock));

下单时使用 Redis 的原子操作扣减：

Long remain = stringRedisTemplate.opsForValue() .decrement("stock:product:" + productId); if (remain < 0) { // 扣超了，需要加回来 stringRedisTemplate.opsForValue().increment("stock:product:" + productId); throw new BusinessException("库存不足"); }

decrement是原子操作，多个请求同时执行时 Redis 内部会排队，避免超卖。订单支付超时或被取消时，再increment把库存加回去。

这里要特别提醒一个容易忽视的点：Redis 里的库存最终要和数据库里的库存保持一致。比较稳妥的做法是：Redis 扣减成功 → 创建订单 → 支付成功 → 再扣减数据库库存；支付超时取消的，Redis 和数据库都要回补。至于商品详情页展示的库存，直接读 Redis 就好，数据库库存作为最终对账依据。

5.4 防超卖的金额计算：购物车结算的含税与优惠顺序

下单时计算出正确的应付金额，也是极其容易出 bug 的地方。如果商品价格是 19.9 元，买 3 件，直接19.9 * 3 = 59.7没错。但如果你用了浮点数double去计算，可能会出现59.699999999999996这种结果。

所以在涉及金额计算时，务必遵循两条规则：

1. 金额字段全部使用BigDecimal，数据库对应decimal(10,2)。
2. 单价 × 数量 = 小计，所有商品小计求和 = 商品总额，然后商品总额减去优惠金额 = 应付金额。

顺序不要搞反，更不要直接把优惠金额按比例分摊到每个商品上——那是电商平台的进阶玩法，毕设阶段用总额优惠即可。下面的代码是一个结算计算的示例：

BigDecimal totalAmount = BigDecimal.ZERO; for (CartItemDTO item : cartItems) { BigDecimal subtotal = item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())); totalAmount = totalAmount.add(subtotal); } // 满减活动 BigDecimal discount = promotionCalculator.calculateDiscount(totalAmount); BigDecimal payable = totalAmount.subtract(discount); // 优惠券 if (coupon != null && couponValidator.isValid(coupon, payable)) { payable = payable.subtract(coupon.getDiscountAmount()); } // 最终确保不为负数 payable = payable.max(BigDecimal.ZERO);

6. 数据可视化与运营后台——让导师眼前一亮的统计报表

运营后台是整个系统里“管理端”价值的直接体现。很多毕设项目后台只做了普通 CRUD，数据展示全靠表格，缺少一个像样的统计分析页面。而这个题目里“运营平台”的定位，实际上暗示了统计分析功能应当被认真对待。

6.1 基于订单数据的统计指标

运营后台的首页可以考虑做成数据看板，直观展示以下指标：

• 今日销售额、今日订单数、今日新增用户数
• 近 7 日/30 日销售趋势折线图
• 商品分类销售占比饼图
• 销量 Top10 商品排行榜
• 优惠券领取与使用情况

对应到后端，就是写几个统计数据接口。比如近 7 日销售趋势的 SQL：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, COUNT(*) AS order_count, SUM(pay_amount) AS sales_amount FROM orders WHERE pay_status = 1 AND create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d') ORDER BY day ASC;

用 MyBatis 在 XML 里写这段，返回List<Map<String, Object>>，Jackson 自动转成 JSON 给前端 ECharts 使用，非常顺畅。

6.2 用 ECharts 渲染后端返回的数据

前端部分，如果你是前后端分离的项目，用 Vue 或者原生 HTML + ECharts 都行。核心就是把后端返回的数据塞进 ECharts 的 option 里。一个折线图的代码可以是这样：

axios.get('/api/admin/dashboard/salesTrend').then(res => { const data = res.data.data; myChart.setOption({ xAxis: { type: 'category', data: data.map(d => d.day) }, yAxis: { type: 'value', name: '销售额(元)' }, series: [{ type: 'line', smooth: true, areaStyle: {}, data: data.map(d => d.salesAmount) }] }); });

如果你用的是 Vue，也建议先把数据格式和接口约定好，再考虑用哪种前端方案。后端只要返回结构稳定的 JSON，前端怎么渲染完全是相对独立的。

6.3 一个小众但加分的数据导出功能

除了图表，运营后台还可以加一个“订单数据导出 Excel”功能。这个功能看着不起眼，但是它是运营日常工作中非常高频的需求。用EasyExcel或者 Hutool 的 Excel 工具类可以很快实现：

public void exportOrders(HttpServletResponse response, OrdersQuery query) { List<OrderExcelVO> list = orderService.queryForExport(query); ExcelWriter writer = ExcelUtil.getWriter(true); writer.write(list, true); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setCharacterEncoding("utf-8"); String fileName = URLEncoder.encode("订单数据", "UTF-8"); response.setHeader("Content-Disposition", "attachment;filename=" + fileName + ".xlsx"); ServletOutputStream out = response.getOutputStream(); writer.flush(out, true); writer.close(); }

在答辩演示时，现场导出一份 Excel 给导师看，这种“真实运营场景”的功能往往比炫酷动效更让导师认可。

7. 答辩一定会被追问的 SpringBoot 底层原理——从项目引申出去的高频问题

毕业设计答辩和面试不一样，导师更关注的是你“自己做的到底明不明白”。但有些基础原理问题几乎是必问的，提前准备就可以流利应答。

7.1 为什么 SpringBoot 能“零配置”启动一个 Web 应用——自动配置原理

导师问这个问题时，他想听到的关键点是：@SpringBootApplication是@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan三个注解的合成注解。其中@EnableAutoConfiguration会配合spring.factories（SpringBoot 3 里叫AutoConfiguration.imports）文件，加载所有候选的自动配置类。这些配置类上通常有@ConditionalOnClass、@ConditionalOnMissingBean等条件注解，只有当引入的依赖具备时，对应的自动配置才会生效。

拿你的项目举例：你引入了spring-boot-starter-web，自动配置类DispatcherServletAutoConfiguration检测到类路径有DispatcherServlet，就会自动帮你装配 SpringMVC 的完整组件，你不用手动配置。 因为条件注解中有“类的存在性”判断，这就解释了为什么spring-boot-starter-*的引入是开启对应功能的前提。

7.2 SpringBoot 处理一次请求的调用链路

这个问题的理想回答，是把一条请求从浏览器到数据库再返回的过程讲清楚：前端请求 → DispatcherServlet 接收 → 根据 URL 找到对应的 HandlerMapping → 执行拦截器 preHandle → 进入 Controller 方法 → 调用 Service 层业务逻辑 → 调用 Mapper 操作数据库 → 返回结果 → HandlerAdapter 处理 → 拦截器 postHandle → 响应 JSON 返回前端。

衍生出来的细节有：Controller 方法上的@RequestBody靠HttpMessageConverter把 JSON 转成 Java 对象；@RestController是@Controller+@ResponseBody的组合，返回的数据自动被 Jackson 序列化为 JSON。把这些链路在自己的项目里对着代码走一遍，回答这个问题很轻松。

7.3 @Transactional 事务在什么情况下会失效

这个问题频率极高，因为绝大多数毕设都会在OrderService里加事务注解，但可能从来没验证过失效场景。列举几个最常见的失效原因：

• 方法被private修饰，事务切面无法代理；
• 同类内部方法调用this.order()，绕过代理对象；
• 被try catch吞掉异常，事务感知不到需要回滚；
• 方法不是通过 Spring 管理的 bean 调用的；
• 数据库存储引擎是 MyISAM（通常现在不会了），不支持事务；
• 传播行为被设置成NOT_SUPPORTED。

找一个你项目中实际的例子，比如“保存订单 + 扣库存 + 减优惠券”这三个操作放在同一个事务里，讲一下如果第二步抛异常，因为@Transactional(rollbackFor = Exception.class)的存在，第一步和第三步会被回滚，数据保持一致，这个回答比干背理论生动得多。

7.4 SpringBoot 项目的启动流程

这个问题可以概括为：运行main方法 → 构建SpringApplication对象 → 调用run方法 → 准备并刷新 Spring 容器（refreshContext）→ 触发自动配置加载 → 创建内置 Tomcat 服务器 → 执行CommandLineRunner/ApplicationRunner→ 完成启动。

对应的代码断点位置你可以自己跑一遍，对SpringApplication.run()逐行断点，能看到它依次初始化了环境变量、事件监听器、Spring 容器等。有过这种调试经历，回答的深度会明显不一样。

8. 开发过程中最容易踩的五个环境与联调坑

最后按照实际开发经验，集中整理出这个项目里其他常见但又容易被忽视的坑。这些踩过一个就能帮你省下几天时间。

8.1 时区问题导致的时间差了 8 小时

数据库显示create_time比当前时间早 8 个小时，几乎人手必踩。解决方法是三层配置同时检查：

1. JDBC URL 加上参数：serverTimezone=Asia/Shanghai
2. SpringBoot 的application.yml配置：spring.jackson.time-zone=GMT+8、spring.datasource.hikari.connection-time如果引用了时间也要注意
3. MySQL 连接初始化 SQL：connectionInitSqls: SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci

8.2 前端传 JSON 但后端接收不到值

最常见的原因是前端没有设置Content-Type: application/json，或者后端对象字段名和 JSON 里的 key 对不上。排查方法是：先在浏览器开发者工具里看 Network 请求头，确认请求体长什么样，再检查后端 DTO 是否每个字段都有对应的getter/setter。如果用 Lombok，检查是否在编译时正确引入了注解处理器。

8.3 MyBatis-Plus 逻辑删除和唯一索引冲突

如果你给商品表设计了逻辑删除（deleted字段），然后商品表里同时有唯一索引（比如商品编码唯一），那么删除一条记录后再次插入相同编码的记录，会因为唯一索引冲突而入不进去。解决思路是唯一索引字段拼接上删除标记，或者创建索引时把deleted字段一并纳入组合索引中。不同项目可能需要不同的取舍，但意识到这个冲突本身就是经验。

8.4 Redis 连接成功后出现的序列化乱码

用 RedisTemplate 存储字符串数据，取出来发现是\xac\xed\x00\x05t\x00...这样的乱码。这是因为默认的JdkSerializationRedisSerializer把对象做了 Java 序列化。解决方法是把 key 和 value 的序列化器都改掉：

@Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(factory); // key 使用 String 序列化 template.setKeySerializer(new StringRedisSerializer()); // value 使用 JSON 序列化 template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); return template; }

8.5 支付宝沙箱支付回调验签不通过

支付回调验签失败的原因，多数是公钥配置不对。支付宝沙箱有两个公钥概念要分清：一个是“支付宝公钥”（用于验证支付宝发来的回调通知），一个是“应用公钥”（你自己生成的公钥，上传到支付宝后台）。很多同学把这两个搞混，把应用公钥拿去验签，自然永远验不过。建议配置时把三样东西单独存好：“应用私钥”“应用公钥”“支付宝公钥”，各用一处，不要混淆。

9. 项目完成后如何从“能用”升级到“优秀”——再给你三个加分方向

到这里，一个 SpringBoot 保健品商城从架构到实现的核心链路已经完整梳理完了。如果你的开发进度比预期快，或者想在答辩前给自己加点分，可以从下面三个方向里选一个做增量开发。

第一个方向是把“健康资讯”升级成“智能推荐”模块。保健品用户最关心的是“我适不适合吃、该什么时候吃”，你可以做一个简单的规则推荐引擎——用户填写年龄、性别、目标（比如补钙、增强免疫力），系统根据商品标签做匹配，推荐相关商品。数据库加一张user_health_profile表，推荐逻辑用标签匹配分数排序即可。这个功能不需要算法基础，但带来的业务完整感和个性化体验非常加分。

第二个方向是把“订单统计”对接进一个定时任务，每天凌晨生成前一天的销售日报。SpringBoot 自带的@Scheduled就能实现：

@Scheduled(cron = "0 0 1 * * ?") public void generateDailyReport() { // 统计昨日订单、销售额、热销商品 // 生成一条日报记录 }

虽然定时任务本身不复杂，但放到“运营平台”的场景里非常自然，而且能向导师展示你理解“运营需要看日常监控数据”这一需求。

第三个方向是给前端做一个 H5 移动端适配版本。现在电商用户绝大多数来自移动端，你不需要单独开发 App，只要让前端页面用响应式框架，或者做一个简化版的 H5 下单流程。答辩时现场掏出手机扫码打开页面下单，这个演示效果应该会相当不错。

我个人在实际带毕设项目的时候，一直给学生强调一句话：一个好的毕设项目，不是在功能列表上堆了多少项，而是把一条核心业务链路从头到尾走通、走稳、走得有说服力。保健品商城这个题目天然具备“商城 + 医疗健康 + 营销”的三重属性，只要按着从业务拆解到技术实现的路径走下来，它既有业务故事可以讲，也有技术深度可以挖，最终呈现出来的作品不会是一堆代码的毫无生气的堆叠，而是一个让人觉得“这个学生是真的想做懂一个系统”的完整项目。