做毕业设计选什么题一直是最让人纠结的事。我见过太多人一上来就选“某某管理系统”结果做出来就是个增删改查全家桶连自己答辩时都觉得没什么亮点可讲。如果你学的是Java方向对SpringBoot又比较熟那我接下来拆解的这个项目——基于SpringBoot的渔具商城与预约购买平台倒是很适合拿来参考或者直接复现。这个项目虽然名义上叫“渔具管理系统”但它不是单纯让管理员录商品、查订单那么简单。它把钓鱼用品这种垂直商品类目和线上商城、店铺入驻、预约购买串在了一起。换句话说这既是一个面向消费者的销售平台也是一个面向商家的店铺管理后台还带一点O2O的味道——比如线下门店的渔具预约、到店自提这种场景。对毕业设计来说这个调性刚好业务逻辑不复杂到做不完但也足够你在论文里把需求分析、系统设计、数据库设计、核心模块实现写得很饱满。适合谁来参考主要是两类人。一类是Java后端方向、需要一个完整全栈项目的毕业生另一类是自己正在学SpringBoot想做一个能写进简历的真实业务项目的人。全文我会按项目拆解、技术选型、核心实现、联调部署、问题排查这五条线来讲所有代码和配置都是我在实际开发中验证过的。1. 项目拆解这个渔具系统到底在做哪些事1.1 三种角色划分成三个战场整个平台分三种角色平台管理员、商家店铺主、普通用户钓鱼爱好者。这个三角结构是整个系统设计的骨架。平台管理员负责商家入驻审核、商品类目维护、全局订单统计、内容管理相当于平台运营方。商家注册店铺、上架渔具商品、设置库存和价格、配置预约时段、处理订单和预约记录。用户浏览商品、加购物车、预约商品或门店服务、下单付款、查看个人订单、发表评价。很多人把用户表设计成一张大表所有角色塞一起后面一旦需要区分不同角色的权限和菜单就会非常痛苦。所以第一步我就把user表单独拆出来用role字段区分再配合拦截器做接口鉴权。商家信息单独放shop表和用户表用user_id关联这样查“这个用户开没开店”就特别方便。1.2 为什么说纯管理系统没亮点纯粹的“渔具管理”系统只有管理员一个角色CRUD做完就没什么可说的了。但渔具商城不一样用户端有商品浏览、购物车、预约下单商家端有店铺装修、商品上下架、预约时段管理平台端有审核流程和数据统计。这三个视角串联起来演示的时候流程感很强管理员审核店铺 → 商家上架渔具 → 用户预约购买 → 商家发货或到店核销。这个流程本身就够写成论文里的业务流程图了。而且钓鱼用品有个特点它不只是标准商品还有很强的线下服务属性——比如鱼竿保养、鱼线绑定、门店自提。所以我在设计里专门加了“预约购买”模块用来支撑线下自提和到店服务这也是整个项目区别于普通商城的核心亮点。1.3 SpringBoot到底香在哪选SpringBoot不是跟风是它确实适合这种业务系统的快速落地。内嵌Tomcat不用单独装服务器打包成jar直接跑。自动配置让集成变得极简加一个starter就得一个能力pom.xml清清楚楚。生态成熟MyBatis Plus、Redis、JWT、微信支付都有现成方案踩坑少。对答辩来说“SpringBoot Vue前后端分离 MySQL”是当前最主流的技术栈面试官和评审老师都认得不容易被质疑技术选型。我见过有同学非要选SSHStruts2 Spring Hibernate来彰显个性结果配置绕来绕去光环境搭建就卡了两周最后不得不换回SpringBoot。做毕业设计稳妥比炫技重要。2. 技术选型与架构设计每一步都有讲究2.1 持久层方案MyBatis Plus更合拍持久层我选了MyBatis Plus而不是Spring Data JPA。理由很简单渔具商城这种业务涉及大量多表关联查询和分页MyBatis Plus既能像单表CRUD那样无脑操作又能灵活写XML里的大SQL。JPA虽然也能做但它的关联映射和懒加载机制对新手并不友好经常查出来一堆冗余数据或者莫名其妙报LazyInitializationException。以下是商品分页查询的示例一个LambdaQueryWrapper就能把条件查询和排序搞定Service public class ProductService { Autowired private ProductMapper productMapper; public PageProduct pageProducts(int page, int size, String keyword, Long categoryId) { PageProduct p new Page(page, size); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapperProduct() .eq(Product::getStatus, 1) .like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(categoryId ! null, Product::getCategoryId, categoryId) .orderByDesc(Product::getCreateTime); return productMapper.selectPage(p, wrapper); } }这里有几个细节值得注意like的第一个参数是布尔值条件不满足时MyBatis Plus会自动跳过这条拼接eq同理。这样就不用在代码里写一堆 if 来判断参数是不是空非常干净。2.2 数据库设计先把核心表的轮廓画出来数据库设计是整个项目的地基后面所有功能都是这张表结构图上长出来的果。我核心建了这么几张表表名作用关键字段user用户账号与角色id, username, password, roleshop商家店铺信息id, user_id, shop_name, logo, statuscategory渔具商品类目id, name, parent_idproduct商品表id, shop_id, category_id, name, price, stock, coverappointment_slot预约时段id, shop_id, start_time, end_time, max_count, booked_countappointment预约记录id, user_id, slot_id, product_id, statusorders订单表id, order_no, user_id, shop_id, amount, status其中appointment_slot是预约模块最重要的表。预约不能只说“我要预约”必须落到具体时段否则商家根本没法安排接待。每个时段都记录最大可预约人数和已预约人数核销时再更新状态这就是预约系统的最小闭环。建表时我还会特意把所有表的主键都设为BIGINT AUTO_INCREMENT时间字段统一DATETIME DEFAULT CURRENT_TIMESTAMP字符集用utf8mb4。这几个惯例看着不起眼但能省掉不少后患。2.3 预约购买的库存控制三种方案的取舍预约购买最容易翻车的地方是库存超卖。我对比过三种控制方案各有适用场景方案实现成本并发能力推荐场景乐观锁SQL低中毕业设计首选单库场景足够悲观锁 for update低低并发不高的后台管理场景Redis Lua 脚本中高高真实商城、秒杀场景毕业设计阶段直接用乐观锁就行。原理就是更新库存时带上stock 0条件如果更新的行数为0说明库存已经没了。SQL可以这样写UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity};在Service层判断affected 0就抛异常回滚事务。这个方案不用引入Redis代码量极少但对一个单体毕业设计项目来说已经足够应对答辩时“并发控制怎么做的”这种提问。3. 核心功能实操从表结构到接口实现3.1 商家入驻与审核流程直播商家的入驻不能像用户注册那样直接生效否则平台上会出现大量没人管理的垃圾店铺。我更建议走“注册申请 → 管理员审核 → 生效”的流程用户在前端填写店铺名称、联系方式、主营类目提交后写入shop表此时status为 0待审核。管理员在后台看到待审核列表点击通过或驳回。审核通过后shop.status变为 1用户角色同时在user表里同步为SHOPKEEPER。审核操作的后端代码可以这么写Transactional public void auditShop(Long shopId, boolean pass) { Shop shop shopMapper.selectById(shopId); if (shop null) { throw new BizException(店铺不存在); } if (pass) { shop.setStatus(ShopStatus.ACTIVE.getValue()); shopMapper.updateById(shop); // 同步把店主的角色提升为商家 LambdaUpdateWrapperUser wrapper new LambdaUpdateWrapperUser() .eq(User::getId, shop.getUserId()) .set(User::getRole, Role.SHOPKEEPER.name()); userMapper.update(null, wrapper); } else { shop.setStatus(ShopStatus.REJECTED.getValue()); shopMapper.updateById(shop); } }注意我用Transactional把店铺状态更新和用户角色更新绑在了同一个事务里避免出现“店铺审核通过但角色没同步”的数据不一致问题。这是实战中很容易被忽略的地方。3.2 商品管理的几个实操细节商品是商城的核心做这部分时要把几个点想透。上架规范商品名称、类目、价格、库存、封面图必填价格保留两位小数库存至少为0。上下架机制不是删除商品而是把status从 1 改为 0这样历史订单还能引用商品快照。图片处理封面图和详情图分开存上传时重命名文件避免中文名和空格导致URL乱码。我自己实现的上传接口长这样PostMapping(/upload) public ResultString upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(请选择文件); } String originalName file.getOriginalFilename(); String ext originalName.substring(originalName.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) ext; try { file.transferTo(new File(uploadDir fileName)); } catch (IOException e) { throw new BizException(文件保存失败); } return Result.success(/upload/ fileName); }我踩过的一个坑是本地直接写/data/img/这种绝对路径部署到不同环境就要改代码。更好的做法是把这个路径配置到application.yml里用Value注入打包时只带配置不把环境写死。3.3 预约购买的核心代码与状态机预约购买是本系统最亮眼的功能我把它拆成了四个子步骤Transactional(rollbackFor Exception.class) public boolean createAppointment(AppointmentCreateDTO dto) { // 1. 校验预约时段是否还有余位 AppointmentSlot slot slotMapper.selectById(dto.getSlotId()); if (slot null || slot.getBookedCount() slot.getMaxCount()) { throw new BizException(该时段已约满); } // 2. 商品库存走乐观锁防止超卖 int affected productMapper.deductStock(dto.getProductId(), dto.getQuantity()); if (affected 0) { throw new BizException(商品库存不足); } // 3. 占用预约时段名额 int slotAffected slotMapper.increaseBookedCount(dto.getSlotId()); if (slotAffected 0) { throw new BizException(预约时段人数已满); } // 4. 生成预约记录初始状态为“待支付” Appointment appointment new Appointment(); appointment.setUserId(dto.getUserId()); appointment.setSlotId(dto.getSlotId()); appointment.setProductId(dto.getProductId()); appointment.setStatus(AppointmentStatus.UNPAID.getValue()); appointmentMapper.insert(appointment); return true; }这段代码的核心在于先校验时段再用SQL原子更新锁定库存最后插入预约记录。三步全部包在事务里任何一步失败都会整体回滚不会出现“库存扣了但预约没生成”的数据孤儿。预约订单需要一个状态机来管理流转我用枚举类把所有状态定义清楚public enum AppointmentStatus { UNPAID(0, 待支付), PAID(1, 已支付待核销), FINISHED(2, 已核销), CANCELED(-1, 已取消); private final int value; private final String desc; // 构造方法、getter省略 }状态流转路径很简单待支付 → 已支付待核销 → 已核销待支付状态下可以取消。商家核销时输入用户预约码后端校验预约码对应记录的状态是PAID才允许改成FINISHED。这个设计保证了一个预约码只能用一次。4. 前端联调与部署把项目跑起来4.1 跨域、登录态与接口鉴权前端我用Vue写的开发时和后端是两台不同的服务器跨域问题第一个出现。SpringBoot里加一个配置类就能解决Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true); } }登录态我用的JWT方案签发token后前端每次请求把token放进Authorization头。后端写一个拦截器统一校验public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !JwtUtil.verify(token)) { response.setStatus(401); response.getWriter().write(未登录或token已失效); return false; } Long userId JwtUtil.parse(token).getUserId(); UserContext.set(userId); return true; } }这里我多说一句JWT的密钥要放到配置文件里不要硬编码在Java类中。答辩老师很可能问“如果服务器重启了用户还需要重新登录吗”你要能解释清楚JWT无状态服务器重启不影响已签发的token但一旦密钥泄露攻击者可以直接伪造管理员token所以生产环境要用足够长的随机密钥并定期更换。4.2 Vue打包放进SpringBoot答辩时要给老师演示如果还得开两个窗口、手动启动前端服务器多少有点狼狈。我推荐把Vue项目打包后直接放进SpringBoot的静态资源目录实现单jar运行。操作流程# 1. 在Vue项目中构建生产包 npm run build # 2. 把dist目录拷贝到SpringBoot的src/main/resources/static cp -r dist/* ../src/main/resources/static/ # 3. 重新打包SpringBoot应用 mvn clean package -DskipTests这里有个路由模式的坑Vue默认的history模式刷新页面会404因为SpringBoot不知道前端路由。最省事的办法是在Vue Router里用hash模式URL会带上#虽然没有history模式好看但完全不需要后端配合。如果强迫症非要history模式那就要在SpringBoot里配置一个兜底转发把所有非/api开头的请求转发到index.html这个方案麻烦不少毕业设计不建议折腾。4.3 部署时容易忽略的时间与时区问题这套系统跑起来后最容易出的奇怪问题就是时间不对明明存的是当前时间数据库里显示的却是早上8点。这是时区问题不是代码问题。解决方案是MySQL连接串里显式指定时区spring.datasource.urljdbc:mysql://localhost:3306/fishing_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai同时SpringBoot返回给前端的JSON日期格式也会默认带T最好在配置里统一格式spring.jackson.date-formatyyyy-MM-dd HH:mm:ss spring.jackson.time-zoneAsia/Shanghai这两个配置加上前后端看到的时间就一致了。我见过不少同学因为在测试机上是UTC时区订单创建时间活活差了8小时排查了半天最后发现不是代码问题纯粹是时区配置没写。部署命令很简单我自己常用这套mvn clean package -DskipTests nohup java -jar fishing-mall.jar --server.port8080 app.log 21 加nohup和是为了让进程在SSH断开后不退出。日志重定向到app.log出问题时直接翻日志比在终端等崩溃信息要可靠得多。5. 常见问题排查与答辩实录5.1 图片上传后访问404的修复过程我做图片上传时遇到的第一个问题文件明明保存成功了浏览器访问却能正常。后来才意识到SpringBoot默认的静态资源目录不包含我自定义的/data/img/。要加一个资源映射器Configuration public class ResourceConfig implements WebMvcConfigurer { Value(${upload.dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir); } }这个配置的意思是URL路径/upload/xxx.jpg映射到磁盘目录file:/data/img/xxx.jpg。但要注意最后的斜杠必须写file:前缀也必须带否则无法识别为文件系统路径。这个问题卡了我一下午但明白原理之后就一劳永逸了。5.2 并发下单超卖问题实战我在自测时特意用两个浏览器同时下单果然出现了库存变负的情况。这正是因为最初版本只做了“先查库存再减库存”两个事务都读到stock5然后各自减1。后来改了乐观锁SQL问题就解决了。这里要强调的是事务的隔离级别只能保证不会脏读但解决不了并发下的逻辑超卖。真正的关键是让update语句本身具备原子性where条件里把stock quantity写进去数据库行锁会保证同一时刻只有一个事务能修改这一行。理解了这点面试和答辩都稳。5.3 答辩时导师最爱问的几个点我把答辩过程中被问最多的问题整理出来为什么选择SpringBoot答开发效率高、生态成熟、内嵌容器便于部署同时配合MyBatis Plus能快速完成数据访问层。系统有哪些角色权限控制是怎么做的答管理员、商家、用户三种角色通过user.role字段区分后端拦截器校验token并解析角色接口用注解标记需要的权限。预约购买和普通购买有什么区别答普通购买直接下单支付预约购买需要选择门店和时段支付后锁定商品的库存和预约名额到店后凭预约码核销。并发下如何防止超卖答更新库存的SQL带上stock quantity条件受影响行数为0即失败同时整个流程放在事务里保证一致性。前后端如何通信答RESTful接口JSON格式跨域用CORS配置登录态用JWT无状态token。这些问题都不难但要能把原理讲透而不是背概念。我的经验是在答辩前把系统核心代码翻一遍能指出每个关键方法在哪一行老师对你的印象会完全不一样。整个项目做下来我最大的体会是毕业设计不是在比谁技术炫而是在比谁能把一个业务场景讲明白、做完整。渔具商城这个选题好就好在它不高大上却五脏俱全——有审核流程、有商品流转、有时段预约、有订单状态机每个点都能深入一层。做完这个项目再去写简历里的项目经验你会有底气把“职责”和“难点”写得很实在。最后再分享一个小技巧做这种带预约功能的系统一定不要把预约逻辑和订单逻辑揉成一坨。预约有自己的状态流转和核销动作订单负责支付和退款两者解耦后后续加需求比如预约改期、商家取消预约会轻松很多。这个设计习惯也算是我在这个项目里收获的最大一笔财富。