企业官网建设流程全解析

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 Boot+SSM

这一章我想先聊聊很多人纠结的问题：技术栈到底怎么选？是我用了什么就一定推荐什么吗？不是的，关键得看你的场景和目标。

2.1 框架选型的三方权衡

蛋糕购物平台这种中大型的课程设计项目，市面上常见的技术栈其实有几条路线：

当时我之所以在“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课程体系中依然是教学重点。你做了一个前后端分离项目，分离的意义是什么？如果没有独立前端团队、没有多端复用需求，硬上Vue+Spring 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

我把支付时间、发货时间、收货时间都作为独立字段记录，而不只是用一个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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里的product_name和product_image是故意冗余的。如果哪天商品下架或者改名了，订单详情里依然保留用户当时购买的真实信息，这在电商系统中叫“数据快照”，是做订单系统的基本功。

4.3 表关联与外键取舍

我所有表都没有使用物理外键，而是依靠逻辑外键——在代码中维护关联关系。为什么？一是物理外键会拖慢大批量插入和删除的性能，二是分库分表时物理外键会变成大麻烦。很多实际开发项目都约定不用物理外键，这个问题面试时也会被问到，你答上来会加分。逻辑外键怎么保证数据一致性？在Service层做好事务管理，该锁的锁、该查的查，完全可控。

4.4 索引优化实战

索引这块我做了两个关键优化。第一个是订单表的user_id索引，因为“我的订单”页面高频根据用户ID查询；第二个是商品表的category_id和status联合索引，因为商品列表页高频按分类和上下架状态筛选。用EXPLAIN测过，走索引后查询耗时从几十毫秒降到了个位数毫秒，这种优化虽然简单，但如果你在博客或者答辩文档里写出来，显得很懂数据库调优。

5. 核心业务代码实现与关键细节剖析

进入真正的代码环节。我不打算把所有代码贴上来，那样太长也没意义。我挑几个最有技术含量、也最容易被问到的业务点做深度拆解。

5.1 商品动态条件查询与分页

蛋糕列表页通常可以按分类、关键字、价格区间、排序方式来筛选。我使用了MyBatis的动态SQL来实现这个多条件的组合查询：

<select id="selectProductList" resultType="com.yuantang.entity.Product"> SELECT * FROM product <where> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> AND status = 1 </where> <choose> <when test="sort == 'sales'"> ORDER BY sales DESC </when> <when test="sort == 'price_asc'"> ORDER BY price ASC </when> <otherwise> ORDER BY create_time DESC </otherwise> </choose> </select>

<where>标签会自动处理条件拼接时多余的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. 遍历购物车选中的商品，计算总价 List<Cart> checkedCarts = cartMapper.selectCheckedByUserId(userId); BigDecimal totalPrice = BigDecimal.ZERO; List<OrderItem> 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 商品列表的数据渲染与价格展示

商品列表页面我用JSTL+EL表达式在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 环境准备清单

工欲善其事必先利其器，基础环境先准备齐：

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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver

注意serverTimezone=Asia/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}" pattern="yyyy-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-path=D:/cake_shop_upload/），后续部署到Linux服务器时只改一处配置就行。

8.4 事务不生效的诡异场景

背景：下单接口出现了订单部分成功、部分失败的情况，数据库里能看到订单主表有记录但订单详情表记录缺失。

原因分析：排查发现我调用下单的入口是Controller直接调Service，但Service内部又通过this.createOrder()调用了另一个带@Transactional的私有方法。this调用不会经过Spring的代理对象，导致事务注解失效。

解决方案：把所有事务方法放到Service接口中，通过注入的代理对象来调用。或者把事务切面直接加到Controller调用的那个方法上。

注意，这个问题不只在Spring Boot中常见，在所有基于动态代理的事务控制中都是经典坑。

8.5 常见问题速查表

8.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对比了优化前后的执行计划：

提升是很明显的，而且我只是加了两三个索引。如果你在论文里写清楚“为什么加这个索引、如何用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开发的整个思考链路。