又到毕业设计季了。每次看到群里有人问“Java毕设选什么题”我脑子里第一个冒出来的基本都是这个基于Spring Boot的家电销售展示平台。它足够经典经典到技术栈完全不用担心过时它又足够“小而完整”登录注册、商品展示、购物车、下单支付流程、后台管理一个不少正好把大学四年学的东西串成一条线。今天这篇就结合我自己实际带过、帮人改过的好几套类似项目把这个题目从选题定位、数据库设计、后端编码、前端联调一直拆到论文和答辩完整过一遍。不管你是打算从头自己写还是手头有代码但没吃透逻辑这篇都能帮你少走很多弯路。1. 第一步先搞清楚这个毕设到底要做什么1.1 需求拆解销售展示平台的核心功能边界很多人拿到这个题目第一反应是“做一个像某东一样的商城”然后就开始焦虑——是不是要做秒杀、要做优惠券、要做推荐算法不是的兄弟这是毕业设计不是创业项目。毕设的核心目标是把你学过的东西系统地展示出来让答辩老师看到你具备独立完成一个完整业务系统的能力。所以功能边界一定要收住做到“麻雀虽小五脏俱全”就够了。一套标准的家电销售展示平台用户端核心功能就四块一是商品浏览包括分类筛选、关键词搜索、分页展示、详情查看二是用户中心包括注册、登录、个人信息维护三是购物车加购、改数量、删商品、勾选结算四是订单提交订单、支付模拟、查看订单列表、确认收货。后台管理端两到三块商品管理增删改查和上下架、分类管理、订单管理查看、发货。再往上想可以加个轮播图管理、公告管理这类锦上添花的功能。但分清楚优先级把核心链路做到稳定不出错比堆砌一堆用不上的功能点要重要得多。我见过不少学生一上来就规划了十几个数据表、二十多个页面结果数据库关系理不清代码写了一团浆糊最后连基本的注册登录都有Bug。所以我的建议是前端时间不要急着敲代码先花一个下午把用户从“进入首页”到“下单成功”这条主路径走一遍把每一步涉及到的页面、数据、接口列出来。主链路通了你的毕设就已经完成六成了。1.2 技术选型为什么是Spring Boot这套组合技术选型是整个项目最关键的决策之一。用Spring Boot作为底座几乎是这类毕设的最优解。理由很简单Spring Boot内置了Tomcat、自动配置了一大堆常用组件你不用像以前写SSH框架一样去配一堆XML文件项目跑不起来大概率是配置写错的情况能减少一大半。对毕设这种“必须当场能跑起来演示”的场景来说稳定压倒一切。持久层我建议用MyBatis不要用Spring Data JPA。原因很实际MyBatis的SQL是你自己写的答辩老师问复杂度高的查询怎么实现时你能拿着XML里的SQL讲得头头是道而JPA自动生成的SQL遇到复杂联表查询时容易讲不清楚。当然现在更流行的是MyBatis-Plus自带分页插件和条件构造器写起代码来确实快很多毕设用也不会有问题。我的建议是如果项目是参考网上的教学视频做的那就视频用什么你就用什么别在技术选型上搞创新怎么稳怎么来。前端方案则是另一个需要尽早确定的分叉路口。方向一Thymeleaf模板引擎加Bootstrap或Layui服务端渲染后端写页面工程量小一个人两周就能搞定方向二前后端分离Vue加Element UI加Axios界面好看交互流畅但你要同时处理跨域、Token校验、异步渲染等问题工作量至少增加三成。这个选择题没有标准答案取决于你距离交稿还有多少时间。时间紧就踏踏实实走方案一界面干净整洁一样可以拿高分。2. 把地基打好数据库表设计与接口规划2.1 六张核心表的字段设计与关联关系所有业务系统数据库设计就是地基。网上那些“数据库有59张表”的毕设模板听听就行了实际毕业设计用到的表控制在6到8张最合适。让我给你列一份我反复调整过、觉得最顺手的表结构你直接对着改就行。用户表t_user主键id、用户名username唯一索引、密码password记得加密存储MD5加盐或BCrypt都可以、手机号phone、头像avatar、角色role0代表普通用户1代表管理员、注册时间create_time。字段别贪多够用就行会员等级、积分这类字段统统不要加。分类表t_category主键id、分类名称name、排序字段sort_order。家电的分类一般就是冰箱、洗衣机、空调、电视、厨卫电器这几个两级分类可以做但没必要建议只做一级后台管理时也省事。商品表t_product主键id、分类idcategory_id外键逻辑关联不加物理外键、商品名称name、副标题subtitle、主图main_image、轮播图sub_images用JSON字符串存或用逗号分隔存到一个字段里即可、详情描述detail、价格price用Decimal精确到分、库存stock、销量sales、上下架状态status、创建时间create_time。这里是重点字段类型要注意价格用DECIMAL(10,2)千万别用double或float存银行家算法算出来的浮点误差够你喝一壶的。购物车表t_cart_item主键id、用户iduser_id、商品idproduct_id、数量quantity、选中状态checked。联合唯一索引(user_id, product_id)保证同一个用户对同一个商品只有一条购物车记录后续加购只需要做累加操作。订单表t_order主键id、订单号order_no用时间戳加随机数生成唯一、用户iduser_id、订单总金额total_price、订单状态status0待付款、1已付款待发货、2已发货、3已完成、4已取消、收货人receiver_name、收货电话receiver_phone、收货地址receiver_address、下单时间create_time、支付时间pay_time、发货时间deliver_time。订单表一定要有冗余的收货人信息不能去关联用户表取地址因为收货地址属于订单快照用户之后改了地址不能影响历史订单。订单明细表t_order_item主键id、订单idorder_id、商品idproduct_id、商品名称product_name、商品主图product_image、购买时单价price、购买数量quantity、小计total_price。这里又是有意冗余把商品名称和图片也存进来了理由和订单表冗余收货信息是一样的——商品信息可能变订单记录不能变。这六张表之间的关联关系你在论文画ER图时这样描述用户与购物车是一对多用户与订单是一对多商品与购物车是一对多商品与订单明细是一对多订单与订单明细是一对多。逻辑扁平、清晰答辩时三五句话就能讲透。2.2 接口清单前后端约定先谈清楚表设计好之后下一步不是急着写代码而是把接口清单列出来。我做项目习惯先花半小时把接口文档写明白后面联调会省下大把时间。你甚至不需要用SwaggerExcel表格或者Markdown都行就是把这些信息列清楚接口路径、请求方式、请求参数、返回结构。用户端接口大概有这些POST /api/user/register注册、POST /api/user/login登录、GET /api/user/info获取当前登录用户信息、GET /api/category/list分类列表、GET /api/product/list商品分页列表支持分类、关键词、排序参数、GET /api/product/detail/{id}商品详情、GET /api/cart/list购物车列表、POST /api/cart/add加购、PUT /api/cart/update修改数量与选中状态、DELETE /api/cart/delete/{id}删购物车项、POST /api/order/create提交订单、GET /api/order/list我的订单、PUT /api/order/confirm/{id}确认收货。管理端接口POST /api/admin/product/save新增或更新商品、DELETE /api/admin/product/{id}删除商品、GET /api/admin/order/list订单列表、PUT /api/admin/order/deliver/{id}发货。重点来了所有接口的返回结构必须统一。我的习惯是封装一个Result类用code、message、data三个字段200表示成功500表示业务异常401表示未登录。这样做的好处太明显了前端判断逻辑只需要写一次处理错误也方便。我见过不少项目有的接口返回成功是{success: true}有的返回{code: 0}前端一堆分支判断看着就头大。统一封装狗看了都摇头但就是很多人不做。2.3 分页与搜索数据库层面的两个设计细节分页查询是商品列表最核心的接口几乎所有用户操作都会经过它。用MyBatis-Plus就直接用Page对象加分页插件一行配置搞定。手写MyBatis的话分页SQL主要靠LIMIT offset, pageSize实现同时要用COUNT(*)查总记录数。这里有个细节要注意COUNT(*)不要和列表查询放在同一个复杂SQL里做最好拆成两个方法一个数总数一个查数据SQL各自优化性能更好。虽然毕设数据量不大但这个习惯能体现你懂分页原理。搜索和排序的SQL写法也需要提前想清楚。商品名称模糊搜索用LIKE CONCAT(%, #{keyword}, %)注意不能用% #{keyword} %这种写法在MySQL里会因隐式类型转换产生隐藏问题。排序场景一般两类按价格从低到高、按销量从高到低。要让排序字段可配置SQL里不能用简单的字符串拼接应该用choose标签配合sidx参数做白名单映射或者直接用MyBatis的${}搭配枚举校验。安全性上这里不要觉得毕设就不用管SQL注入的预防措施写出来论文里还能多一小节内容。3. 核心代码攻坚从登录鉴权到订单闭环3.1 工程初始化目录结构与基础配置技术方案定完直接动手搭建工程。我习惯的做法是直接用IDEIDEA社区版免费够用创建Spring Initializr项目依赖勾选Spring Web、MyBatis或MyBatis-Plus、MySQL Driver、Lombok。Java版本别追新用8或11都行稳定为主。Spring Boot版本用2.x系列最后一个稳定版就好3.x对JDK版本和部分依赖有要求没必要给自己挖坑。工程目录结构要分层清晰。我常用的分包方式是controller放接口层、service放业务逻辑先接口后实现类impl包放实现、mapper或dao放数据访问接口、entity或model放实体类、dto放接收参数的类、vo放传给前端的类、config放配置类、common放统一返回结果、异常处理、工具类。网上很多教程把DTO和VO混在一起用实体类直接返回给前端省事儿是省事儿但商品实体里有库存、状态这些不该传给前端的字段列表接口就会把多余数据都暴露出去。规范一点没什么坏处论文里还能写“我采用了DTO模式对各层数据模型进行隔离”。配置文件application.yml里需要提前处理好几件事。数据库连接串设置时区serverTimezoneAsia/Shanghai不然会报时区错误配置spring.jackson.date-format和time-zone否则LocalDateTime在JSON里会变成数组前端没法解析上传文件的路径要配好我是用file.upload-dir自定义配置项指定一个磁盘目录再把静态资源映射/images/**指向它这样上传的商品图片才能通过URL访问到。3.2 登录认证与拦截器用最稳的方案登录认证这块我的建议是毕设用最简单可靠的方式Session配合拦截器HandlerInterceptor。不要上Spring Security不要上Shiro更不要自己造JWT轮子。理由很简单这些框架都有自己的安全模型和配置方式你光是搞明白Security的过滤器链就要花掉两三天而且配置不当容易出现各种莫名其妙的拒绝访问问题。用原生Session实现代码量少、逻辑透明、答辩时老师问起来你能理直气壮地从头讲到尾。具体实现是这样的用户登录成功后把用户信息放进Session比如session.setAttribute(loginUser, user)loginUser可以是一个只包含id、用户名、角色、头像等基础字段的对象。然后写一个拦截器实现HandlerInterceptor接口在preHandle方法里判断当前请求的Session里有没有登录用户。如果没有而且请求的接口是需要登录权限的直接返回401或重定向到登录页如果有放行。这里的关键点是要把“公开接口”和“需登录接口”分清楚。注册登录这类接口不能拦截商品列表和详情这类接口建议不拦截游客也能看商品这是电商的基本体验购物车、订单相关接口必须拦截管理端接口还要额外校验角色是否为管理员。拦截器还有个作用把当前登录用户信息填充到业务代码里。你可以写一个UserContext工具类用ThreadLocal存当前请求的登录用户业务层随时取用。用ThreadLocal要注意请求结束后必须调用remove()清除否则线程池复用线程会串数据。这个细节你要是能在答辩时说出来绝对是个加分项。3.3 商品搜索分页与详情高频接口的实现细节商品列表接口是整个项目被调用最多的接口实现上值得多花点心思。接收参数大概是categoryId分类筛选、keyword关键词搜索、pageNum、pageSize、sort排序规则。Service层的逻辑分三步走第一步组装查询条件用MyBatis-Plus的LambdaQueryWrapper或者手写动态SQL第二步执行分页查询第三步把实体列表转换为VO列表主要工作是裁剪掉库存、状态等不需要的字段再补上一些前端需要的派生字段。为什么要单独做一步转换因为直接用实体类转JSON返回字段太冗余前端用起来麻烦数据传输量也大。一个ProductVO只包含商品id、名称、副标题、主图、价格、销量、分类名称结构清爽接口文档也好看。商品详情接口相对简单根据id查出商品实体、分类名称、以及从subImages字段拆分出来的图片列表。但这里有性能优化的机会。首页热门推荐、分类页这些场景用户需要的是列表数据并不需要detail字段这种几百字的富文本所以列表查询应该明确指定只查列表需要的列而不是SELECT *。虽然毕设数据量下看不出差别但这个习惯体现了你对查询性能有感知。商品列表还有一个容易忽略的问题分类树。如果只做一级分类用不到但如果做了两级分类列表接口就得支持“点击父分类看到所有子分类的商品”。这个逻辑写出来不复杂子分类集合用IN查询就行但要在设计接口参数时提前预留好categoryId的层级语义。3.4 购物车与下单事务和库存一致性怎么保证购物车这块逻辑不难但容易出Bug。加购的逻辑是先查该用户购物车中是否已有这个商品有的话数量累加没有的话新建一条记录。修改数量时要判断不能小于1也不能超过库存上限。删除支持批量删除或单条删除。这些接口实现时都要注意从Session或Token中解析出当前用户id而不是让前端传入用户id。如果前端能随便传userId操作别人的购物车那这个系统就太离谱了答辩时万一被问到这个点就尴尬了。下单是整个系统的核心链路也是最能体现设计水平的地方。我按下单流程把关键逻辑梳理一遍第一步从购物车中读取当前用户选中的商品项。第二步遍历校验商品是否仍为上架状态库存是否充足价格需要从商品表实时取不能信任购物车里的快照价格。第三步扣减库存这里要特别注意并发问题。正确写法是使用带条件的更新SQLUPDATE t_product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}。这条SQL如果影响行数为0说明库存扣减失败要么是库存不足要么是商品不存在直接抛异常回滚。这就是乐观锁的思路比先查后改安全得多能防止超卖。第四步生成订单主记录和订单明细记录。第五步清除购物车中已下单的商品项。第六步模拟支付毕设里一般是点击提交订单后直接把状态置为已支付或者单独做一个支付弹窗模拟调一个不需要接入真实支付网关的接口随机成功或失败。整个流程必须放在一个事务里。在Service方法上加Transactional(rollbackFor Exception.class)任何一步抛异常前面所有操作全部回滚数据库不会处于中间状态。注意rollbackFor一定要指定默认情况下Transactional只在RuntimeException下回滚如果你抛的是自定义的检查异常事务不会回滚这坑我很早之前踩过印象太深了。4. 前端呈现与联调上线让系统真正能跑能演示4.1 前端方案Thymeleaf还是前后端分离前端方案前面提了一嘴这里展开说说我的真实看法。如果你想在短时间内做出一套看着舒服的界面Thymeleaf加Bootstrap是个稳妥选择。Spring Boot对Thymeleaf的支持很友好在application.yml里配置好视图解析器Controller返回index字符串就对应templates/index.html模板。模板语法本身也不复杂th:each遍历商品列表、th:href动态拼接链接、th:if做条件判断有HTML和Java基础的人一两天就能上手。页面继承用layout:fragment定义公共头部、底部商品页、详情页复用同一套导航栏开发效率很高。前后端分离方案的好处也很明显页面质感能拉开差距。用Vue加Element UI或者更轻量的Vant移动端风格也挺好看页面交互流畅度完全不是服务端渲染能比的。代价是你要自己处理跨域。我推荐的做法是在后端写一个CORS配置类用WebMvcConfigurer的addCorsMappings方法统一允许跨域同时allowCredentials设为trueallowedOriginPatterns用具体域名或*前端Axios配置withCredentials: true这样Cookie和Session才能在跨域请求中正常传递。这个配置网上抄很容易但要注意版本差异Spring Boot 2.4之后通配符配置有变化你如果照旧教程写可能跨域依然报错。如果你时间紧张、又想要前后端分离的样子还有一个折中方案后端只写一套Thymeleaf首页其他模块做成接口返回JSON用原生JavaScript加少量Vue语法写页面。不需要完整脚手架也不需要Node环境照样能做出局部动态刷新的效果。4.2 商品页性能优化与图片处理前端性能优化是毕业设计里容易被忽视、但产出效果最明显的环节。商品列表页最常见的性能问题就是图片加载一个页面几十张大图首屏全部请求服务端压力大用户体验也差。最简单的优化方法是图片懒加载。Bootstrap的Layui自带懒加载组件原生的做法是用>
