每年跨到这个节点总有一批计算机专业的同学跑来问我同一个问题毕设到底选什么题目我的回答里基于SpringBoot的JavaWeb商城项目始终占一个位置。不是因为它多新鲜反而恰恰因为它常见。以品牌手机商城为主线的在线销售与订单管理平台几乎把JavaWeb开发的核心环节全串起来了用户登录鉴权、商品SPU/SKU建模、购物车、下单支付、订单状态流转、后台商品与订单管理……整个流程做下来就是一个完整业务闭环答辩展示效果还直观。这篇文章就围绕这个项目展开从需求拆解、技术选型、核心业务实现、实际开发中踩过的坑、答辩追问准备这几个维度写适合想用SpringBoot做毕业设计、又不想只停留在增删改查层面的同学参考。1. 品牌手机商城到底做什么需求边界与模块拆解1.1 为什么偏偏是品牌手机这个品类先回答一个看似无关的问题为什么是手机商城而不是通用商城手机这个品类有一些特殊属性恰好能把你的毕设结构撑得更专业。手机有明确的品牌、型号、颜色、存储容量、运行内存等维度。这意味着你需要做SPU和SKU两层结构而不是简单的一张商品表打天下。这是一个非常容易被答辩老师注意到的点也是真实电商系统的核心建模思路。手机属于高客单价商品订单流程中的状态变化和库存约束比普通商品更值得展开。一本书缺货了你顶多晚两天到但一台手机超卖会导致投诉和售后问题业务约束直接决定了技术方案。手机迭代快天然带新品上架按品牌筛选按价格区间搜索这些场景功能扩展顺手。说白了选手机品类不是因为它有什么奇怪的业务逻辑而是因为它能让你的表结构、功能模块、答辩叙述都更饱满。用通用商城写出来的毕设往往是一个Product表加一个Order表做完跟没做过似的而手机商城至少能引出SPU/SKU、多规格库存、品牌分类这些真实电商场景。1.2 功能清单不是越多越好毕设的功能设计有一个原则功能要完整但边界要清晰。你的系统要能讲一个完整的业务故事而不是罗列一堆用不到的功能。前台模块用户注册/登录手机号或邮箱 密码JWT无状态token。商品浏览首页轮播、品牌专区、分类导航、商品列表分页 按品牌/价格/上架时间筛选。商品详情SKU选择颜色/存储版本、库存显示、商品图片、参数规格。购物车加入、修改数量、删除、结算。订单流程确认订单页、地址管理、提交订单、模拟支付、取消订单、订单跟踪待支付/待发货/待收货/已完成。个人中心订单列表、订单详情、历史足迹。后台模块管理员登录独立权限角色不走用户表。商品管理品牌管理、分类管理、商品上架/下架、SKU库存维护。订单管理订单列表、发货操作、查看订单详情、订单状态变更。用户管理用户列表、账号状态控制。数据统计首页简单统计商品数、订单数、销售额不用图表给个数即可。大部分毕设做到这个程度已经绰绰有余。不要加秒杀、抢购、积分商城这类花架子功能你会在答辩时被细节问题追着打。举个例子你做了秒杀老师很自然会问你怎么控制秒杀接口的并发流量这个问题要从令牌桶、消息队列、限流组件一路聊下去聊不深就是给自己挖坑。1.3 数据库设计表与表之间的关系才是核心我把核心表结构列一下你可以直接当参考表名说明关键字段brand品牌表id, name, logo, sort_ordercategory分类表id, parent_id, name, levelproduct商品表SPUid, category_id, brand_id, name, main_image, description, statussku库存单位SKUid, product_id, specs(颜色/版本), price, stock, imageuser用户表id, username, password, phone, avatar, statuscart购物车表id, user_id, sku_id, quantityorders订单主表id, order_no, user_id, total_amount, status, address_snapshot, create_time, pay_timeorder_item订单明细表id, order_id, sku_id, product_name, sku_specs, price, quantityaddress收货地址表id, user_id, receiver, phone, province, city, detail, is_default几个设计要点address_snapshot这个字段很多人忽略。下单时把用户地址快照保存到订单里避免用户后续改了地址导致订单显示混乱。这在答辩时是一个加分项。order_item冗余了product_name和sku_specs。下单后商品改名或SKU删除订单历史记录依然可读。记住一句话下单那一刻的商品信息是快照不是引用。订单金额永远不要实时算订单主表的total_amount就是下单时的最终金额。如果用户下单后价格变了订单不能跟着变。这个历史一致性的概念很多工作了两年的人都未必想得清楚你能说出来就是亮点。2. 技术选型的底层逻辑为什么选SpringBoot这组搭配2.1 SpringBoot版本怎么选别盲目追新先说版本。SpringBoot 3.x是当前主流但有一个前提JDK必须是17及以上。如果学校机房电脑还是JDK 8或者你对Java 17的新语法不熟老老实实用SpringBoot 2.7.x JDK 8完全够用。组合方案使用场景风险点SpringBoot 3.x JDK 17本机开发环境较新部分教程/插件还未完全适配SpringBoot 2.7.x JDK 8学校机房、老环境生态成熟几乎没坑我的建议很直接对毕设来说稳定性大于新鲜感。无论选哪个版本核心思想是一样的SpringBoot的自动装配把以前SSM项目里大量的XML配置消灭了你用几个注解就能把Web层、数据层、事务管理全部串起来。这也是论文里为什么选SpringBoot的最好论据——开发效率高、配置简化、生态成熟、社区样例多。2.2 数据层用MyBatis-Plus省力但别丢掉SQL能力数据层我推荐MyBatis-Plus理由很实际单表CRUD几乎不用写SQLBaseMapper直接帮你搞定。分页插件好用IPage Page配好MybatisPlusInterceptor后查询就是一行。LambdaQueryWrapper写条件查询非常直观。比如按品牌和价格区间筛选商品不用手动拼接SQL字符串代码可读性好很多。但你要注意一点MyBatis-Plus不是让你完全不写SQL。订单报表、多表关联查询、库存扣减这类逻辑手写SQL更清晰可靠。比如库存扣减UPDATE sku SET stock stock - #{num} WHERE sku_id #{skuId} AND stock #{num}这条SQL里的stock #{num}条件就是防超卖的关键后面我会专门展开。补充一句为什么不用JPASpring Data JPA的领域建模思想确实好但学习曲线陡而且复杂查询时自动生成的SQL未必符合预期。对毕设来说MyBatis-Plus是最稳的选择因为你能精确控制每条SQL出了问题也容易排查。2.3 前端用VueElement UI前后端分离是答辩加分项有些同学的毕设还在用JSPServlet或者Thymeleaf模板渲染。我不反对但我更推荐前后端分离。原因有三个答辩时你可以讲跨域、JWT无状态认证、前端路由这些是当前JavaWeb实际开发的主流模式。部署不复杂Vue打包后是个dist目录扔进Nginx或者SpringBoot的static目录都能跑。界面好看Element UI自带成套组件比手写原生页面工整得多。具体组合Vue 2 Element UI适合前端基础一般的同学社区资料最多报错一搜就有解Vue 3 Element Plus适合愿意花时间适应Composition API的同学。前端页面不需要多登录注册页、首页、商品列表页、商品详情页、购物车页、订单确认页、个人中心、后台管理页加起来十来个页面足够。2.4 Redis的定位别为了用而用Redis在毕设里很容易被滥用。我的看法是加Redis的前提是你真的用到了它的特性。这个商城项目里Redis值得用的场景有三个验证码存储key设置过期时间自动失效非常自然。购物车缓存如果购物车表结构简单可以直接用Redis Hash存userId - skuId - quantity省掉一张表。但如果你对Redis数据类型不熟悉用数据库表更稳。热点商品缓存商品列表做缓存减少数据库压力加分项不是必需项。不要做的事情把用户Session塞进Redis然后说分布式会话。你的系统只有一台服务器、一个Session那这个设计就是自嗨答辩老师一问分布式场景从哪来你接不住。3. 订单与库存联动商城最核心的业务闭环设计3.1 下单流程九步业务必须在一个事务里前端点击提交订单后后端要完成的动作按顺序是校验用户登录态JWT解析。从请求中拿到SKU列表和数量。校验SKU是否存在、是否上架。校验库存是否充足。计算订单总金额。生成订单主表和订单明细表。扣减库存。清空对应购物车记录。返回订单ID和订单号。注意第5步那句话不要相信前端传的价格。有些毕设做商城直接把前端传来的totalAmount写入数据库这是一个经典的逻辑漏洞。答辩老师只要问一句那我如果拦截请求把价格改成1分钱你的系统怎么处理——如果你用后端重新计算价格这个问题就能轻松回答。这九步必须在同一个事务里。任何一个步骤失败前面的操作都要回滚尤其是库存扣减和订单生成不能出现订单生成了但库存没扣或库存扣了但订单没了的中间状态。实现方式就是在Service方法上加Transactional默认遇到RuntimeException就回滚。3.2 订单状态机比你想的更有讲头订单状态建议用整数常量或者枚举管理状态流转要严格单向状态值状态名可以流转到0待支付1已支付/ 5已取消1已支付待发货2已发货2已发货3已完成3已完成-5已取消-设计要点已支付的订单不能直接取消要取消必须走退款逻辑毕设可以简化为取消后直接原路退回。订单状态更新要用条件更新UPDATE orders SET status #{newStatus} WHERE order_no #{orderNo} AND status #{currentStatus}。这个条件防止并发情况下两个请求把同一个订单状态跳变两次。订单号和支付可以做模拟用户点击立即支付后直接切到支付成功页面记录pay_time。状态机的好处是答辩时可以讲我的订单模块不是简单的字段赋值而是有明确的状态流转约束非法跳转会直接被拒绝。这句话比订单能改状态高级很多。3.3 防超卖库存扣减的三种方案对比超卖问题oversell是商城类毕设必问的技术点。场景很简单库存只有1件来了两个用户同时下单系统技术上怎么保证不卖超方案一select查库存再update扣减最差的方案Integer stock skuMapper.selectStock(skuId); if (stock - num 0) { skuMapper.updateStock(skuId, num); // 生成订单... }这个方案在并发场景下会出事两个请求都查到stock1都判断库存够都去扣减。第一个扣完了第二个又把-1写回去库存变成0但订单生成了两个。原因就是判断和扣减不是原子的。方案二SQL层面原子扣减推荐也是我实际用的方案UPDATE sku SET stock stock - #{num} WHERE sku_id #{skuId} AND stock #{num}这条SQL把判断库存是否充足和扣减库存合并成一个原子操作。数据库的UPDATE语句自带行锁执行时MySQL会对这一行加锁第二个事务的UPDATE要等第一个提交完才执行。通过受影响行数判断如果返回值是1说明库存够且扣减成功返回值是0说明库存不足或SKU不存在直接抛出业务异常。方案三乐观锁version字段UPDATE sku SET stock stock - #{num}, version version 1 WHERE sku_id #{skuId} AND version #{version}乐观锁依赖上层重试在并发超卖场景下也可以但实现复杂度高一点需要捕获更新失败后重新查询再重试。毕设选方案二就足够了——SQL原子性保证了正确性而且能一句话讲清楚原理。Redis预扣库存方案这里我不推荐因为要处理Redis和数据库的一致性以及支付超时后释放预扣库存的定时任务。这是高级系统才需要的东西硬塞进毕设只会给自己挖坑。4. 开发实测中最容易踩的四个坑与完整排查链路这一部分是我真正想重点写的。下面每一个坑都是我实际带毕设时见过的真实问题不是从文档里抄来的理论。4.1 坑一Long类型ID前端精度丢失现象数据库主键是Long雪花ID或自增ID后端接口返回JSON给前端前端拿到ID后变成了一个近似值比如1888888888888888888变成了1888888888888888800。列表页和详情页跳转时ID对不上点击任何商品都跳到错误页面。排查过程先是怀疑前端路由传参问题调试后发现前端拿到的ID本身已经不对。再去后端接口看返回值数据库里和接口响应都是对的。最后用浏览器控制台一打印发现问题在JSON序列化这一步。根因JavaScript的Number类型能安全表示的最大整数是2^53-19007199254740991超过这个精度的整数会被JS自动转成近似表示。而雪花ID通常是19位数字远大于2^53。这本质上是跨语言类型精度问题不影响后端但前端一拿到就丢了精度。解决方案让后端把Long类型的ID序列化成字符串。JsonSerialize(using ToStringSerializer.class) private Long id;或者在配置类里统一处理。这个方案简单但实际价值极大——就算你现在自增ID不到2^53一旦你切换雪花ID策略这个问题必现。答辩时老师甚至会主动问你的ID传到前端为什么用String接收这就是一个天然的技术亮点。4.2 坑二LazyInitializationException查询越深越容易踩现象商品列表查询OK商品详情页查询OK但当你把商品和品牌信息通过级联查询一起展示时突然报错LazyInitializationException: could not initialize proxy - no Session。排查过程当时一度以为是Hibernate的问题后来才意识到是MyBatis-Plus的关联查询在Service层返回Entity之后连接已经关闭但前端序列化时还在尝试加载懒加载属性导致找不到Session。根因ORM的懒加载机制需要会话Session保持打开状态。Service方法结束后事务关闭持久化上下文销毁此时再访问未加载的关联对象就会异常。解决方案不要在Entity上做太多跨表关联。最简单的做法是直接在Mapper里用SQL把要展示的数据查出来封装到DTOVO里Select(SELECT p.id, p.name, p.main_image, p.price, b.name AS brand_name FROM product p LEFT JOIN brand b ON p.brand_id b.id WHERE p.category_id #{categoryId} ORDER BY p.id DESC) ListProductVO selectProductVOByCategory(Param(categoryId) Long categoryId);另一个思路是Service层用Transactional包住整个调用链。但我个人更倾向DTO方案显示的字段就是你要查的字段干脆利落也顺便解决数据一致性问题。4.3 坑三事务注解失效的两种典型场景现象下单功能在测试环境一直好好的突然一次并发测试时发现脏数据订单生成了但库存没扣减。排查过程翻代码下单Service方法确实标了Transactional。然后从头排查发现这个下单方法是在同一个类内部被另一个方法调用的Service public class OrderServiceImpl { // 对外入口 public Long submitOrder(SubmitOrderDTO dto) { return this.createOrder(dto); // 自调用 } Transactional public Long createOrder(SubmitOrderDTO dto) { // 生成订单、扣库存... } }问题就在这里。Spring的Transactional基于AOP代理实现。当你调用this.createOrder()时实际上调的是原始对象的方法没有经过代理对象事务注解就不会生效。根因Spring AOP的代理机制只拦截外部对代理对象的调用。同类内部调用不走代理事务切面完全不干预。解决方案把createOrder方法拆到另一个Service类或者把下单逻辑对外暴露的方法本身标记为Transactional不要在类内部绕一层。还有一个更隐蔽的事务失效场景方法内把异常catch住了再吞掉。比如Transactional public void submit() { try { doSomething(); } catch (Exception e) { log.error(发生异常, e); // 没抛出去事务不知道出错了不会回滚 } }规则是Spring默认只在RuntimeException和Error抛出时回滚。你一旦在方法内部把异常吃了事务不会感知已执行的SQL全部提交脏数据就落库了。要么让异常抛出去要么在catch块里手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。4.4 坑四商品图片上传后404现象后台正常上传商品图片返回了保存路径但前端商品列表图片显示不出来报404。排查过程看上传接口返回的路径比如/files/20240516/xxx.jpg前端访问http://localhost:8080/files/20240516/xxx.jpg确实404。再去target目录看一下发现图片保存到了项目运行目录之外而且SpringBoot默认只映射classpath:/static/目录。根因SpringBoot打包后是JAR运行图片不应该写进JAR内部这个目录不可写也不该写。你需要一个外部可写的目录来存文件然后把URL映射配置好。解决方案配置一个本地磁盘目录存文件通过WebMvcConfigurer映射虚拟路径Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) /upload/; registry.addResourceHandler(/files/**) .addResourceLocations(file: uploadPath); } }这样/files/**就映射到了项目运行目录下的upload文件夹。生产环境同理把uploadPath换成服务器上的绝对路径即可。5. 答辩追问突击老师最可能问的四个技术与话术5.1 为什么选SpringBoot的标准话术答辩老师基本必问。不要回答因为简单这种话。一个能打的标准说法传统的SSM项目需要大量的XML配置每个Mapper、Service、Controller都要手动注册配置繁琐且容易出错。SpringBoot通过自动配置和约定大于配置把常用组件的装配逻辑内置了。我引入一个starter依赖框架就能自动完成Bean装配和参数绑定。这样我开发时的精力可以集中到业务逻辑而不是配置文件。另外SpringBoot内置Tomcat打包成可执行的JAR就能直接部署运维成本也低。最后补一句基于SpringBoot的JavaWeb开发也是目前企业里Java后端最主流的模式。5.2 库存不够怎么办必须答到原子操作上标准回答在下单事务里我用条件更新扣减库存UPDATE sku SET stock stock - #{num} WHERE sku_id #{skuId} AND stock #{num}。这行SQL在数据库层面保证判断和扣减是原子的。如果返回的受影响行数是0我就抛业务异常提示库存不足整个事务回滚订单不会生成库存也不会被扣减。这条SQL在并发情况下依靠数据库行锁保证正确性。这里要注意一定不要回答我先查库存够了我再扣这种方案那正好撞在枪口上。5.3 JWT和Session有什么区别这个几乎是JavaWeb必问。简短回答Session是服务端状态用户登录后服务端保存Session数据通过Cookie里的JSESSIONID关联Session默认存在单台服务器内存里。JWT是无状态认证服务端签发一个包含用户信息的token不保存会话状态客户端每次带着token请求服务端验证签名即可。适合前后端分离和水平扩展场景不需要考虑Session共享问题。如果能再补一句JWT的缺点是token一旦签发到期前无法主动失效所以我在设计时把过期时间设得比较短并支持刷新token那就更圆满了。5.4 项目最大亮点是什么三句话讲出设计深度不要回答我用了Redis缓存这种大路货。一个更好的角度是第一订单状态机有明确的流转约束不允许非法跳转待收货的订单不能被直接改成已完成之外的状态。第二库存扣减采用条件update实现原子操作从数据库层面杜绝超卖。第三订单金额和商品信息在生成订单时做了快照不随后续商品价格变动而变动保证订单数据的历史一致性。这三句话讲出来老师会觉得你的系统设计有真实业务考量而不是教科书复刻。6. 从开发到部署一台服务器跑通上线的完整路径最后说说部署因为很多答辩老师会问一句你部署了吗。就算没有真实服务器能把流程讲清楚也是加分项。6.1 打包与启动一套可复用的部署命令第一步统一项目环境。IDEA里配置好MavenJDK版本和SpringBoot要求一致。application.yml里区分开发环境和生产环境spring: profiles: active: prodapplication-prod.yml里配置MySQL地址、Redis地址如果用了、上传文件路径。第二步打包。Maven面板里执行clean package生成可执行JAR。注意pom.xml里确保打包插件是SpringBoot自带的build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build第三步数据库初始化。把SQL脚本导出成init.sql服务器上先建库再导入。第四步上传JAR到服务器启动nohup java -jar brand-mall.jar --spring.profiles.activeprod mall.log 21 查看日志tail -f mall.log看到Started xxxApplication就说明启动成功。6.2 前后端分离项目的上线形态如果是前后端分离前端dist目录交给Nginx托管配置一个反向代理指向后端8080端口。不熟悉Nginx也没关系直接把dist目录放进SpringBoot的static目录打包成一个JAR也能跑通——这种方法适用于所有想省事的前后端分离项目。上线前最好做一遍自检我列个清单数据库连接信息确认无误Redis连接正常如果用了。上传目录存在且有写权限。首页、列表页、详情页、购物车、下单支付、后台发货这条主链路完整走通。登录过期后前端是否自动跳转到登录页。服务器时间是否正确订单支付时间依赖系统时间。我在实际带毕设的项目里发现很多同学做完系统后演示时最担心的不是功能有问题而是某个页面因为小配置不对直接白屏。所以上线前走一遍主链路是最值的投资比临时改代码有效得多。这个项目做到能演示、能讲原理、能答追问就已经达到优秀毕设的标准了。代码本来就该是次要的能做出来、能说清楚为什么这样做比堆功能有用得多。如果真的准备走Java后端方向把订单状态机、防超卖、事务失效这几个问题吃透面试时也能直接当项目经验讲。