每年毕业季总能看到一帮人在选题上反复横跳，Java方向的尤其多。今天想聊的这个项目——“基于Web的商品预购平台”，是我个人非常推荐的一个毕设方向。它没有复杂的推荐算法，也没有海量数据处理的压力，但它把Web开发的主干技术全都串起来了：Java基础、Servlet和SpringMVC的请求流转、MyBatis和MySQL的数据交互、前端的页面渲染，甚至还有并发扣库存这种真实电商场景下才碰得到的经典问题。无论你是想拿它当毕业设计交付，还是想通过一个完整项目把JavaWeb的知识体系重过一遍，这个题目都能让你在“做出来”和“讲清楚”两个层面都站得住脚。
先给还没定方向的同学一个准话：这个题目处在“难度适中”和“含金量不低”的交集上。复杂程度不如秒杀系统那种大并发全链路，但绝对比普通的增删改查课设要更有故事可讲。而且商品预购在生活中俯拾皆是，从手机新品首发到双十一预售，评委一眼就能看懂你做的是什么，不用费力气解释业务背景。下面我会从技术选型、功能拆解、数据库设计、核心代码实现一直聊到调试排错和答辩准备，尽量把我在实际带项目中踩过的坑和总结出的经验一次说完。
1. 项目定位与技术选型
1.1 预购业务到底在解决什么问题
商品预购（预售）在电商里是个非常经典的业务模式。以手机行业为例，新品发售前平台先开放预售，用户支付定金锁定购买资格，商家拿到预售数据后再安排生产和备货。这么做的好处很清楚：商家能提前感知需求量，降低库存积压风险；用户能确保自己在首发时买到，不用熬夜抢购。放在毕设场景里，这个业务逻辑就简化为“用户浏览商品→发起预购→提交预购单→模拟支付定金→生成正式订单”这么一条核心链路。
这个题目的优势在于，它不是一个纯展示型的CRUD系统。预购天然自带两个技术难点：预购数量的库存控制，以及预购活动的时间窗口管理。这两个点正好是答辩时最能展示你思考深度的素材。新人容易忽略这一点，觉得设计几个表、写几个页面就完事了，等到答辩被问“并发情况下库存会不会超卖”时才开始冒冷汗。所以我在做这个项目时，从一开始就把这两个难点纳入设计，而不是把它们当成后期加分项。
1.2 技术栈三种方案的横向对比
JavaWeb方向的技术选型，市面上基本是三个路线：JSP+Servlet、SSM（Spring + SpringMVC + MyBatis）、Spring Boot + MyBatis Plus。我分别说下它们的适用场景。
| 方案 | 优点 | 缺点 | 适合情况 |
|---|---|---|---|
| JSP + Servlet | 底层原理清晰，答辩好解释 | 代码冗余，配置繁琐 | JavaWeb课程设计、想练基本功 |
| SSM | 分层思想标准，资料极多 | 配置文件较多，需要手动整合 | 绝大多数学校毕设首选 |
| Spring Boot + MP | 开发效率高，约定大于配置 | 原理容易说不清，答辩有风险 | 私活、就业项目、技术基础好的同学 |
我给大多数人的建议是：如果学校允许自由选择，优先选SSM。理由很简单，Spring + SpringMVC + MyBatis是Java后端岗位面试的核心内容，你把这个项目的框架整合过程吃透了，后续找工作面试聊到IOC、AOP、DispatcherServlet这些都有的说。而且毕设论文写起来也方便，框架整合、配置文件解读都能写成好几个小节。
如果是你已经熟练掌握了Spring Boot，那就别委屈自己用老写法。Spring Boot + MyBatis Plus会让你省下大量配置时间，把精力集中在业务代码上。唯一要注意的是，答辩前一定要把自动配置和Starter的原理背熟，别被老师一句“Spring Boot为什么能自动装配”问住。
1.3 开发环境与工具准备
工具版本这块，我建议直接照抄下面这个组合，全是经过验证的稳定搭配：
- JDK 1.8：虽然JDK 17都出来很久了，但毕设用1.8依然是兼容性最好的选择，Tomcat、IDE、老项目的坑最少。
- IDEA 2024及以上：社区版也够用，如果需要用到Spring的XML配置提示，建议用Ultimate版，学校一般都有正版授权。
- Tomcat 8.5/9：对应Servlet 3.1/4.0规范，SSM项目随便跑。
- MySQL 5.7/8.0：8.0要注意驱动包用
com.mysql.cj.jdbc.Driver，5.7用com.mysql.jdbc.Driver。这个细节在4.1节排错时会专门说。 - Maven 3.6以上：用阿里云镜像加速，别用默认中央仓库，不然下载依赖能让你怀疑人生。
- Navicat或SQLyog：可视化建库导数据都方便。
在正式动手之前，强烈建议把Maven和阿里云镜像先配好，并且用一个空的Maven工程跑通“依赖下载→打包→部署”的全流程。很多人第一步没准备好，后面写代码五分钟、调依赖两小时，心态直接崩掉。
2. 需求拆解与数据库设计
2.1 前端用户侧功能模块
商品预购平台从用户视角看，应该有这几个核心功能：
- 注册与登录：用户名密码注册、登录。密码不能明文存，至少用MD5加盐或BCrypt做哈希。很多人的课设直接存明文，这属于答辩时会被直接点名的低级问题。
- 商品浏览与搜索：首页展示预购商品列表，支持按分类筛选和简单的关键词搜索。列表页每张卡片要展示商品主图、名称、预购价、定金和预购状态（进行中/已结束）。
- 商品详情页：商品信息、预购倒计时、预购库存余量、预购规则说明，以及“立即预购”按钮。
- 预购下单：选择预购数量，确认信息后提交预购单。这里需要做两层校验：前端先校验数量合法性，后端二次校验库存和登录状态。
- 个人中心：查看我的预购记录、订单记录，支持对未支付定金的预购单取消操作。
这里我多说一句，功能不在多，而在闭环。所谓闭环就是用户能完成“注册→登录→浏览→预购→支付定金→查看订单→取消订单”这样一个完整的行为路径。很多同学喜欢堆功能，什么论坛、留言板、积分商城都往里加，结果每个功能都是半成品，代码一团糟。不如把主链路做扎实，让评委顺着你的演示路径走一遍就明白了。
2.2 后台管理侧功能模块
后台是给管理员用的，核心是管理商品和预购活动：
- 管理员登录：独立的管理员账号体系，简单点就一张admin表，复杂点可以加拦截器和权限判断。
- 分类管理：商品分类的增删改查。
- 商品管理：上架商品、编辑商品信息、下架商品。商品字段包括标题、描述、封面图、原价、预购价、预购库存、定金等。
- 预购活动管理：设置预购开始时间和结束时间，控制预购状态。这块和商品状态要分开，因为同一件商品可以有多轮预购活动。
- 订单管理：查看用户预购单和订单，执行发货操作或者取消异常订单。
后台功能不需要做得太花哨，重点是让评委看到你有“前后端分离”的角色意识：用户的普通操作走前台，管理操作走后台，两个入口用拦截器做权限隔离。这一条在论文里可以用“系统采用JSP作为视图层，后台管理页面与前台页面共用一套Controller但按角色鉴权”来表述，非常加分。
2.3 核心数据表结构与字段说明
数据库是整个项目的地基，表设计得合理，后面写代码会舒服很多。我用的核心表一共有5张：用户表、分类表、商品表、预购活动表、预购订单表。有精力的话可以再加一张轮播图表或者支付记录表，但核心就这5张，先设计清楚。
用户表（user）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键，自增 |
| username | varchar(50) | 用户名，唯一 |
| password | varchar(100) | 密码（哈希后存储） |
| phone | varchar(20) | 手机号 |
| create_time | datetime | 注册时间 |
分类表（category）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| name | varchar(50) | 分类名 |
| sort | int | 排序权重 |
商品表（product）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| category_id | int | 关联分类表 |
| name | varchar(100) | 商品名称 |
| description | text | 商品描述 |
| cover_img | varchar(255) | 封面图路径 |
| original_price | decimal(10,2) | 原价 |
| pre_price | decimal(10,2) | 预购价 |
| deposit | decimal(10,2) | 定金 |
| status | int | 0=下架 1=上架 |
| create_time | datetime | 上架时间 |
预购活动表（pre_sale）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| product_id | int | 关联商品表 |
| pre_stock | int | 预购总库存 |
| remain_stock | int | 剩余库存 |
| start_time | datetime | 预购开始时间 |
| end_time | datetime | 预购结束时间 |
| status | int | 0=未开始 1=进行中 2=已结束 |
预购订单表（pre_order）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 主键 |
| order_no | varchar(32) | 订单号（唯一，避免用自增id暴露订单量） |
| user_id | int | 关联用户表 |
| pre_sale_id | int | 关联预购活动表 |
| quantity | int | 预购数量 |
| total_deposit | decimal(10,2) | 定金总额 |
| status | int | 0=待付定金 1=已付定金 2=已取消 3=已发货 |
| create_time | datetime | 下单时间 |
2.4 表关系与设计中的几个关键点
表关系这块其实不复杂：分类和商品是一对多，商品和预购活动是一对多，用户和预购订单是一对多，预购活动和预购订单是一对多。注意我这里把“商品”和“预购活动”分开设计了，这是很多新人容易搞混的地方。有的同学直接把预购时间、预购库存字段塞进商品表里，一旦同一件商品要做两轮预购，设计就崩了。
几个关键设计点我单独拎出来说：
- 不要用外键。用逻辑关联（查询时通过id字段JOIN或二次查询）来代替物理外键，这样插入删除更灵活，也避免在Navicat里建外键时因为数据不一致而报错。
- 金额一律用decimal。float和double在金额计算上会有精度误差，这在答辩时是一个很常见的追问点。
decimal(10,2)能满足绝大多数场景。 - 状态字段用int枚举。比如订单状态0、1、2、3，配合注释或常量类解释含义。用字符串存状态虽然可读性好一点，但索引效率差，写起来也啰嗦。
- 订单号一定要唯一。用时间戳加随机数即可，比如
SimpleDateFormat("yyyyMMddHHmmss")加几位随机数字。别直接用自增id当订单号，会让用户轻易估算出平台订单量，这是个很业余的暴露。
3. 实操过程与核心环节实现
3.1 用IDEA快速搭建项目骨架
我以经典的SSM架构为例，讲一下从零搭建的过程。第一步是在IDEA里创建一个空的Maven项目，选好JDK版本，GroupId填com.example，ArtifactId填pre-sale-platform就行。建完之后的目录结构应该是标准的Maven风格：
src/main/java // Java源码 src/main/resources // 配置文件（spring、mybatis、日志） src/main/webapp // JSP页面、静态资源、web.xml接着处理pom.xml。SSM项目至少要引入这些依赖：Spring核心、SpringMVC、MyBatis、MyBatis-Spring整合包、MySQL驱动、Jackson（用于JSON序列化）、JSTL（JSP页面里用c:forEach这些标签必须的）、文件上传组件。版本号建议用Spring 5.2.x、MyBatis 3.5.x、MySQL驱动8.0.x，这些都是能互相兼容的组合。引入依赖后记得让Maven刷新，看到依赖列表没有红色报错再继续。
然后是配置文件。SSM最劝退新人的地方就是配置多，你要准备好四个文件：web.xml（配置DispatcherServlet和编码过滤器）、spring-mvc.xml（扫描Controller、开启注解驱动、配置视图解析器）、spring-mybatis.xml（配置数据源、SqlSessionFactory、Mapper扫描）、jdbc.properties（数据库连接信息）。其中spring-mybatis.xml是重点，数据源用DruidDataSource或BasicDataSource都行，但我建议用Druid，因为它的连接池监控能力在答辩演示时很有说服力。
3.2 预购下单的完整链路
预购下单是系统的核心功能，整条链路从页面点击开始，大致如下：
用户点击"立即预购" → 前端JS校验登录状态和数量 → ajax/post提交到Controller → Service层校验商品状态、预购活动时间、库存余量 → Mapper插入预购订单 → 同时扣减预购剩余库存 → 返回结果给前端 → 前端跳转到订单详情页Controller层的接口设计可以这样写：
@Controller @RequestMapping("/preorder") public class PreOrderController { @Resource private PreOrderService preOrderService; @PostMapping("/create") @ResponseBody public Result create(@RequestParam Integer preSaleId, @RequestParam Integer quantity, HttpSession session) { User user = (User) session.getAttribute("loginUser"); if (user == null) { return Result.fail("请先登录"); } return preOrderService.createPreOrder(user.getId(), preSaleId, quantity); } }Service层是业务校验的重灾区，我列一下至少要检查的几个点：
- 预购活动是否存在：
preSale == null直接报错。 - 预购活动是否在进行中：
now.before(startTime) || now.after(endTime)都拒绝下单。 - 预购数量是否合理：大于0且不能超过单笔上限（比如每人限购2件）。
- 剩余库存是否充足：这是防超卖的第一道闸门。
- 同一用户是否已经对该活动下过单：限购一次的设计。
这里有个经验想分享：状态判断千万别只依赖前端传来的状态字段，一定要在Service层重新从数据库查一遍。因为页面可能缓存、用户可能恶意绕过前端直接调接口，后端校验才是唯一可信的。
3.3 并发扣减库存的超卖问题与解决
预购平台最核心的亮点功能就是这个超卖控制。先解释下超卖发生的场景：假设预购库存剩1件，两个用户同时提交预购。如果代码逻辑是先查库存（select），发现有余量，再执行插入和扣减（update），在并发情况下两个请求都可能读到“库存还有1件”的旧值，然后都进去下单，最后商品卖出了2件但库存已经为0，这就是超卖。
解决方案分几个层次：
-- 最经典的条件更新，直接一步完成扣减 UPDATE pre_sale SET remain_stock = remain_stock - #{quantity} WHERE id = #{preSaleId} AND remain_stock >= #{quantity}核心思路是把“判断库存充足”和“扣减库存”合并成一条SQL，依靠数据库的行锁保证原子性。WHERE里的remain_stock >= #{quantity}就是乐观锁思想，如果库存不足，这条SQL影响行数为0，程序就能据此判断预购失败回滚事务。这招在普通毕设级别完全够用，而且面试时讲到“乐观锁控制并发”绝对是个加分项。
还有更进阶的手段，比如Redis预扣库存、消息队列削峰，但这属于秒杀系统级别的设计，放到毕设里反而显得大材小用。如果你论文里想秀一下，可以在“系统展望”里提一句：后续可引入Redis缓存预购库存，通过Lua脚本实现原子扣减，但在当前项目阶段，基于数据库条件更新的方案已经能覆盖业务需求。
3.4 预购倒计时与后端时间校验
预购能不能下单，本质是个时间问题：开始前不能下单，结束后也不能下单。前端的倒计时是给用户看的体验优化，真正的判断标准必须落在后端时间上。
前端倒计时可以用JS实现。页面加载时从后端接口取到endTime，然后setInterval每秒计算剩余时间，将时间戳差格式化为“天-小时-分钟-秒”显示。注意一定要用服务端时间而不是本地时间，因为用户可以直接改电脑系统时间让倒计时加速结束。
后端怎么配合？最简单的方法是在Service里每次下单前执行：
Date now = new Date(); if (now.before(preSale.getStartTime()) || now.after(preSale.getEndTime())) { throw new BusinessException("预购活动未在进行中"); }这块还要注意数据库时间字段的时区问题。如果MySQL连接URL没有配置serverTimezone=Asia/Shanghai，插入和读取的时间可能跟你本地的相差8小时，表现在页面上就是倒计时提前或者延后。这个坑我在4.4节会专门再说。
3.5 调试运行的完整步骤
项目写完之后，调试运行是很多人最容易卡住的一环。我建议按下面这个顺序来，能省掉大量无效排查时间：
- 先保证数据库能连上。在Navicat中测试连接，确认用户名密码没问题，确认库名和
jdbc.properties里的配置一致。 - 导入SQL建表脚本。运行建表和初始化数据脚本，确保预购活动和商品有几条真实数据可用于测试。
- 启动Tomcat。IDEA里配置Tomcat Server，Deployment中添加
war exploded包，Application context填/或/pre-sale都行。启动后看控制台日志有没有“Started”或者部署成功信息。 - 先跑通登录注册。这是最基础的链路，如果注册能写库、登录能跳转，说明SpringMVC和MyBatis的整体链路没问题。
- 再测试商品列表和详情。这一步能验证查询语句和页面数据渲染是否正常。
- 最后测预购下单。重点看库存扣减和订单生成是否正确。建议同时开两个浏览器登录两个账号，模拟并发提交预购，验证超卖是否被挡住。
调试是个熟练活，别怕报错。碰到问题先看控制台最后几行异常栈，顺着Caused by一层层往底层翻，绝大多数Bug都能在异常信息里找到线索。实在解决不了再搜索报错原文，不要凭记忆瞎改代码。
4. 常见报错与排查技巧实录
4.1 数据库连接失败的三种典型场景
数据库连接问题在毕设调试中出现的概率最高，报错形态却多种多样。
第一种是Access denied for user 'root'@'localhost'。原因很简单：用户名或者密码不对。排查时先到Navicat里测一下连接，确认无误再看jdbc.properties，注意检查是不是有多余的空格，password字段是不是被中文引号括住了。我见过好几个同学的报错居然是因为复制配置时把中文分号带了进去。
第二种是Unknown database 'xxx'。这个八成是库名写错了，要么是数据库根本没创建，要么是jdbc.url里的库名和实际不一致。去Navicat确认一下库的真实名称就好。
第三种是Communications link failure或者Connection refused。这种比较隐蔽，常见原因有两个：一是MySQL服务没启动，Windows下到服务管理器里确认MySQL服务是运行状态；二是连接URL里的serverTimezone没配，导致建连时报时区相关的通信异常。8.0驱动对时区特别敏感，URL里最好带上?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai。
4.2 404和500的处理思路
404和500是Web项目最常见的两个状态码，处理思路完全不同。404表示资源不存在，问题出在URL路径或者路由映射上。先确认浏览器的访问路径和Controller上的@RequestMapping是否一致，再看web.xml里DispatcherServlet的url-pattern是不是把JSP请求也拦截了。新手最常遇到的情况是配置了/作为url-pattern，导致SpringMVC把/index.jsp也当成Controller路径去匹配，匹配不到就404。
500表示服务器内部出错，问题在代码或者运行时环境。看到500先去IDEA控制台找异常栈，最常见的几类是：空指针（查到了null对象没做判断）、SQL语法错误（MyBatis的XML或注解SQL写错）、Mapper绑定失败（Mapper接口和XML的namespace或id对不上）。这些异常信息都写得比较明确，照着改就能解决。
补充一个小技巧：在spring-mvc.xml里配置一个全局异常处理器，把异常信息返回成一个自定义的JSON结果，前端就能弹出具体的错误原因。这个在处理预购下单这类业务逻辑时很有用，不然用户只看到一个白屏500，根本没法判断是哪里出了问题。
4.3 端口占用与Tomcat启动失败
Tomcat启动时最经典报错是Port 8080 was already in use。这种情况基本都是上一次的Tomcat没有正常关闭，或者有其他程序占了8080端口。解决方式两种：一是找到占用进程并结束它，命令行执行netstat -ano | findstr 8080拿到PID后在任务管理器里结束进程；二是直接换端口，在IDEA的Tomcat配置里把HTTP port改成8081，简单粗暴但有效。
还有一个容易忽略的问题：Tomcat启动抛java.lang.ClassNotFoundException。这个通常是因为依赖包没部署到WEB-INF/lib。用IDEA部署war包时，右键项目选择“Open Module Settings”，在Artifacts里把lib目录加入Output Layout就能解决。如果用的是Maven，也可以直接执行mvn clean package生成war包，部署到Tomcat的webapps目录下运行。
4.4 中文乱码的根治方案
中文乱码几乎是所有JavaWeb毕设必踩的坑，而且往往是三个层面叠加出的问题。第一层是页面乱码，JSP文件头部需要设置<%@ page language="java" contentType="text/html; charset=UTF-8" %>，同时确保文件的真正编码也是UTF-8，可以在IDEA的右下角确认编码格式。第二层是请求乱码，POST请求中文参数乱码的问题最容易出，在web.xml里配置Spring的CharacterEncodingFilter，设置encoding为UTF-8，并且forceEncoding为true。第三层是数据库乱码，连接URL里必须带characterEncoding=UTF-8，建表时字段的字符集也必须是utf8或utf8mb4。
这三层有一层没配好，就会看到问号或者乱码。排查时建议先看是哪个环节出了错：先看数据库存进去的值是不是乱码，如果是，说明是数据库连接或者表字段的问题；如果库里是好的但页面显示乱码，那就是查询后到JSP渲染这一路的编码问题。
4.5 毕设调试中的其他高频坑
除了上面三类，还有几个高频问题值得单独提一下。MyBatis的SQL语句里如果有<这种特殊字符，在XML文件里会被解析成标签开始符号，导致报错。解决方法是把<写成<，或者用<![CDATA[ ... ]]>把SQL包起来。
另一个是Jackson对象转JSON时出现循环引用问题，比如User对象里关联了List，List里又关联回User，序列化时就可能抛Infinite recursion。解决办法是在关联字段上加@JsonIgnore注解，只保留单向序列化，后台管理页面如果需要用户信息，直接用单独的VO类接收就好。
最后提醒一个IDEA层面的问题：Tomcat部署的Artifact类型一定要选war exploded，不要选war，否则每次修改代码都要重新打包，调试效率极低。war exploded是解压目录方式，IDEA会自动把改过的字节码同步到部署目录，配合热部署功能体验会好很多。
5. 论文写作与答辩准备的实用建议
5.1 论文结构安排与亮点提炼
论文是毕设的另一半工作，写得好能把你的代码调用放大不少。常见的结构是六章：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试。难点往往在第2章和第4章。第2章讲技术，别只写“Spring是什么、MyBatis是什么”这种百科内容，要结合项目讲，比如“Spring的IOC容器用于管理Service层和Mapper层的Bean依赖”，“MyBatis通过Mapper接口与XML文件绑定实现SQL与Java代码的解耦”。第4章讲系统设计，一定要画好用例图、架构图、E-R图和数据库表结构图。不用多精美，但逻辑要对得上。
亮点提炼上，我建议围绕三个方向写：一是预购业务的时间状态机设计（未开始/进行中/已结束），二是并发场景下基于数据库条件更新的防超卖设计，三是前后台角色分离的权限控制。这三个方向都来自真实的业务需求，而不是为了凑字数的理想空谈，评委看到这种从实际设计出发的内容，一般都会很认可。
5.2 答辩高频问题回答参考
答辩环节老师一般会从“你这个项目做了什么”和“关键技术你懂不懂”两个角度问问题。我整理了一份高频问题列表，不保证你全部遇到，但遇到的基本都能从容应对：
“系统用到了什么架构？MVC是如何体现的？”
回答思路：系统基于SSM三层架构，MVC是设计模式的思想。SpringMVC中DispatcherServlet作为Controller入口接收请求，Service层负责业务逻辑，JSP作为View渲染数据，Model数据通过ModelAndView传递。重点是说明请求从view到controller再回到view的完整流向。
“预购和普通购物有什么区别？”
回答思路：普通购物是现买现结，库存实时扣减；预购是先付定金锁定购买资格，尾款在约定时间再支付。预购平台需要管理预购活动的时间窗口和预购库存，并且要处理定金支付和尾款支付两个阶段。
“并发情况下如何防止超卖？”
回答思路：不能用“先查再扣”的方式，因为并发时会读到一致旧值。项目采用条件更新SQL，在一条update语句中同时完成“库存充足判断”和“库存扣减”，数据库行锁保证一致性。如果影响行数为0，说明库存不足，回滚事务并返回失败。
“密码是怎么加密存储的？”
回答思路：项目中采用MD5加盐方式，或者BCrypt。面试时讲BCrypt更专业，因为是自适应哈希，抗彩虹表攻击。毕设如果用了BCrypt，记得说清楚盐值和管理方式；如果用了MD5加盐，也要说明固定盐和随机盐的区别。
“数据库有多少张表，表与表之间是什么关系？”
回答思路：核心表5张——用户表、分类表、商品表、预购活动表、预购订单表。分类和商品一对多，商品和预购活动一对多，用户和预购订单一对多，预购活动和预购订单一对多。如果加了轮播图表、公告表，也一并说清楚。
“如果预购人数超过库存，如何处理？”
回答思路：在用户提交预购时，先走条件更新扣减库存，库存不足则直接返回“已被抢完”；如果限购，还需判断该用户是否已经下单，通过订单表中user_id和pre_sale_id的唯一索引来保证一人一单。
能把这几个问题回答清楚，答辩就算稳了一大半。回答的时候不要背稿，用自己的话讲，配合具体的代码位置和页面效果来说，会让老师觉得你是真的写进去了。
最后再分享一个我自己的体会：做完这个项目之后，最大的收获反而不是那些代码，而是养成了一个习惯——每次听到JavaWeb相关的面试题，都会下意识去想“这事在我预购平台里是怎么实现的”。比如面试问Bean的生命周期，我就想到Spring容器里Service的创建和销毁过程；问MySQL索引，我就想user表的username字段为什么需要唯一索引。有了一个亲手做出来的项目做支点，很多抽象的技术概念就落地了。如果你也想通过一个项目把JavaWeb体系串起来，商品预购平台这个题目，值得认真对待。祝一次通关。
