SpringBoot+Vue盲盒商城系统：从抽取算法到并发库存的完整实战-育师

作为一个带过不少毕业设计、也自己动手写过完整项目的过来人，我接了不计其数的商城系统课题，但像"盲盒管理系统"这种带着强娱乐属性和业务特色的题目，反而比普通的图书管理、考勤管理更有意思。这篇博文不讲空话，直接拿我实际开发的一套基于SpringBoot与Vue的潮玩盲盒电商平台出来拆解，从选题逻辑、技术选型、数据库设计、抽取算法、前后端联调到部署答辩，一条线讲清楚。想找毕业设计参考、或者想自己做个能摆上台面的商城类项目的朋友，这篇文章可以直接当操作手册用。

1. 毕业设计选题：为什么盲盒电商比普通商城更值得做

1.1 盲盒业务的独特闭环

当初选这个题，表面上是"商城系统的又一种变体"，实际上盲盒电商和传统商城在业务逻辑上有本质区别。普通商城是用户选什么买什么，SKU明确、库存明确、价格明确，核心逻辑就是加购物车、下单、支付、发货。但盲盒电商的核心是不确定性——用户花钱买的是一个"机会"，他可能抽到隐藏款，也可能抽到普通款。

这个不确定性带出了几个普通商城完全没有的子系统：

抽取规则引擎：概率怎么配、保底怎么算、库存怎么扣
开盒记录体系：用户每一次开盒都要有据可查，这是信任基础
隐藏款和稀有款的库存控制：隐藏款永远不会直接展示在商品列表里，只能通过开盒获得
用户心理预期管理：前端开盒动画、结果展示、重复款处理（回收、合成、赠送）等

所以盲盒系统虽然看起来和商城差不多，但它的精彩程度和一个普通增删改查题目完全不在一个量级。我身边很多同学毕设做的"XX管理系统"，核心功能就四个字：增删改查。答辩时老师问"你这个系统解决了什么实际问题"，一句话都答不上来。而盲盒电商平台天然有业务故事：抽盒有概率、有惊喜感、有隐藏款稀缺性，这些点任何一个拿出来都能讲三分钟。

1.2 系统功能边界的确定

毕业设计最忌讳的就是"什么都想做"，所以我第一期把功能边界卡得很死，只做核心闭环：

用户端：注册登录、浏览盲盒系列、查看详情、下单抽取、开盒动画、查看我的盲盒与重复款
管理端：盲盒系列管理、盲盒单品管理、库存管理、订单管理、抽取概率配置、用户管理
公共模块：轮播图管理、系统通知、个人资料

这套范围覆盖了一个完整电商交易闭环的前后端全部环节，既不会大到做不完，也不会小到没东西可写。我建议做类似题目的同学也这样划分：先列"必须做的"，再列"有空再做的"。比如秒杀、优惠券、社区分享、盲盒置换这些放到二期，不要把开题报告写成SaaS平台规划书。

1.3 目标用户与使用场景

盲盒系统的目标用户很清晰：潮玩爱好者、学生群体、盲盒收集者。使用场景更偏向移动端，但Web端作为管理后台和浏览入口同样重要。我在设计时特别注意了两个细节：

一是浏览体验。盲盒系列封面图必须大、必须好看，因为用户决定买一个盲盒很大程度上是"看着爽"就下单了，商品图质量直接影响转化率。前端首页我用了大图轮播加系列卡片墙，而不是干巴巴的商品表格。

二是开盒仪式感。线上盲盒没有线下拆盒的物理快感，就必须靠交互弥补。用户点"立即抽取"后，前端先播放盒子弹跳旋转动画，再显示"正在开启..."的过渡状态，最后才揭示结果。动画时长控制在2秒左右，过长用户会烦，过短没有期待感。这个交互细节我在答辩时专门演示了，老师普遍反应"这个比普通商城有意思"。

2. 技术选型背后的真实考量：SpringBoot 3.x与Vue 3的搭配逻辑

2.1 后端选SpringBoot：生态成熟度是最大优势

后端我选了SpringBoot 3.x，JDK用的17。很多人写毕设还在用SpringBoot 2.x + JDK 8，我理解原因是学校教材和网上老教程多，但SpringBoot 3已经稳定了很长时间，毕业设计用新版本反而能体现你关注技术演进。不过要提醒一句：SpringBoot 3对JDK版本有硬性要求，必须JDK 17及以上，如果你电脑上还是JDK 8，就得一起升级，这算是个小门槛。

选择SpringBoot的核心原因有三点：

生态成熟：JPA、MyBatis-Plus、Spring Security、Redis、MinIO都有现成starter，遇到问题搜得到解决方案，对毕设党极度友好
开发效率高：约定大于配置，一个注解搞定路由、参数校验、事务管理，不需要像SSM那样写一堆XML
写论文方便：SpringBoot的架构图好画、技术名词好写，"自动配置""起步依赖""微服务友好"这些话术在论文里很好发挥

持久层我用的MyBatis-Plus而不是原生MyBatis。理由很实在：MyBatis-Plus的BaseMapper内置了单表CRUD，毕业设计里80%数据操作都是单表查询，不用写XML就能直接调selectById、insert、updateById，省下来的时间全拿去写业务逻辑了。多表关联用@TableField加VO手写SQL，或者直接复用MP的Wrapper构造条件，完全够用。

2.2 前端选Vue 3：组件化与响应式是核心诱因

前端用Vue 3 + Vite + Element Plus + Pinia + Vue Router。

Vue 3的Composition API我一开始觉得不习惯，但写多了确实比Options API舒服。逻辑可以按功能聚合而不是按data、methods、computed分散，比如一个"抽取盲盒"相关的所有状态和函数集中在一个setup函数里，改起来不用上下跳。

配套技术栈的选型理由：

Vite：启动速度快到离谱，热更新几乎秒级，相比Webpack那套折磨人的配置，Vite开箱即用。注意Vite要求Node.js 16+，装之前先检查版本
Element Plus：后台管理页面的表格、表单、弹窗、分页组件全是现成的，样式也不算丑，适合毕设这种对UI要求"看得过去就行"的场景
Pinia：比Vuex轻，API更友好，存用户登录态、购物车状态、抽取动画状态都方便。其实我项目里全局状态并不多，主要就是userStore和cartStore
Vue Router：路由这块踩坑最多的是"刷新404"问题，后面单独讲

2.3 整体架构：前后端分离加统一响应

项目采用经典的前后端分离架构，前端跑在5173端口（Vite默认），后端跑在8080端口。前端的API请求通过Axios发到后端。

后端包结构我按controller、service、mapper、entity、vo、config分层。这个结构不是我想出来的，是几乎所有Java毕设项目的通用模板，好处是导师看着眼熟、答辩时好讲、代码组织也清晰。真实项目里可能按业务模块分包更合理，但毕设求稳，按技术分层就够了。

所有接口返回统一的Result<T>结构：

public class Result<T> { private Integer code; // 200成功 400业务异常 401未登录 500系统异常 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(400); result.setMessage(message); return result; } }

这个统一返回结构前端Axios拦截器直接判断code字段，等于200就走业务逻辑，不等于200就弹出message。省去了每个接口各自定义返回格式的重复劳动，也让前端错误处理非常统一。

3. 数据库设计：盲盒业务的核心表结构拆解

3.1 商品与盲盒系列：一对多的关系建模

盲盒系统的商品模型比普通商品多了一层"系列"概念。一个系列就是一整套盲盒，比如"太空宇航员系列"一共有6个常规款加1个隐藏款。每个款式是一个独立的商品SKU，但它们同属一个系列。

我设计了四张核心表：

box_series：盲盒系列表，字段包括系列名、封面图、描述、状态（上架/下架）
box_item：盲盒单品表，字段包括所属系列ID、款式名、款式图片、款式类型（普通款/隐藏款）、库存、抽取概率
box_series_rule：系列抽取规则表，记录每个系列的总抽取次数、开启时间等（这个表后来我懒得用，概率直接放在box_item里了，表设计时思路清晰点更省事）
box_item_sku：单品SKU表，保存具体款式的编码、价格、图片、库存

建表核心SQL示例如下（精简版）：

CREATE TABLE `box_series` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `series_name` varchar(100) NOT NULL COMMENT '系列名称', `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图URL', `description` text COMMENT '系列描述', `status` tinyint 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='盲盒系列表'; CREATE TABLE `box_item` ( `id` bigint NOT NULL AUTO_INCREMENT, `series_id` bigint NOT NULL COMMENT '所属系列ID', `item_name` varchar(100) NOT NULL COMMENT '款式名称', `item_image` varchar(255) DEFAULT NULL COMMENT '款式图片', `item_type` tinyint DEFAULT '0' COMMENT '款式类型 0普通款 1隐藏款', `stock` int DEFAULT '0' COMMENT '库存数量', `probability` decimal(5,2) DEFAULT '0.00' COMMENT '抽取概率(%)', `price` decimal(10,2) DEFAULT '0.00' COMMENT '单个盲盒售价', PRIMARY KEY (`id`), KEY `idx_series_id` (`series_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='盲盒单品表';

注意两个细节：一是所有表都用utf8mb4字符集，因为Emoji和特殊符号在utf8mb3里会报错，盲盒系统的款名经常带"✦限量""🤖"这类字符，不用utf8mb4迟早出事。二是series_id要建索引，因为"查某个系列下所有款式"这个操作太频繁了，不建索引数据量一大就会慢。

3.2 订单与抽取记录：交易和开盒解耦

用户下单抽取盲盒，这个动作涉及两张核心表：订单表和抽取记录表。

区别在于订单表管钱、管物流，抽取记录表管"开出了什么"。我最初想把它们合成一张表，后来发现逻辑会乱：一个订单可能对应多次抽取（比如一次性买5个盲盒），每次抽取结果单独记录；但支付和退款以订单为单位。所以最终设计成：

box_order：订单表，存订单编号、用户ID、系列ID、金额、状态（待支付/已支付/已取消/已完成）、支付时间、创建时间
box_draw_record：抽取记录表，存订单ID、用户ID、系列ID、抽取出的box_item_id、开盒时间、是否隐藏款

下单的核心流程是：

用户点"立即抽取"创建订单，状态为待支付
用户支付成功后，调用抽取算法随机确定款式，扣减相应库存，生成抽取记录
前端轮询或接口返回抽取结果，播放开盒动画

这里有一个值得在答辩时提的设计决策："先支付、后抽盒"。为什么不先抽盒再支付？因为你一旦先告诉用户抽到了什么，用户可能反悔不付款，等于免费让他看到了结果。先支付再抽取保证了平台的利益，也保证了抽取的公平性——结果必须在支付之后才能揭晓。

CREATE TABLE `box_order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` bigint NOT NULL, `series_id` bigint NOT NULL, `total_amount` decimal(10,2) NOT NULL COMMENT '支付金额', `status` tinyint DEFAULT '0' COMMENT '状态 0待支付 1已支付 2已取消 3已完成', `pay_time` datetime DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表'; CREATE TABLE `box_draw_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_id` bigint NOT NULL, `user_id` bigint NOT NULL, `series_id` bigint NOT NULL, `item_id` bigint NOT NULL COMMENT '抽中的单品ID', `is_hidden` tinyint DEFAULT '0' COMMENT '是否隐藏款 0否 1是', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='抽取记录表';

订单编号我用的是yyyyMMddHHmmss + 用户ID后四位 + 随机四位数字，确保并发下不重复。顺便在order_no上加了唯一索引，双保险。这个编号规则简单、好看、答辩能说清楚，比用雪花算法更适合毕设场景。

3.3 用户、库存与并发控制的设计权衡

用户表我用Spring Security的UserDetails自定义扩展，字段包括用户名、密码（BCrypt加密）、昵称、头像、手机号、角色（USER/ADMIN）。角色控制直接靠@PreAuthorize("hasRole('ADMIN')")注解，省去自己写拦截器。

库存表我一开始做了单独的box_inventory表，后来发现这就一个stock字段的事，直接放在box_item表里更合理。库存扣减的并发问题，我用的是乐观锁：

UPDATE box_item SET stock = stock - 1 WHERE id = ? AND stock > 0

这条SQL是关键。它利用了数据库行锁和stock > 0条件，在高并发下也能保证不会超卖，同时不需要引入Redis分布式锁这种重型方案。真实场景里如果一个用户秒杀了100个盒子，那用stock > 0一次扣100个、更新100条抽取记录即可，SQL返回影响行数为0就说明库存不够。

我还加了数据库层面的唯一约束防止同一用户重复下单：(user_id, series_id, status)的逻辑我没用唯一索引，因为用户确实可能对同一系列买很多次，所以这部分靠后端逻辑控制——下单前查询待支付订单，若有就直接拦截。这个方案防君子不防小人，但毕设场景够用了。

4. 盲盒抽取的核心逻辑：概率算法、库存扣减与公平性

4.1 概率算法选择：加权随机还是精确概率

盲盒抽取是系统的灵魂，算法我前后写了两版。

第一版是加权随机。把每个款式的概率当作权重，比如系列里有6个普通款（概率各13%）和1个隐藏款（概率22%），那总共100%。实现方式是生成一个0到1之间的随机数，按概率区间逐一判断落在哪个区间。代码长这样：

public BoxItem drawByWeight(List<BoxItem> items) { // 计算总权重 double totalWeight = items.stream().mapToDouble(BoxItem::getProbability).sum(); // 生成随机数 double random = ThreadLocalRandom.current().nextDouble() * totalWeight; double cumulative = 0; for (BoxItem item : items) { cumulative += item.getProbability(); if (random <= cumulative) { return item; } } return items.get(items.size() - 1); }

这个方案简单直白，概率配置灵活，但有一个小问题：浮点数累加的精度误差。比如某个款式概率是13%，在二进制浮点数里不能精确表示，多次累加后误差累积可能把概率区间推偏。另一个问题是如果某个款式概率配置为0，它永远不会被抽中，但如果所有配置的概率加起来不等于100%，totalWeight就变了，等价于归一化，某些产品的概率会被扭曲。

所以我后来换了第二版：直接用百分比整数区间。在box_item里存概率字段时，用整数存储（如隐藏款存储为22，含义是22%），前端展示时自动拼%。抽取时生成1~100的整数随机数，按每个款式的整数概率分配区间。这样计算精确、逻辑直观，也方便管理员在后台看到"概率总和是否为100%"。我在管理端配置概率的界面加了合计校验，如果所有款式概率之和不是100，会导致部分款式概率被静默压低。

抽取逻辑的完整代码：

// 核心：按整数概率决定抽中哪个款式 public BoxItem drawByPercent(Long seriesId) { List<BoxItem> items = boxItemMapper.selectList( new LambdaQueryWrapper<BoxItem>() .eq(BoxItem::getSeriesId, seriesId)); // 校验总概率接近100 int total = items.stream().mapToInt(BoxItem::getProbabilityInt).sum(); if (Math.abs(total - 100) > 0) { throw new BusinessException("该系列概率配置不正确，请管理员检查"); } int rand = ThreadLocalRandom.current().nextInt(1, 101); // 1~100 int cumulative = 0; for (BoxItem item : items) { cumulative += item.getProbabilityInt(); if (rand <= cumulative) { // 扣减库存 int updated = boxItemMapper.reduceStock(item.getId()); if (updated == 0) { throw new BusinessException("该款式库存不足，请稍后再试"); } return item; } } throw new BusinessException("抽取失败，请重试"); }

注意reduceStock就是前面说的原子扣减语句。把扣库存和选中款式的逻辑放在同一次随机抽取内，能避免"抽中了但没库存"的尴尬情况。

4.2 保底机制：伪随机中的可控变量

纯靠概率配置，可能出现极端情况：隐藏款概率1%，但脸黑用户连开300个都抽不到。这在真实盲盒业务里会让用户骂娘，也会让平台失去复购率。所以我在抽取逻辑里加了一个保底计数器。

实现方式不复杂：box_draw_record表记录用户最近100次抽取，每抽一次就检查该系列下用户连续没抽中隐藏款的次数，如果连续次数达到阈值（比如50次），下次抽取强制命中隐藏款。这个称为"软保底"。

具体实现：

// 查询该用户在该系列下的最近N次抽取记录 int consecutiveMiss = drawRecordMapper.countConsecutiveMiss(userId, seriesId); if (consecutiveMiss >= 50) { // 强制抽取隐藏款 BoxItem hidden = items.stream() .filter(item -> item.getItemType() == 1) .findFirst() .orElseThrow(() -> new BusinessException("该系列隐藏款未配置")); boxItemMapper.reduceStock(hidden.getId()); return hidden; }

这个机制在论文里可以写进"系统特色"章节，在答辩时也是一个加分项——它证明你不只是机械地实现功能，还思考了业务上的合理性。真实业务中"保底50次"是个运营配置，我把它放在管理端的系统设置里，管理员可以动态调整，不需要改代码。

4.3 隐藏款的隐藏逻辑

还有一个细节容易被忽略：隐藏款在商品列表和管理端都不能"亮出来"。普通商城所有SKU都在商品列表展示，但盲盒的隐藏款如果直接挂出来，神秘感就没了。我的做法是：

系列详情页只展示普通款的图片和名称，隐藏款显示为一个带问号的灰色占位卡："???神秘款"
管理端可以配置隐藏款，但系列的对外接口返回数据时，隐藏款items单独放一个字段，前端只展示占位图
只有用户抽到隐藏款之后，前端才加载真实图片

实现上就是接口返回BoxItemVO时做字段过滤：

// 对外返回时隐藏隐藏款信息 public BoxSeriesVO convertToVO(BoxSeries series) { BoxSeriesVO vo = new BoxSeriesVO(); vo.setId(series.getId()); vo.setSeriesName(series.getSeriesName()); vo.setCoverImage(series.getCoverImage()); vo.setDescription(series.getDescription()); List<BoxItemVO> visibleItems = new ArrayList<>(); for (BoxItem item : series.getItems()) { BoxItemVO itemVO = new BoxItemVO(); itemVO.setId(item.getId()); itemVO.setItemName(item.getItemType() == 1 ? "神秘隐藏款" : item.getItemName()); itemVO.setItemImage(item.getItemType() == 1 ? "https://your-cdn/default-mystery.png" : item.getItemImage()); itemVO.setItemType(item.getItemType()); visibleItems.add(itemVO); } vo.setItems(visibleItems); return vo; }

这个细节在答辩时绝对是个亮点，它体现的不是"会不会写代码"，而是"懂不懂业务"。

5. Vue前端的关键实现：从系列卡片到开盒动画

5.1 路由配置与权限控制

前端路由我分成两部分：用户端和管理端。用户端路由包括首页、系列详情、订单中心、个人中心；管理端路由包括系列管理、单品管理、订单管理、用户管理、概率配置。管理端路由统一挂在/admin前缀下，并加路由守卫：

// vue-router 4 守卫 router.beforeEach((to, from, next) => { const userStore = useUserStore(); if (to.meta.requiresAuth && !userStore.isLoggedIn) { next({ path: '/login', query: { redirect: to.fullPath } }); return; } if (to.meta.requiresAdmin && userStore.role !== 'ADMIN') { next({ path: '/', message: '无权访问' }); return; } next(); });

路由懒加载建议加上，用() => import('@/views/Home.vue')的形式，可以避免打包后首屏加载一个巨大的JS文件。我的项目在本地开发不觉得慢，但打包后放服务器上，首屏加载时间从5秒降到1.8秒。

5.2 开盒交互：用Vue动画制造仪式感

前端最有技术含量的页面就是开盒页。我的实现方案如下：

盒子旋转进入(0.6s) -> 盒子震动(0.4s) -> 金色光芒闪烁(0.8s) -> 结果显示卡片翻转(0.5s)

这段动画用CSS动画加Vue的<transition>组件实现，核心代码：

<template> <div class="draw-container"> <transition name="shake"> <div v-if="boxVisible" class="box-card" @click="startDraw"> <img src="box-cover.png" /> </div> </transition> <transition name="flip"> <div v-if="resultVisible" class="result-card"> <img :src="resultItem.itemImage" /> <div class="item-name">{{ resultItem.itemName }}</div> <div v-if="resultItem.itemType === 1" class="rare-tag">稀有隐藏款</div> </div> </transition> </div> </template> <script setup> const startDraw = async () => { boxVisible.value = true; // 调用后端抽取接口 const { data } = await drawApi.createDraw(orderId); // 延迟展示结果，模拟开盒过程 setTimeout(() => { resultItem.value = data; boxVisible.value = false; resultVisible.value = true; }, 1800); }; </script> <style> .shake-enter-active { animation: shake 0.4s infinite; } @keyframes shake { 0%, 100% { transform: rotate(0deg); } 25% { transform: rotate(-3deg); } 75% { transform: rotate(3deg); } } </style>

开盒动画这块我用了一个关键技巧：抽取接口在动画开始前调用。也就是用户点击按钮的瞬间就发出请求，等后端返回结果时动画刚好进行到揭示环节。这样用户感受到的是"动画播完结果自然出现"，不会有等待的空白期。

5.3 前端与后端对接的常见坑

跨域配置：开发环境下前端5173请求后端8080，必然触发跨域。我在后端加了CORS配置类，addCorsMappings允许http://localhost:5173访问。
请求超时设置：Axios默认超时是0（不超时），但开盒过程中如果后端处理慢，用户会一直看着动画。我把超时设成10秒，超过就提示"网络繁忙请重试"。
结果状态刷新：用户支付成功后跳转开盒页，如果直接刷新页面，抽取结果可能丢失。我的做法是box_draw_record里有orderId字段，页面加载时根据orderId查询已有的抽取记录，如果有就直接展示，没有才调用抽取接口。

Element Plus的表格分页组件el-table搭配后端分页接口非常顺手，管理端所有列表页都是同一套逻辑：前端传pageNum和pageSize，后端返回PageResult，前端表格绑data，分页组件绑total，翻页时重新请求。这个套路写成通用函数能省一半代码量。

6. 项目开发中的踩坑记录与解决思路

6.1 跨域CORS配置：前端的"预检请求"问题

第一次前后端联调，我信心满满地启动前端，然后浏览器直接报跨域错误。我当时的后端配置类写得很随意，只处理了GET和POST请求，没处理OPTIONS预检请求。

浏览器在发起带自定义Headers（比如Authorization、Content-Type: application/json）的请求前，会先发一个OPTIONS请求探路，后端必须对OPTIONS也做出正确响应，否则前端请求直接失败。

正确配置方式：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("http://localhost:*", "http://127.0.0.1:*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

allowedOriginPatterns比allowedOrigins更灵活，支持通配符。maxAge(3600)让浏览器缓存预检结果1小时，减少无谓的OPTIONS请求。这个配置完成后跨域问题再没出现过。

6.2 定时清理超时未支付订单

下单后如果用户一直不支付，订单表里会堆一堆status=0的脏数据。我加了SpringBoot的定时任务，每5分钟清理一次超时订单：

@Component public class OrderTimeoutTask { @Scheduled(cron = "0 */5 * * * ?") public void cleanExpiredOrders() { // 找出创建超过30分钟且未支付的订单 LocalDateTime deadline = LocalDateTime.now().minusMinutes(30); List<BoxOrder> expiredOrders = orderMapper.selectList( new LambdaQueryWrapper<BoxOrder>() .eq(BoxOrder::getStatus, 0) .lt(BoxOrder::getCreateTime, deadline)); for (BoxOrder order : expiredOrders) { // 恢复库存？不需要，因为库存只在支付成功后扣减 order.setStatus(2); // 已取消 orderMapper.updateById(order); } } }

这里我特别说明一个设计决策：库存扣减发生在支付成功之后，而不是下单时。所以超时订单清理不需要恢复库存，逻辑简单很多。如果换成下单即锁库存的模式，取消订单还要把库存加回来，并发情况下容易出问题。两种设计都能用，但我选的这种对毕设场景更友好。

记得在启动类上加@EnableScheduling，不然定时任务不生效。这个坑我踩过，折腾了半天才发现是忘了开开关。

6.3 图片存储的取舍：本地存储还是OSS

盲盒系统的图片很多：封面图、款式图、用户头像。我一开始直接存Base64进数据库，后来发现数据库表体积膨胀极快，查询变慢，于是改成图片上传后存本地磁盘，数据库只存URL。

本地存储方案：

# application.yml file: upload-path: /data/images/ access-path: /images/**

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/images/**") .addResourceLocations("file:" + fileUploadPath); } }

后端用MultipartFile接收上传文件，写入本地目录后返回URL。这个方案零成本，毕设完全够用。如果你有条件，可以用MinIO搭建本地OSS，或者直接用云OSS，但本地存储方案在答辩时胜在"全链路可控"——存储路径、访问映射、文件类型校验都是自己写的，好讲。

上传接口还要注意三点：文件大小限制（SpringBoot默认1MB，要调大）、文件类型校验（防止上传可执行文件）、文件名重命名（防止重名覆盖和中文乱码）。我用UUID拼接原始后缀名解决重名问题。

6.4 打包部署：Vue构建产物放进SpringBoot

很多人的毕设只做到"本地能跑"，但要想答辩效果更好，把项目部署到一台服务器上、给评委一个在线访问的地址，瞬间拉开差距。

Vue项目构建后生成dist目录，里面有index.html和一堆静态资源。两种部署方式：

方式一（推荐）：dist目录丢到Nginx里，配置反向代理把/api转发到后端8080端口。这个方案前端和后端完全分离，符合前后端分离架构的本质
方式二：把dist复制到SpringBoot的src/main/resources/static目录，打包成单个JAR，访问http://ip:8080直接看到页面。这个方案简单，但刷新页面时Vue Router的history模式会404，需要后端加一个兜底路由把非API请求转发到index.html

方式二的兜底路由配置：

@Controller public class PageController { @RequestMapping(value = {"/", "/**"}) public String index() { return "forward:/index.html"; } }

注意这个控制器要放在@RequestMapping("/api/**")的路由不匹配之后才生效，实际配置时可以给后端API统一加/api前缀，避免和页面路由冲突。我最终采用了方式一，因为Nginx处理静态文件性能更好，而且以后想再加一个H5端也方便。

7. 答辩时可以主动展示的细节与项目扩展方向

7.1 三个值得单独演示的亮点

毕业设计答辩时间有限，老师不会看你全部代码。我准备了三个必讲的亮点场景，每个都能引出一段"为什么这样设计"的故事：

第一个是开盒时的概率校验。我在管理端做了一个概率配置页面，管理员可以调整每个款式的抽取概率。我现场演示把普通款概率调低、隐藏款概率调高，再演示用户端开盒，老师能看到概率变化立即生效。这比讲一百句"我的系统支持概率配置"有说服力得多。

第二个是并发下库存不超卖。我提前造了100个库存的系列，后端用Postman并发发20个抽取请求，返回成功数始终不超过库存数。这个可以直接证明你的系统考虑过并发安全性，很多同学的毕设压根没想过这个问题。

第三个是隐藏款不直接展示。我在演示时专门说："大家注意，这个系列的隐藏款在用户端不显示真实信息，只有抽到之后才会揭示。"然后实际抽一次，展示结果从"?"变成真实款式图的过程。这个业务细节很能说明你理解盲盒的玩法。

7.2 可以继续演进的功能方向

如果做完核心功能还学有余力，或者想把它当成一个真正的作品集项目，可以往这几个方向扩展：

重复款处理：用户抽到重复款后可以"合成"成积分或参与"置换"；这个逻辑会带出积分系统和C2C置换市场
连抽机制：支持"一次抽10盒"，价格打折，动画改成10连展示；这个对提升客单价有直接帮助
开盒记录分享图：用户抽到隐藏款后生成一张可分享的海报图，带系列信息和款式图，利用社交裂变拉新
数据分析看板：管理端增加"系列热度排行""款式抽取热度""用户复购分析"，用ECharts画饼图和折线图，论文里还能写上"数据可视化"

这些方向的代码基础都已经在本项目里打好了，加新功能主要是扩展表结构和新增接口，不需要推翻重来。

7.3 经费与时间分配的经验

最后说点实在的。如果你准备复刻这个项目，我建议时间分配如下：

第1周：搭环境、建库建表、把SpringBoot和Vue框架跑通
第2-3周：后端所有CRUD接口 + 权限框架
第4周：前端的列表、详情、管理页面
第5周：开盒动画、订单流程、支付模拟（用开发者工具模拟支付成功回调）
第6周：联调、修bug、优化体验
第7周：部署到服务器 + 准备论文和答辩PPT

搭建环境时最容易卡住的是Maven依赖下载慢，建议配阿里云镜像源。Node依赖安装慢可以配npm config set registry https://registry.npmmirror.com。我见过太多人卡在环境配置上两天没进展，这些小事提前处理好能节省大量时间。

这个项目做下来，我个人最大的体会是：毕业设计不是比谁的技术多新多深，而是比谁更完整地理解了一个业务场景，并且能用合理的技术方案把它落地。盲盒管理系统在技术难度上不算顶尖，但业务逻辑的完整度、交互细节的把控、并发安全性的考虑，都让它比普通"管理系统"高出一个层次。这套SpringBoot加Vue的组合，加上我上面讲的抽取算法和库存扣减方案，足够支撑你写出一篇有内容、答辩不虚的毕设论文。如果你在开发过程中遇到卡壳的地方，优先检查数据库表结构和接口返回数据是否对齐，我遇到过的大部分诡异问题最后都是字段名不一致或者少传了参数引起的，这是最没有技术含量但最常见的坑。

SpringBoot+Vue盲盒商城系统：从抽取算法到并发库存的完整实战