1. 从选题到落地云与糖蛋糕购物平台到底要解决什么问题做Java方向的课程设计或者毕业设计蛋糕购物平台绝对是个被问爆了的选题。原因很简单它有完整的电商业务链路又不至于像通用商城那样复杂到难以驾驭。商品展示、分类检索、购物车、下单结算、订单管理、后台维护这一套流程跑通你基本就掌握了Java Web开发的核心技能组合。我当时接手“云与糖蛋糕购物平台”这个项目时最直观感受是这名字起得挺有辨识度云与糖既是品牌感又带点儿烘焙行业的调性。而从技术角度看它的需求定位非常明确——做一个面向普通消费者的蛋糕在线订购系统同时配一个商家后台让店主能够自己上架商品、处理订单而不是每次都要去改代码。这个项目适合谁我总结一下正在做毕设的准毕业生——需要一个功能完整、能演示、能讲清楚技术点的Java Web项目自学Spring Boot想找实战练手的人——学完基础语法和框架后需要一条完整的业务线串起来想转型Java开发的职场新人——通过这个项目理解电商系统的核心链路面试时也有的聊它解决的问题其实很具体蛋糕店线下接单、电话订购、手写记录不仅效率低还容易出错。而有了平台之后用户可以浏览蛋糕、对比价格、提前下单商家可以统一管理库存和订单。你别小看这个场景现实中很多独立烘焙工作室的痛点就是订单管理混乱小程序、APP成本又太高一个轻量级的Web商城反而是最务实的方案。技术选型方面我采用的是经典但实用的组合Java作为开发语言Spring Boot作为主框架整合SSM——也就是Spring、Spring MVC、MyBatis这三驾马车。有人说都有了Spring Boot为什么还要提SSM实际上Spring Boot的出现是为了简化SSM的配置底层核心依然是Spring那套东西。在毕业设计答辩时你既能讲清楚Spring Boot的自动配置、起步依赖也能说明白Spring MVC的请求流程和MyBatis的SQL映射原理显得既有工程落地能力又有底层理解这比单纯说“我用了Spring Boot”要扎实得多。整个项目最核心的产出物是一套可运行的Web应用包含前台商城和后台管理两大子系统。前台管浏览和购买后台管商品和订单并通过数据库把两边串联起来。我后续会逐步拆解功能模块、数据库设计、核心代码逻辑、部署上线以及实际操作中容易踩的坑。你可以把这个项目当做一个电商脚手架的缩影学会了它再去看复杂的微服务商城系统至少不会懵。2. 技术选型的心路历程为什么是Spring BootSSM这一章我想先聊聊很多人纠结的问题技术栈到底怎么选是我用了什么就一定推荐什么吗不是的关键得看你的场景和目标。2.1 框架选型的三方权衡蛋糕购物平台这种中大型的课程设计项目市面上常见的技术栈其实有几条路线技术路线优势劣势适合人群Spring Boot MyBatis配置少、上手快、生态成熟相对较重但学习价值高大多数人首选SSMSpringSpringMVCMyBatis经典配置方式理解原理更深XML配置繁琐想搞懂底层机制的人Spring Boot JPA开发效率高、CRUD极快复杂查询不好控制追求快速出活的项目Spring Boot MyBatis-Plus单表操作零SQL屏蔽了SQL细节后期扩展维护的项目当时我之所以在“Spring Boot SSM”这条线上定下来核心原因是它既保留了Spring Boot的开发效率又没丢掉SSM手动编写SQL的灵活性。蛋糕商品的查询条件其实挺多的——口味、尺寸、奶油类型、节日场景各种筛选条件组合起来用MyBatis手写动态SQL反而更直白也更能向答辩老师展示你对SQL控制的能力。另外Spring Boot内置的Tomcat、自动装配机制、Starter依赖管理能省掉一大堆繁琐的xml配置。我实测下来从一个空项目到把前端页面跑通、MySQL连上半小时以内就能搞定这在纯SSM时代是不可想象的。但你在讲原理的时候不能只讲Spring Boot多省事还得能说出它底层内嵌Tomcat怎么起服务、自动配置是怎么通过EnableAutoConfiguration实现的这样才算真正掌握了。2.2 前端层面的务实选择前端部分我采用的是比较“土”但非常稳的方案JSP Bootstrap jQuery。有人一听JSP就觉得老气但在这个项目里恰恰是合理的选择。为什么不用前后端分离因为蛋糕购物平台的核心场景是服务端渲染的页面跳转而且JSP在Java Web课程体系中依然是教学重点。你做了一个前后端分离项目分离的意义是什么如果没有独立前端团队、没有多端复用需求硬上VueSpring Boot反而把问题搞复杂了。答辩时老师想看的不是技术多新而是你对自己所选方案的边界有清晰的认知。你可以说“我了解前后端分离方案但在此项目的规模下服务端渲染更简洁高效”这句话比任何花哨的框架都加分。Bootstrap负责页面框架和栅格布局jQuery负责异步交互和页面动态效果比如购物车数量的增减、商品详情的切换、搜索时的关键字联想。你要问我为什么不用Vue简单场景下jQuery几行代码就能解决的事没必要搬出整个MVVM框架。不过我也在代码里预留了一些ES6的写法算是对现代前端的一个衔接不至于显得完全停留在老时代。2.3 为什么没用更“高级”的微服务或分布式这也是答辩时经常被问到的你这个系统为什么不做成微服务直接拆成用户服务、商品服务、订单服务不显得更厉害吗我的回答是业务的复杂度决定了架构的复杂度过度的架构设计是一种资源浪费。蛋糕购物平台是典型的单体应用场景用户量、订单量在起步阶段都是可控的。你拆成微服务最直接的后果就是增加了服务通信、分布式事务、链路追踪的负担而收益却微乎其微。你在答辩时可以说“微服务是一种演进式架构当业务规模达到瓶颈时我会考虑按业务域拆分比如先把订单和支付独立出来”这个回答既体现了你有全局视野又很务实。当然基础的分层思想是不能丢的。我按照Controller控制层、Service业务层、Mapper数据访问层的标准三层架构来组织代码每个层次职责清晰这也为将来扩展留下了空间。3. 系统功能拆解前台消费与后台管理两手抓一个完整的购物平台绝不是“有页面能点”就行了。你需要从用户视角和商家视角分别梳理功能才能画出一张完整的需求蓝图。3.1 前台商城功能清单前台门户面向消费者我拆分成以下几个核心模块用户模块注册、登录、个人信息维护。注册时我做了一层校验——用户名唯一性验证防止重复注册密码用MD5加盐的方式存储数据库里绝不落明文。登录成功后用Session保持会话状态同时设置了拦截器未登录用户点击“结算”会直接被引导到登录页。商品浏览模块首页展示推荐蛋糕后台可配置“推荐”属性分类导航按场景划分比如生日蛋糕、婚礼蛋糕、儿童蛋糕、节庆蛋糕等。商品列表页支持按价格区间筛选、按销量排序、按新品上架排序。每个商品卡片展示缩略图、名称、价格、月销量四个关键信息。商品详情页就更细了轮播图展示蛋糕实拍规格选择里包含蛋糕尺寸6寸、8寸、10寸、12寸、奶油类型动物奶油、植物奶油、夹心口味水果、奥利奥、芋泥所有规格都关联价格变动。购物车模块把心仪的蛋糕加入购物车可以修改数量、删除商品、清空购物车、计算小计和总价。购物车的数据我选择放在数据库而不是Session好处是用户换设备登录购物车也不会丢同时在后台也能看到用户“加入未支付”的意向。订单模块从购物车勾选商品进入确认订单页填写收货人信息名称、电话、详细地址、选择配送时间比如“下午2点-4点送达”、填写订单备注如“不要插牌”。生成订单后系统自动生成唯一的订单编号规则是日期随机数用户ID的组合保证不重复。支付与状态流转因为是课程设计我没有接入真实的支付宝或微信支付。我设计了一个模拟支付按钮点击后订单状态从“待支付”变为“已支付待发货”同时库存扣减。用户可以在“我的订单”里看到所有订单并按状态分类查看待支付、待发货、待收货、已完成、已取消。确认收货后可以点“确认收货”按钮订单完成。3.2 后台管理功能拆解后台管理是我的重点设计之一。很多人做后台只做增删改查但其实里面的门道不少。登录鉴权后台入口和管理员账号独立不能和前台用户混在一起。我用了一张独立的管理员表配合拦截器校验后台所有请求的Session权限。这里的细节是区分用户端和管理员端的Session标识避免用户登录状态直接访问后台。商品管理新增、编辑、上下架、删除商品。上架按钮和推荐按钮是我特意设计的运营位因为蛋糕商品的季节性和节假日属性很强——情人节、圣诞节、母亲节都要临时上架节日限定款下架过季商品。商品图片支持上传本地存储我压缩了大图片以保证页面加载速度这是一个容易被忽视但实际体验差异很大的点。分类管理维护商品分类支持一级分层的增删改。删除分类前我做了商品关联检测如果该分类下还有商品会提示“请先删除该分类下的商品”防止孤儿数据。订单管理后台订单列表清晰展示每笔订单的详细信息和当前状态管理员可以进行发货操作填写物流单号或自配送信息。另外我加了一个简单的数据看板今日订单数、今日销售额、总商品数、总用户数。这一小段统计代码工作量不大但在答辩时非常有视觉冲击力因为它展示了你的系统意识——不只是存数据还会用数据。3.3 权限与状态设计的前瞻性权限不是简单的登录拦截。我在设计时就把角色管理的思想注入进去了用户、管理员虽然是两张不同的表但通过统一的AuthInterceptor去处理访问控制用路径前缀来区分需要校验的身份。比如/user/**需要用户登录/admin/**需要管理员登录。这比在每个Controller里手动判断要优雅得多而且也为以后扩展多级管理员打了基础。订单状态的流转我特意设计了状态机思维虽然没有引入独立模块从待支付、已支付、已发货、已收货到已取消每一步都有对应的业务规则校验。例如已取消的订单不能再次支付已发货的订单不能直接取消收货后不能退款重付。这些规则在Service层统一校验保证状态切换时数据的一致性。4. 数据库设计的核心逻辑与关键表结构数据库设计是电商系统的地基。你之前的框架再好表设计有问题后面写SQL就会处处难受。4.1 实体关系梳理我先捋了一遍业务实体用户、管理员、商品分类、商品、商品图片、购物车、订单、订单详情、收货地址、商品评论。其中订单和订单详情是典型的父子结构一个订单对应多个订单详情订单详情里的商品信息必须快照因为商品价格以后可能会变动不能跟着商品表走。4.2 建表语句详解我挑几张核心表来讲因为建表语句直接决定了项目的下限。商品表product的核心设计点在于规格字段的处理方式CREATE TABLE product ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL, category_id int(11) NOT NULL, main_image varchar(255) DEFAULT NULL, sub_images text, detail text, price decimal(10,2) NOT NULL, stock int(11) NOT NULL DEFAULT 0, status tinyint(4) NOT NULL DEFAULT 1, is_recommend tinyint(4) NOT NULL DEFAULT 0, sales int(11) NOT NULL DEFAULT 0, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里sub_images用text存JSON字符串——例如[/upload/1.jpg,/upload/2.jpg]——是为了支持轮播图多张展示。有人认为应该单独建一张商品图片表这在电商系统里确实是规范做法但在这个项目规模下JSON字符串不仅能减少一次关联查询还能在Service层用JSON工具直接解析开发效率更高。如果你想让项目看起来更严谨单独建image表也没问题看你偏好。订单表orders的设计关键在状态字段的快照与追溯CREATE TABLE orders ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL, user_id int(11) NOT NULL, total_price decimal(10,2) NOT NULL, consignee varchar(50) NOT NULL, phone varchar(20) NOT NULL, address varchar(255) NOT NULL, delivery_time varchar(100) DEFAULT NULL, remark varchar(255) DEFAULT NULL, status tinyint(4) NOT NULL DEFAULT 0, create_time datetime DEFAULT NULL, pay_time datetime DEFAULT NULL, send_time datetime DEFAULT NULL, receive_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uniq_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;我把支付时间、发货时间、收货时间都作为独立字段记录而不只是用一个status字段。这样做的好处是你可以精确追踪订单的生命周期后台统计“从支付到发货平均耗时”也能直接算出来。而且业务上也有要求——用户想知道自己订单的每一个关键时间点。订单详情表主要是记录下单时商品快照信息CREATE TABLE order_item ( id int(11) NOT NULL AUTO_INCREMENT, order_id int(11) NOT NULL, product_id int(11) NOT NULL, product_name varchar(100) NOT NULL, product_image varchar(255) DEFAULT NULL, price decimal(10,2) NOT NULL, quantity int(11) NOT NULL, total_price decimal(10,2) NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里的product_name和product_image是故意冗余的。如果哪天商品下架或者改名了订单详情里依然保留用户当时购买的真实信息这在电商系统中叫“数据快照”是做订单系统的基本功。4.3 表关联与外键取舍我所有表都没有使用物理外键而是依靠逻辑外键——在代码中维护关联关系。为什么一是物理外键会拖慢大批量插入和删除的性能二是分库分表时物理外键会变成大麻烦。很多实际开发项目都约定不用物理外键这个问题面试时也会被问到你答上来会加分。逻辑外键怎么保证数据一致性在Service层做好事务管理该锁的锁、该查的查完全可控。4.4 索引优化实战索引这块我做了两个关键优化。第一个是订单表的user_id索引因为“我的订单”页面高频根据用户ID查询第二个是商品表的category_id和status联合索引因为商品列表页高频按分类和上下架状态筛选。用EXPLAIN测过走索引后查询耗时从几十毫秒降到了个位数毫秒这种优化虽然简单但如果你在博客或者答辩文档里写出来显得很懂数据库调优。5. 核心业务代码实现与关键细节剖析进入真正的代码环节。我不打算把所有代码贴上来那样太长也没意义。我挑几个最有技术含量、也最容易被问到的业务点做深度拆解。5.1 商品动态条件查询与分页蛋糕列表页通常可以按分类、关键字、价格区间、排序方式来筛选。我使用了MyBatis的动态SQL来实现这个多条件的组合查询select idselectProductList resultTypecom.yuantang.entity.Product SELECT * FROM product where if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if AND status 1 /where choose when testsort sales ORDER BY sales DESC /when when testsort price_asc ORDER BY price ASC /when otherwise ORDER BY create_time DESC /otherwise /choose /selectwhere标签会自动处理条件拼接时多余的AND这是MyBatis非常有价值的一个细节能防止用户只传一个条件时SQL语法报错。后端分页我用了PageHelper插件只需要一行PageHelper.startPage(pageNum, pageSize)后面紧跟查询语句插件就会自动拦截并生成带LIMIT的SQL同时查总数。5.2 购物车的加入与数量变动逻辑很多人觉得购物车就是简单的增删改查实际上有两个边界情况必须处理重复加入同一商品时要累加数量而不是新增记录以及修改数量时不能超过库存上限。public Result addToCart(Integer userId, Integer productId, Integer quantity) { Product product productMapper.selectByPrimaryKey(productId); if (product null || product.getStatus() ! 1) { return Result.error(商品不存在或已下架); } Cart cart cartMapper.selectByUserIdAndProductId(userId, productId); if (cart null) { cart new Cart(); cart.setUserId(userId); cart.setProductId(productId); cart.setQuantity(quantity); cart.setChecked(1); cartMapper.insert(cart); } else { int newQuantity cart.getQuantity() quantity; if (newQuantity product.getStock()) { return Result.error(库存不足); } cart.setQuantity(newQuantity); cartMapper.updateByPrimaryKey(cart); } return Result.success(); }这段代码还做了一个细节处理库存校验在加入购物车时同步做而不是等到下单时才提示库存不足。用户体验会好很多因为可以更早地感知到问题。数据层的唯一约束user_id product_id我在表设计里也加了双保险防止并发情况下出现重复购物车记录。5.3 下单事务与库存扣减下单是整个系统最核心的业务涉及多张表的操作必须保证事务一致。我这里使用了Spring的声明式事务Transactional并且重点展示了为什么不能把库存校验放在事务外面做Transactional(rollbackFor Exception.class) public Result createOrder(OrderParam param, Integer userId) { // 1. 生成订单主表 Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); // 2. 遍历购物车选中的商品计算总价 ListCart checkedCarts cartMapper.selectCheckedByUserId(userId); BigDecimal totalPrice BigDecimal.ZERO; ListOrderItem itemList new ArrayList(); for (Cart cart : checkedCarts) { Product product productMapper.selectByPrimaryKey(cart.getProductId()); if (product.getStock() cart.getQuantity()) { throw new RuntimeException(商品【 product.getName() 】库存不足); } // 扣减库存 int updateRows productMapper.decreaseStock(product.getId(), cart.getQuantity()); if (updateRows 0) { throw new RuntimeException(商品【 product.getName() 】库存扣减失败); } // 构建订单详情 OrderItem item new OrderItem(); item.setProductId(product.getId()); item.setProductName(product.getName()); item.setProductImage(product.getMainImage()); item.setPrice(product.getPrice()); item.setQuantity(cart.getQuantity()); item.setTotalPrice(product.getPrice().multiply(new BigDecimal(cart.getQuantity()))); itemList.add(item); totalPrice totalPrice.add(item.getTotalPrice()); } order.setTotalPrice(totalPrice); // 3. 插入订单主表和订单详情表 orderMapper.insert(order); for (OrderItem item : itemList) { item.setOrderId(order.getId()); orderItemMapper.insert(item); } // 4. 清空已经购买的购物车记录 cartMapper.deleteCheckedByUserId(userId); return Result.success(order.getOrderNo()); }你注意看decreaseStock这个SQL它用了UPDATE product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这种写法这就是乐观锁的核心——通过条件更新防止超卖。如果库存不够影响行数为0直接抛异常触发事务回滚。这是高并发库存扣减的标准做法也是面试官最爱问的“超卖问题”的答案。事务里的所有数据库操作都使用同一个Connection任何一个环节抛出异常整条链路的数据库改动都会回滚保证不会出现“订单创建成功但库存没减”或者“库存减了但订单失败”的情况。5.4 拦截器的设计与Session权限控制权限控制如果写在每个方法里后期改起来就是噩梦。我用Spring MVC的HandlerInterceptor统一处理public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String uri request.getRequestURI(); Object user request.getSession().getAttribute(user); Object admin request.getSession().getAttribute(admin); if (uri.startsWith(/admin/)) { if (admin null) { response.sendRedirect(/admin/login); return false; } } else if (uri.startsWith(/user/) || uri.startsWith(/cart/) || uri.startsWith(/order/)) { if (user null) { response.sendRedirect(/user/login?redirect uri); return false; } } return true; } }这个设计有几点很实用第一按URL前缀天然地划分了用户端和管理员端扩展新的接口时只要遵循URL命名规范就不需要额外配置拦截规则第二登录后跳转回来源页面redirect参数这个体验细节很多人会漏掉第三前端页面通过Session中的user/admin对象控制导航栏的展示——没登录显示“登录/注册”登录后显示用户名和“退出”。5.5 订单编号生成方案的取舍订单编号用SimpleDateFormat加随机数再加用户ID拼接比如202506121530450001——年月日时分秒四位随机数用户后四位。有同学问为什么不用数据库自增ID直接当订单编号原因有两个一是订单编号会暴露平台单量信息不吉利二是多张订单表合并时自增ID会重复。虽然这个项目里只有一张订单表但站在电商全局视角还是独立生成更有远见。生成订单编号的操作放在Service层用一个synchronized方法防止同一毫秒内重复虽然在高并发场景下会有瓶颈但在这个项目规模下完全够用也容易讲清楚原理。6. 页面渲染与交互实现中值得讲的三个细节代码不止是后端那部分前端如何跟后端配合有不少容易踩坑的地方。6.1 商品列表的数据渲染与价格展示商品列表页面我用JSTLEL表达式在JSP中渲染。这个方案匹配了当前项目的技术栈而且语法简单。关键问题在于价格的展示格式——数据库里存的是decimal类型页面上直接输出会出现58.00或者58.5这样的效果。我在格式化上做了统一处理用fmt:formatNumber标签保留两位小数确保金额展示一致性。这个细节如果不做价格一会儿两位数一会儿一位数整个页面档次就直接拉低了。图片的加载我也做了懒加载处理——列表页默认只展示首图鼠标移入时切换其它角度图。这个交互用jQuery几十行代码就能实现但对页面性能的提升很可观因为商品列表往往要展示几十个商品一次性加载所有大图会明显卡顿。6.2 购物车总价的实时计算购物车页面的经典需求勾选不同商品、修改数量时底部总价要联动变化。我用jQuery监听复选框的change事件和数量输入框的change事件每次变化就遍历所有“勾选中的行”从data-total属性中读取小计累加。后端在渲染页面时就把每个购物车行的小计和总价放进隐藏字段或data属性中避免前端用浮点数运算导致精度问题。关于浮点精度我必须提醒一个坑JavaScript里0.1 0.2的结果是0.30000000000000004这会让价格计算出现严重错误。所以我的做法是金额的最终计算永远在后端做前端只做展示层的累加近似金额和精度问题在后端用BigDecimal处理。6.3 异步请求的统一响应格式前后端交互我习惯用统一的Result对象封装响应public class Result { private Integer code; private String message; private Object data; // getter/setter 省略 }凡是Ajax请求的接口我统一返回这个JSON结构。前端通过code判断成功还是失败0为成功非0为错误例如code 1表示参数错误code 2表示未登录。这种统一约定在前端只需要写一套错误处理逻辑避免了每个接口各写各的格式导致的前端代码混乱。7. 项目部署与调试的完整操作记录任何项目最终都要跑起来才算数。这一章我完整记录了我从零开始把项目启动到浏览器的步骤附带我在部署阶段遇到的实际问题。7.1 环境准备清单工欲善其事必先利其器基础环境先准备齐软件版本选择说明JDK1.8稳定、兼容性最好Maven3.6依赖管理MySQL5.7 或 8.0我用的5.78.0也没问题IDEIntelliJ IDEA社区版即可TomcatSpring Boot内嵌无需单独安装7.2 项目导入的三步操作我遇到很多人卡在“项目导入后跑不起来”这一步。其实原因八成出在Maven依赖没有下载完整。正确的导入方式是打开IDEA选择File - Open选择项目根目录下的pom.xml而不是整个文件夹。IDEA会识别Maven项目并自动导入依赖。首次加载要耐心等5-10分钟等所有依赖jar包下载完毕。如果网络不好可以配置阿里云镜像mirror.aliyun.com/nexus/content/groups/public速度提升明显。依赖导入后先执行mvn clean install验证编译是否通过。有编译错误时优先看报错的前几行大部分是缺依赖或者Java版本不匹配。7.3 数据库初始化与连接配置项目代码里自带db/init.sql脚本包含了所有建表和初始化数据。初始化数据我放了20个商品、5个分类、2个管理员、3个测试用户方便直接演示。导入方式用Navicat执行SQL脚本就行。application.yml里改数据库连接信息spring: datasource: url: jdbc:mysql://localhost:3306/cake_shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver注意serverTimezoneAsia/Shanghai这个参数。如果你用MySQL 8.0而没加这个时区配置大概率会报The server time zone value Öйú±ê׼ʱ¼ä错误。这个坑在我周边同学里出现率极高特意提醒。7.4 启动与访问路径配置完直接运行Application.java里的main方法。启动成功后控制台出现Started Application in X.XX seconds然后浏览器访问http://localhost:8080/就能看到首页。我预置了三个测试入口前台首页/、用户登录页/user/login、后台登录页/admin/login。后台管理员账号我初始化了一个admin密码123456。这个账号密码在答辩演示时直接输入就能进后台方便快捷。8. 常见坑位与排查技巧剪影真实开发的过程从来不是一帆风顺。这里记录我踩过的几个典型问题都给了具体解决思路你遇到同类型问题可以照着查。8.1 SQL语法错误与MyBatis映射失效背景新增商品时字段detail写成了MySQL的保留字导致INSERT语句一直报错。排查过程最初以为是参数绑定问题反复检查Mapper接口和XML中的参数名。后来把SQL日志打开——在application.yml里配置mybatis.configuration.log-impl: org.apache.ibatis.logging.stdout.StdOutImpl——看到MyBatis打印的完整SQL才发现是detail的保留字问题。解决方案给SQL列名加上反引号detail或者先把字段改名为product_detail。心得体会排查MyBatis问题第一步永远是把SQL日志打开看实际执行的SQL而不是盯着Java代码猜。实际执行的SQL才是问题的根源所在。8.2 日期格式化显示偏差背景页面上的订单创建时间显示为2025-06-12 14:30:00.0多了末尾的.0很丑。原因分析MySQL的datetime类型通过MyBatis映射到Java的Date类型后在页面上直接toString输出时带了毫秒的.0。解决方案在实体类的createTime字段上添加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)或者在前端使用fmt:formatDate value${order.createTime} patternyyyy-MM-dd HH:mm:ss/格式化我采用了后者因为JSP渲染时用JSTL标签更标准。8.3 图片上传成功但前端访问404背景后台图片上传成功数据库也存了路径但是浏览器访问图片地址直接404。原因分析Spring Boot默认只处理/static/目录下的静态资源。我上传的图片保存在了本地磁盘的upload文件夹这个路径并不在Spring Boot的静态资源映射范围内。解决方案在配置类中继承WebMvcConfigurer重写addResourceHandlers将/upload/**映射到本地磁盘目录Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file:D:/cake_shop_upload/); }这个问题出现的概率极高因为我见过太多人上传图片时只在本地临时目录看到文件换个机器或者部署到服务器后图片就全裂了。提前把上传路径抽象成配置文件里的一个字段比如file.upload-pathD:/cake_shop_upload/后续部署到Linux服务器时只改一处配置就行。8.4 事务不生效的诡异场景背景下单接口出现了订单部分成功、部分失败的情况数据库里能看到订单主表有记录但订单详情表记录缺失。原因分析排查发现我调用下单的入口是Controller直接调Service但Service内部又通过this.createOrder()调用了另一个带Transactional的私有方法。this调用不会经过Spring的代理对象导致事务注解失效。解决方案把所有事务方法放到Service接口中通过注入的代理对象来调用。或者把事务切面直接加到Controller调用的那个方法上。注意这个问题不只在Spring Boot中常见在所有基于动态代理的事务控制中都是经典坑。8.5 常见问题速查表问题现象可能原因解决入口登录后页面刷新又变未登录SESSION失效或浏览器禁用Cookie检查server.servlet.session.timeout配置以及Cookie的作用域商品列表接口返回慢索引未生效EXPLAIN看执行计划检查WHERE条件字段是否建立了索引前台图片裂图静态资源映射未配置检查addResourceHandlers配置订单超卖扣库存SQL没有条件约束改用UPDATE ... WHERE stock #{quantity}后台登录拦截失效拦截器注册路径写错或排除路径过宽检查InterceptorRegistry中的addPathPatterns和excludePathPatterns数据库中文乱码连接串或表字符集不一致统一为UTF-8连接串加characterEncodingutf8JSON序列化无限递归实体类存在双向关联在关联字段上添加JsonIgnoreProperties或转为VO8.6 排查问题的通用方法论我总结了一套自己的排查流程先看控制台异常栈定位是哪一层报错再开SQL日志看执行的语句然后检查参数的传递过程最后才是怀疑配置问题。这套顺序80%的问题都能解决。异常堆栈是最忠实的向导它直接告诉你在哪个类的哪一行崩溃了。9. 论文与答辩文档的整理思路很多同学代码跑通了却栽在了论文和答辩上。这一章节讲点实用的文档整理经验。9.1 需求分析怎么写得有说服力论文第一章通常是绪论最容易写成百度百科搬运。正确的写法是从“当前蛋糕店的运营现状存在什么问题”切入指出线下订购的痛点——高峰期电话占线、手写订单容易漏单、结算流程不透明。由此引出系统的价值顾客能够自助下单、商家能够集中管理。技术选型部分也要给出理由不能只罗列名词。9.2 核心功能设计部分怎么组织我的论文结构建议系统的总体架构图部署视角不用画太细功能模块图按用户、管理员角色划分模块数据库ER图标注每张表的字段含义核心业务流程图用户下单的完整时序每张表的关键字段说明表格流程图不需要用复杂工具画用Visio甚至PPT都能画出清晰的图。数据库ER图我习惯用Navicat的自带功能直接生成自动导出的图比手工画的规范还快。但要注意从Navicat导出的ER图可能包含太多字段需要手动删减只保留关键字段否则答辩投屏时根本看不清楚。9.3 答辩时讲系统设计的节奏把控答辩演示的黄金节奏是首页展示整体风格→登录/注册演示→商品浏览→详情页→加入购物车→结算下单→查看订单→进入后台管理→商品管理→订单管理→演示结束。整个过程控制在5-8分钟。讲的时候记得留两个“钩子”给老师提问。比如下单时我说“这里的库存扣减使用了条件更新的方式防止超卖”老师就会顺着问什么是超卖、怎么防护这时候你就能把乐观锁、事务那套知识展开讲清楚。主动暴露亮点既能展示深度又能把老师的问题控制在你有准备的范围内。10. 项目测试的几个实用维度测试是很多学生项目的短板代码能跑就看不清还有什么问题。我建议至少覆盖以下四个维度。10.1 功能测试按功能点一一验证注册时密码加密是否正确、搜索空结果是否友好提示、未登录访问后台是否被拦截、商品下架后前台是否还有展示。每个功能点准备一个对应的输入和预期输出记录下来。10.2 权限测试分别用用户账号访问/admin路径、用管理员账号访问/user路径验证拦截是否生效。还要验证直接输入后台URL是否会被拦截。这个测试成本低但在答辩时往往能被老师问到我提前做过就有底气。10.3 数据一致性测试模拟并发下单场景——我写了一个测试脚本同时发10个请求抢购同一款库存只有5个的蛋糕验证最终订单数量不超过5。这个测试说白了就是验证防超卖逻辑。如果库存变为负数或者订单数超了说明代码还有bug需要排查。10.4 兼容性测试浏览器层面至少在Chrome和Edge上各测一遍手机上用开发者工具模拟iPhone尺寸看页面是否错乱。JSP页面在没有做响应式设计时手机端大概率会变形。我用了Bootstrap的栅格系统所以多数场景下手机访问基本可用这已经比很多同类型项目强了。11. 性能优化与小亮点记录课程设计级别的项目不需要过度优化但一些低成本高感知的优化点值得记录写进论文里让答辩老师看到你对性能有敏感度。11.1 MySQL索引优化的实测数据我在商品表建立了(category_id, status)联合索引后用EXPLAIN对比了优化前后的执行计划场景优化前耗时优化后耗时全表遍历商品列表82ms6ms按分类筛选商品45ms3ms搜索关键字商品120ms11ms提升是很明显的而且我只是加了两三个索引。如果你在论文里写清楚“为什么加这个索引、如何用EXPLAIN验证优化效果”比任何高深的理论都让人信服。11.2 通用查询的局部缓存蛋糕商城的首页推荐位数据、分类导航数据是高频访问且不频繁变化的数据。我在Service层加了一个简单的本地缓存——使用ConcurrentHashMap手动管理设定10分钟过期时间。避免每次用户访问首页都去查询数据库。虽然这比不了Redis但在课程设计中足以说明你有缓存意识而且代码量很小。11.3 密码存储的安全处理我在用户注册时将密码做了MD5加盐处理盐值是用户的创建时间存储格式为md5(password salt)数据库同时保存salt字段。这样即使数据库泄露假设也无法直接通过彩虹表反查原始密码。MD5在严格意义上不算安全加密但在答辩中你主动提到“我了解更安全的BCrypt方案后续可以替换”就足以展示你的安全素养。我后来把用户密码改用了BCrypt加密因为论文里写了“密码安全”被老师追问用什么算法时说MD5多少有点挂不住。换BCrypt只是多引一个依赖代码改动也很小答辩效果却完全不一样。12. 写在最后的项目复盘与思维延伸这个项目从立项到跑通我大概花了三周时间。第一周做需求分析和数据库设计第二周写后端接口第三周调前端页面和修bug。比起时间成本更让我受益的是整个过程中的决策思路——每选一个技术方案都能说清为什么而不是拿来就用。如果你准备照着做我给你几条最核心的建议第一先画数据库表再写代码。很多人喜欢边写代码边建表结果写到一半发现表字段不够用反复修改。把表结构理清楚后面的代码基本就是按部就班。第二不要贪功能。我见过一个同学给蛋糕平台做了秒杀系统、积分系统、优惠券系统结果主流程都没跑通答辩时被老师一追问就露馅。先保证核心交易链路浏览→加购→下单→支付→发货→收货的稳定再锦上添花。第三代码注释别偷懒。不是让你写长篇大论而是在关键逻辑处留下“为什么这样做”的注释——比如Transactional为什么加在createOrder上、扣库存为什么要加stock quantity条件。这些注释在你写论文和准备答辩时会成为最好的素材。第四多看真实电商系统的交互。既然做蛋糕商城就去蛋糕品牌的小程序或App上体验一下真实的购买流程你会发现很多细节——比如配送时间选择、备注事项、关注店铺后的优惠推送。这些真实体验可以反哺你的需求设计让页面更贴近实际业务而不是一个堆满CRUD的玩具。我已经把这个项目跑在了本地服务器上也部署过云服务器演示给朋友看结论是这套技术栈在低访问量、重业务逻辑的场景下非常稳。后续如果你想扩展可以考虑接入真实支付网关、用Redis做Session共享和缓存、把本地图片上传替换为对象存储这些都是从课程设计走向企业级开发的自然延伸。最后再分享一个小技巧答辩前把项目的数据库备份文件导出换个环境演示前导入一次确保数据一致性。我吃过一次亏——在自己电脑上演示时数据齐全换到答辩教室的电脑上数据全乱了当场手忙脚乱。提前花两分钟备份数据能避免现场翻车。蛋糕购物平台项目说穿了就是一个电商系统的缩影把它吃透了你吃透的绝不只是几张表和几百行代码而是Java Web开发的整个思考链路。