企业官网建设流程全解析

一个用了两年的毕设题目，我为什么还推荐它

每年带毕设，或者在各个技术群里看大家问选题，翻来覆去都是那些经典题目：学生管理系统、图书馆管理系统、校园二手交易平台……不能说不好，但实在没什么新意。今天聊的这个题目——基于Spring Boot的生日蛋糕订购商城的设计与实现，第一次看到时我也没太当回事，但真正完整跟下来之后，我得说：这其实是一个非常聪明的毕设选题。

先讲清楚它能做什么。一个典型的蛋糕订购商城，核心是让用户在线浏览蛋糕、按分类筛选、加入购物车、下订单、在线支付（或者货到付款），同时后台管理端可以管理蛋糕信息、分类、订单状态、用户信息等等。技术上以Spring Boot作为后端框架，搭配MySQL存储数据，前端可以选模板引擎（如Thymeleaf）渲染页面，也可以拆成前后端分离的模式。数据库层面涉及用户表、蛋糕表、分类表、购物车表、订单表、订单项表等多个实体，彼此之间有清晰的外键关联和业务逻辑。整个流程从前端页面交互、到后端接口处理、再到数据库读写，是一条非常完整的链路。

如果你正在纠结毕设选题、或者已经选了类似商城项目但还没有完整思路，这篇文章会把整个项目从设计到实现到答辩的细节都拆给你看，争取让你少走一些弯路。

1. 选题思路：为什么是“生日蛋糕订购商城”而不是别的

1.1 这个题目的合理性分析

很多人选毕设题目的时候陷入一个误区：要么选一个自己完全hold不住的高大上题目（比如“基于深度学习的XXX推荐系统”），要么选一个几乎没有技术含量的增删改查（比如“宿舍管理系统”）。前者容易做不完导致延期，后者评阅老师一眼看过去就觉得没难度，答辩不好过。

生日蛋糕订购商城这个题目，恰好卡在一个非常合适的位置。从业务侧来说，它属于电商领域，是计算机应用型专业非常经典且通用的业务场景，老师容易理解、不用花时间解释需求。从技术侧来说，它覆盖了Web开发的主要环节：用户注册登录、商品的增删改查、购物车、订单流转、文件上传等。这些功能既有业务复杂度，又不会难到需要分布式架构去解决，非常适合一名本科生的能力范围。

我特别喜欢这个题目的一个原因是它的业务故事足够完整。蛋糕和普通商品不一样，它有款式、口味、尺寸（磅数）、配送日期等特殊属性，这让它比“图书商城”“3C商城”多了一层业务趣味：下单时要选规格、要填期望送达时间、标注蛋糕上的祝福语。这些细节让学生在设计数据库表和写业务逻辑的时候，有更多可以发挥的地方，而不是简单地抄一套通用商城模板。

1.2 需求边界：如何避免范围失控

毕设和商业项目最大的区别是：毕设需要的是“够用且完整”，而不是“大而全”。我见过不少同学一开始意气风发，想着在商城里面加优惠券、加秒杀、加积分、加直播带货……最后连核心功能都没做好。

我个人经验，建议把需求规模控制在一个能够独立完成并留出充足调试时间的量级。核心功能锁定在：

• 前台用户端：注册登录、蛋糕浏览（按分类筛选）、蛋糕详情、购物车、订单提交与支付模拟、个人订单管理、个人资料维护。
• 后台管理端：管理员登录、蛋糕信息管理、分类管理、订单管理（发货/完成等状态流转）、用户管理。

这里要注意一个取舍点：支付功能。如果是商业项目，支付一般对接支付宝/微信支付SDK。但在毕设场景下，很多同学没有企业资质，申请不了支付接口，所以最常见的方式是“模拟支付”——下单后跳到支付页面，点击“确认支付”就算支付成功，或者直接选择“货到付款”。这完全不影响项目的完整度，论文里说明清楚即可。如果你确实想用真实支付，可以尝试支付宝沙箱环境，但这会额外增加不少工作量，答辩加分有限，我不太建议在毕设阶段给自己加这个负担。

2. 技术选型：Spring Boot 生态怎么搭配才稳

2.1 核心框架选型：为什么是Spring Boot而不是SSH或SSM

现在仍然有不少教材和学校课程在教SSM（Spring + Spring MVC + MyBatis），但如果你关注过招聘市场或者技术社区，就会知道Spring Boot 已经成为Java Web开发的绝对主流。选Spring Boot做毕设，短期是为了毕业，长期是为了让简历上的技术栈不落后。

Spring Boot对Spring MVC、MyBatis等框架做了大量的自动配置，起步依赖可以把框架整合的成本降得非常低。最典型的例子，SSM时代你要写web.xml、要配spring-mvc.xml、要配数据源、要配事务管理器，里面任何一个环节出错，项目都跑不起来。而Spring Boot里面，一个启动类加上几条application.properties配置，项目就能跑。这样省下的时间可以让同学聚焦在业务代码上，而不是和框架配置死磕。

具体版本选择，我再提醒一句：不要一味追求最新版本。Spring Boot 2.x系列目前是最稳妥的选择，3.x虽然已经发布，但部分第三方依赖的兼容性还需要时间沉淀，尤其是你之后要在网上找资料、找解决办法时，2.x相关的坑基本都被踩平了，一搜就有答案。做毕设，稳定性大于先进性。

2.2 数据库与ORM：MySQL + MyBatis-Plus的组合拳

数据库没有太多悬念，MySQL是绝大多数Java毕设的首选。免费、跨平台、相关资料极多，学校机房或者你自己电脑装一个5.7或8.0版本即可。

ORM框架这块，我强烈推荐MyBatis-Plus。原因很简单：它是在MyBatis基础上做了增强的国产框架，把单表CRUD的通用方法直接封装好了，你不需要为每一个实体类写一堆重复的Mapper方法。比如蛋糕表的基本增删改查，MyBatis-Plus内置的BaseMapper已经提供了insert、deleteById、selectById、selectPage等方法，直接用就行。复杂一点的多表查询、订单统计类需求，你自己写SQL也没有问题，它和MyBatis完全兼容。

举个例子，你要做蛋糕列表的分页查询，只需要：

Page<Cake> page = new Page<>(current, size); LambdaQueryWrapper<Cake> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Cake::getCategoryId, categoryId); wrapper.orderByDesc(Cake::getCreateTime); cakeMapper.selectPage(page, wrapper);

不需要自己拼接LIMIT，不需要写count查询，MyBatis-Plus会帮你处理好。这一行代码放在面试里拿出来讲，也能说明你了解现代开发中“少写重复代码”的理念。

2.3 认证方案：JWT还是Session

用户登录认证是每个Web项目都绕不开的问题，毕设里也是一样。两种主流方案，我分别说下使用场景。

Session方案是传统方案：用户登录成功后，后端把用户信息存到HttpSession中，后续请求通过sessionId（一般存在Cookie里）识别用户身份。优点是好理解，写起来简单，答辩时也容易讲清楚；缺点是前后端分离时处理跨域会比较麻烦，而且服务端需要保存会话状态。

JWT（JSON Web Token）方案是当前前后端分离项目的主流：用户登录成功后，后端签发一个包含用户信息的加密Token返回给前端，前端每次请求时把这个Token放在请求头里。服务端不需要保存会话状态，天然支持分布式环境。对于应届生来说，在项目里用了JWT，简历上可以写一条“基于JWT的无状态认证”，面试官通常会比较认可。

个人建议：如果你打算做前后端分离版的商城（前端用Vue），直接用JWT。如果做服务端渲染版（Thymeleaf），用Session更简单直接。不要在两个方案之间反复横跳，选定一种就坚持到底。

我用过的一个稳定组合是Spring Boot + Sa-Token框架。如果觉得从零实现JWT的加密解密太麻烦，Sa-Token提供了非常简洁的API，几行代码就能完成登录认证和权限校验，底层是Token机制，论文里也好解释。第一次用Sa-Token的时候确实有被惊艳到，它把所有会话、权限、踢人下线的功能都封装好了，写起来极度舒适。当然，如果你希望论文里的技术难点更“重”一些，自己用jjwt库实现JWT工具类也完全可以，难度可控。

2.4 哪些“热门组件”其实可以不加

这两年的大数据、微服务概念很火，有些同学想在毕设里塞入Redis缓存、RabbitMQ消息队列、Nacos注册中心……我劝你冷静。

微服务架构不是不好，但它是为复杂业务场景准备的。一个蛋糕商城，单机Spring Boot足以支撑数百人并发访问，强行拆成微服务，意味着你要额外处理服务发现、配置中心、分布式事务等一系列问题。这些问题每一个都能消耗你大量时间，而答辩时老师可能还会追问：“你这个场景里拆微服务的必要性体现在哪里？”你如果答不上来，反而会扣分。

Redis缓存倒是一个可以考虑的加分项。把蛋糕分类、热门蛋糕列表这些读多写少的数据缓存到Redis里，能明显提升访问速度，技术上也不算难，只需要引入spring-boot-starter-data-redis依赖，在你需要缓存的方法上加上@Cacheable注解即可。但这属于“锦上添花”的功能，核心业务完成之后有余力再做，不要一开始就这样设计增加复杂度。

3. 系统设计与数据库建模：先把地基打好

3.1 功能模块：前台用户端和后台管理端如何划分

系统设计的第一步，是把用户角色理清楚。生日蛋糕订购商城的用户角色可以分成两类。

前台用户（顾客）：通过网站浏览蛋糕、搜索、查看详情、加入购物车、提交订单、管理个人信息。这个角色的核心操作链路是“浏览-加购-下单”，你要保证这条链路畅通无阻，每一步都有清晰的前端页面和后端接口支撑。

后台管理员：登录后台管理页面，维护蛋糕分类、发布和编辑蛋糕信息、管理库存、处理订单（比如将订单状态从“已支付”更新为“制作中”再到“配送中”和“已完成”）、查看用户列表等。

从工程结构上说，不建议把两套功能的代码混在一起。我习惯的做法是：

com.example.cake ├── controller │ ├── admin # 后台接口 │ └── user # 前台接口 ├── service │ ├── admin │ └── user ├── mapper ├── entity ├── vo ├── utils └── config

后台接口路径统一加上/admin前缀，例如/admin/cake/list、/admin/order/updateStatus，并在拦截器或过滤器中校验管理员身份。前台接口保持简洁路径，例如/api/cake/list。这样接口清晰，也方便后续写权限控制。

3.2 核心数据表：从用户表到订单表的设计思路

数据库设计是整个项目的地基。蛋糕商城至少需要这几张表：用户表、蛋糕分类表、蛋糕信息表、购物车表、订单表、订单项表，以及可选的轮播图表（用于首页展示广告图）。

各表的核心字段设计如下。

用户表（user）：id、username、password、nickname、phone、avatar、role（区分管理员与普通用户，0为普通用户，1为管理员）、status（账号状态）、create_time、update_time。

蛋糕分类表（category）：id、name、sort（排序权重）、create_time。

蛋糕信息表（cake）：id、category_id、name、description、price（价格）、image（蛋糕主图的URL）、stock（库存）、sales（销量）、flavor（口味）、sizes（可选规格，如1磅/2磅/3磅）、create_time、update_time。注意：如果支持规格选择，可以另建一张cate_spec表存放不同尺寸对应的价格，但如果毕设篇幅有限，直接在蛋糕表里用字符串字段存储规格JSON结构或“1磅/2磅”文本，也是可行的简化方案。

购物车表（cart）：id、user_id、cake_id、quantity、selected（是否勾选，方便前端做勾选结算）、create_time。

订单表（orders）：id、order_no（订单编号）、user_id、total_amount、pay_type（支付方式：1在线支付，2货到付款）、status（订单状态：0待支付、1已支付待制作、2制作中、3配送中、4已完成、5已取消）、receiver_name、receiver_phone、receiver_address、remark（备注，比如蛋糕祝福语）、create_time、update_time。

订单项表（order_item）：id、order_id、cake_id、cake_name（快照）、cake_image、price（购买时的单价）、quantity。

这里有个很多新手容易忽略的关键点：为什么订单项表里要冗余存cake_name和cake_image？因为蛋糕的名称、图片、价格都是会变的数据，如果管理员修改了蛋糕信息，历史订单里如果只存cake_id，再展示订单时就会显示错误。冗余快照是电商系统里的常规操作，让每个订单项在生成时就“冻结”了当时的商品信息。这个细节在论文里写上一句话，老师会觉得你考虑到了数据一致性的问题。

3.3 表关系与外键约束

上述表之间的关系非常清晰：

• 蛋糕表和分类表是“多对一”，一个分类下可以有多个蛋糕。
• 购物车表和用户表、蛋糕表之间是“多对一”。
• 订单表和用户表是“多对一”，订单项表和订单表是“一对多”。

推荐在数据库层面建立逻辑外键（即不物理创建FOREIGN KEY约束，而是通过查询时手动关联），这样做的原因是：很多业务系统为了保证性能和数据操作自由，会避免物理外键带来的插入更新约束。在论文答辩时，你只需要说明“出于性能考虑，表的关联关系由应用层SQL维护”即可。如果你们学校老师比较传统、要求必须建外键，你也可以加物理外键，这对毕设规模来说并没有明显影响。

建表的SQL就不贴完整版了，网上模板很多，重点是你自己动手设计一遍字段，弄清楚每个字段存在的意义。这个环节理解透彻了，后面对接前端和写业务代码会顺畅得多。

4. 核心功能实现拆解：从商品展示到订单流转

4.1 蛋糕列表与分类筛选：最基础也最容易出彩

蛋糕列表页是用户进入商城后看到的第一屏，第一印象很重要。常见的展示方案是：顶部轮播图，下面按分类展示蛋糕卡片，每张卡片包含蛋糕图片、名称、价格、销量。

前端页面通过请求后端接口获取数据，后端接口设计如下：

@GetMapping("/api/cake/list") public Result<PageResult<CakeVO>> list( @RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "8") Integer size, @RequestParam(required = false) Integer categoryId, @RequestParam(required = false) String keyword) { Page<Cake> cakePage = cakeService.pageCakes(page, size, categoryId, keyword); return Result.success(convertToVO(cakePage)); }

这里需要注意的一个设计细节是返回给前端的数据结构。不要把数据库实体Cake直接返回给前端，而是定义一个CakeVO（View Object，视图对象），只包含前端需要展示的字段，比如去掉createTime、stock这类前端不需要或不想暴露的字段。这样做一方面是安全考虑（比如不要返回密码字段），另一方面是语义更清晰。这个习惯从毕设就开始养成，对你以后进企业做开发帮助很大。

另一个容易被忽略的细节是图片URL的存法。数据库里不要存完整的http://localhost:8080/xxx.jpg，只存相对路径/upload/xxx.jpg，前端展示时用Vue的过滤器或者Thymeleaf的表达式拼上服务器地址即可。这样做的好处是项目迁移时不需要改数据库里的图片地址，灵活得多。

4.2 购物车实现：后端存储还是前端存储

有些商城项目会把购物车数据存在浏览器本地（LocalStorage），这样不需要登录也能加购，体验确实好一些。但从毕设的角度，我建议后端存储方案，即用户登录后把购物车数据存入数据库cart表。

理由有三点：

第一，后端存储能把购物车和订单流程打通，逻辑更加完整。第二，答辩时老师会重点考察你数据库设计的合理性，购物车表会是一个加分点。第三，用户换设备或者清浏览器缓存时购物车不会丢，体验更符合用户的预期。

购物车的核心接口有四个：加入购物车、修改数量、选中/取消选中某个商品、删除购物车条目。实现购物车功能时，要注意一个细节：同一个用户把同一个蛋糕第二次加入购物车时，不应该插入新记录，而是把原有记录的数量加一。这个判断逻辑用LambdaQueryWrapper实现非常简洁：

Cart cart = cartMapper.selectOne(new LambdaQueryWrapper<Cart>() .eq(Cart::getUserId, userId) .eq(Cart::getCakeId, cakeId)); if (cart != null) { cart.setQuantity(cart.getQuantity() + quantity); cartMapper.updateById(cart); } else { Cart newCart = new Cart(); newCart.setUserId(userId); newCart.setCakeId(cakeId); newCart.setQuantity(quantity); cartMapper.insert(newCart); }

4.3 订单流程：状态机思维是关键

订单模块是整个项目中业务逻辑最复杂的部分，也是答辩时老师最可能深挖的模块。

订单的创建流程大概是这样的：

前端从购物车中勾选若干商品，点击“结算”，传递商品ID列表和数量。后端收到请求后执行以下几个步骤：

第一步，从购物车中查出本次要结算的商品明细，校验商品是否存在、库存是否充足。

第二步，计算总金额。注意：商品单价必须以数据库中的实时价格为准，不能信任前端传过来的价格，否则用户可以改价格。这是个非常重要的安全原则，我给学生带毕设时一定会强调这一点。

第三步，生成订单主记录。订单编号需要保证唯一，常见的生成方式是日期时间戳加随机数，例如：

String orderNo = "CK" + System.currentTimeMillis() + RandomUtil.randomNumbers(4);

也可以用UUID，但订单号一般是给用户看的，纯数字或字母数字组合的形式可读性更好。

第四步，将购物车中的商品逐条生成订单项记录，写入order_item表。

第五步，清空购物车中对应商品。

第六步，返回订单ID和订单编号，前端跳转到支付页面。

订单状态管理是另一个重点。我强烈建议用状态机的思路来设计订单状态流转，并为每一种合法状态迁移定义明确的“操作”。简单画一下状态迁移关系：

• 待支付 → 已支付（用户点确认支付）
• 待支付 → 已取消（用户取消订单）
• 已支付 → 制作中（管理员确认开始制作）
• 制作中 → 配送中（管理员点击发货）
• 配送中 → 已完成（管理员确认送达）
• 已支付 → 退款中 → 已退款（用户申请退款，管理员同意）

在代码里，不要直接用“1改成2”这种裸的update操作。我建议把状态更新封装成独立业务方法，在方法内部判断当前状态能否迁移到目标状态，状态非法时直接抛异常。

public void updateOrderStatus(Long orderId, Integer targetStatus) { Order order = orderMapper.selectById(orderId); Integer currentStatus = order.getStatus(); if (!canTransit(currentStatus, targetStatus)) { throw new BizException("非法状态转换：从 " + currentStatus + " 到 " + targetStatus); } order.setStatus(targetStatus); orderMapper.updateById(order); }

这种方式的核心价值在于：它让业务逻辑不会因为状态分支太多而变得混乱，排查问题时也能快速定位是哪一步出了问题。毕设代码里能够体现这种设计思想，绝对是一件加分的事。

4.4 文件上传：蛋糕图片管理的实现

蛋糕商城里管理员需要上传蛋糕图片，这就涉及文件上传功能。Spring Boot实现文件上传非常简单，核心在配置和路径管理。

首先在application.yml中配置上传大小限制，不然默认1MB的限制会让你传大图时反复报错：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

上传接口的写法：

@PostMapping("/admin/cake/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("请选择文件"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID() + ext; String datePath = LocalDate.now().toString(); File dir = new File(UPLOAD_DIR + "/" + datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath() + "/" + fileName)); return Result.success("/upload/" + datePath + "/" + fileName); }

两个细节值得注意：重命名文件时用UUID或者其他随机字符串，不要直接用用户上传的原始文件名，既避免中文文件名乱码，也避免文件名冲突；再一个是按日期分子目录存储图片，文件多时不会全挤在一个文件夹里，后期维护也方便。

图片上传之后，还需要一个静态资源映射配置，让前端能通过URL访问到上传目录中的图片：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadDir + "/"); } }

不要小看这个配置，我在帮学生调试项目时，最常见的问题之一就是图片上传成功了，但前端页面死活显示不出来。一查，静态资源映射没配，或者路径配置错了。这个坑几乎每个人都踩过，你看到这篇文章，可以先把这个点标记在心里。

4.5 管理后台：让用户端和管理端共用一套认证体系

管理后台的设计不需要做得多花哨，但功能要完整。最核心的是权限控制——只有管理员才能访问后台接口。

实现方式上，我举一个JWT风格的方案。用户登录时，后端签发Token时会在Token中带上用户的角色信息。定义一个拦截器，拦截所有/admin开头的接口，从请求头中解析Token、获取用户角色，如果不是管理员则直接返回“无权限访问”。具体代码如下：

public class AdminInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); // 解析token，校验登录状态 // 校验角色是否为管理员 // 失败则响应401或403 return true; } }

使用Session方案也可以用类似思路，只是把Token换成从Session中取用户对象。代码逻辑大同小异。

管理端的页面一般包括：仪表盘（展示订单总数、销售额、待处理订单数）、蛋糕列表页（可以新增/编辑蛋糕）、分类管理页、订单处理页、用户列表页。页面风格求稳，用AdminLTE或者普通的Bootstrap后台模板都行，不用在样式上花太多时间。

5. 实际操作中遇到的坑与调试经验

5.1 版本兼容问题：JDK、Spring Boot、MyBatis-Plus的搭配

版本问题是Java开发中最烦人的问题，没有之一。给学生调试项目时，最常见的一句话是：“老师，我这里启动项目报错了，你帮我看看。”

我建议的稳定组合是：JDK 1.8或JDK 17、Spring Boot 2.7.x、MyBatis-Plus 3.5.x。这个组合经过了大量项目的验证，踩坑的人最多，意味着网上的解决方案也最多。

如果用了JDK 9以上版本，要注意JAXB相关依赖缺失的问题。Spring Boot 2.x在JDK 9以上环境下，可能因为缺少JAXB API而启动失败，解决方案是在pom.xml中添加javax.xml.bind相关依赖。这个坑在新手项目中频繁出现，排查到之后加一行依赖就能解决。

另外，尽量不要用Spring Boot 3.x搭配MyBatis-Plus旧版本，因为Spring Boot 3基于Jakarta命名空间，旧版MyBatis-Plus里的javax.*坐标会直接报ClassNotFoundException。如果你已经在用Spring Boot 3，MyBatis-Plus需要升级到3.5.3以上版本。这些版本搭配的知识，写论文时也可以作为技术选型说明的一部分，显得你的研究更扎实。

5.2 启动失败：端口被占用、数据库连接失败

每次帮学生排查启动问题，百分之六十都是两个原因：端口被占或者数据库连不上。

端口占用的问题，在application.yml里改掉server.port即可，比如改用8081、8082。但如果你的前端代码里写死了请求端口，改了后端端口记得同步改前端。用Vue开发时一般用代理解决跨域，改端口后也要同步代理配置。

数据库连接失败，首先要检查MySQL服务是否启动了。Windows上按Win+R输入services.msc，找到MySQL服务，确认状态是“正在运行”。其次检查数据库名、用户名、密码是否和连接串一致。这里我建议在application.yml中加上这些配置：

spring: datasource: url: jdbc:mysql://localhost:3306/cake_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver

useSSL=false和serverTimezone=Asia/Shanghai这两个参数，一个是为了避免SSL握手警告，一个是为了避免时区问题导致时间显示不正确。我可以很负责任地说，不配serverTimezone，查询出来的日期时间和你本机时间大概率对不上。

5.3 开发调试技巧：善用日志与断点

毕设项目的调试过程，几乎决定了你能不能在截止日期前顺利交付。很多同学遇到Bug，第一反应是在代码里到处加System.out.println，然后启动项目一顿打印。这个方法不是不行，但效率太低。

更好的方式是使用日志。Spring Boot默认集成了Logback日志框架，你可以在application.yml中配置日志输出级别和格式：

logging: level: com.example.cake: debug file: name: logs/app.log

把包名下的日志级别调成debug后，MyBatis-Plus执行的SQL日志、Spring MVC的路径匹配日志都会打印出来，很多问题一眼就能看出来。比如SQL语句写错、查询参数没传进去，日志里都会有线索提示。

如果你的编译环境使用IDEA，调试时优先用断点而不是打印日志。在关键业务方法那行打断点，启动Debug模式，查看变量值的变化、执行到哪一步出了问题，效率是System.out.println的十倍。尤其在排查订单状态流转这种多步骤业务时，断点跟一次，整个逻辑都在脑子里了。

5.4 前端联调阶段的典型问题

我用过的做法是，如果怕麻烦，后端用Thymeleaf做服务端渲染，前端和后端在一起，部署也方便。但如果选择前后端分离（前端用Vue），联调阶段有两个高频问题值得提前了解。

第一是跨域问题。前端跑在localhost:8080，后端跑在localhost:8081，前后端端口不同，浏览器就会阻止跨域请求。解决方案有两种，一种是在后端加CORS跨域配置，一种是前端通过Proxy代理转发请求。我推荐前端代理方案，配置简单且生产环境部署时不需要后端额外处理跨域：

// vite.config.js export default { server: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } }

这样前端页面里所有请求路径都写成/api/cake/list，开发时Vite会代理转发到后端接口。这种方式的好处是前端代码里没有写死后端地址，之后打包后部署到同一域下时不需要改代码。

第二是前后端字段不一致的问题。后端的字段命名风格一般是驼峰命名（如createTime），前端的JavaScript变量习惯建议保持一致，不要在接口层做无意义的字段转换。用JSON交互时，后端Java对象转成JSON，字段名默认和属性名一致，如果后端返回了null字段，前端取的时候要留意空值判断，不然页面渲染直接报错或者显示undefined。

6. 源码使用与部署上线：拿到手之后怎么办

6.1 拿到项目源码后：从运行到调试的完整流程

现在很多同学会从网上下载毕设源码，但拿到手之后的步骤很多人搞不清。你拿到一套Spring Boot蛋糕商城源码后，正确的打开流程应该是这样：

先看README文件。规范的源码项目都有README，里面说明了JDK版本、MySQL版本、Tomcat配置、数据库初始化脚本位置、默认账号密码等关键信息。看完README，能让你的启动过程顺畅很多。

创建一个数据库，执行项目里的sql脚本。有些项目把建表语句放在schema.sql或init.sql中，有些则要求你手动执行。不要跳过建表步骤，直接在空数据库上启动项目，百分之百会报Table not found。

修改application.yml中的数据源配置，改成你自己的MySQL用户名和密码。如果你的MySQL版本是8.0以上，驱动类用com.mysql.cj.jdbc.Driver（Spring Boot 2.7默认就是它），如果你用5.7，通常也兼容。

启动项目。正常情况下，控制台会打印出Spring Boot的启动横幅和Tomcat started on port(s): 8080的日志。这时候启动成功了，访问http://localhost:8080就能看到商城首页。

登录后台。不同项目的默认管理员账号不同，通常在初始化脚本里指定，常见的是admin/admin123。如果登录失败，去数据库user表里查一下，直接用SQL把角色字段改成管理员即可。

6.2 论文结构：怎么把项目写成一份能过审的文档

源码搞定了，论文也逃不掉。关于毕设论文，我只有一个核心建议：不要直接套模板抄，而是要理解你写的每一章在讲什么。

一篇典型的Java毕设论文结构大致如下：

• 第一章绪论：写选题背景、意义、国内外研究现状。研究现状不要太宏大，围绕“商城系统”“电子商务平台”这个领域说两句即可。注意不要大篇幅抄互联网上的内容，查重是硬指标。
• 第二章相关技术介绍：写Spring Boot、MySQL、MyBatis-Plus（或MyBatis）、前端框架等。这一章要讲清楚这些技术的特点、为什么选用它们，不要只是贴官网介绍。
• 第三章系统分析：写可行性分析、需求分析、功能结构图。画图建议用Visio或draw.io，结构清晰即可。
• 第四章系统设计：写总体架构设计、功能模块设计、数据库设计（ER图、数据表结构）。这是论文的核心章节，篇幅占比最大。
• 第五章系统实现：贴关键代码，配功能截图，每个功能模块写清楚实现逻辑。
• 第六章系统测试：写测试方法、测试用例表、测试结果。用黑盒测试思路，列出几个功能点的测试用例和结果即可。
• 第七章总结与展望：总结项目做了什么，有哪些不足，未来可改进方向。

如果你已经有一份源码，建议按上面这个骨架来组织你的论文，每一个章节去对应代码中的实际实现，这样查重和答辩都不会有大问题。

6.3 答辩准备：老师最喜欢问的几个点

答辩PPT不需要做得特别炫酷，条理清晰才是最关键的。从拿到源码到自己亲自动手跑通、改代码，整个过程的熟练度会直接决定你答辩的状态。我总结一下老师高频提问的几个角度：

第一个，为什么选这个选题？这个问题考察你对项目的理解。回答思路：该选题属于电商领域经典场景，能完整覆盖Web开发核心知识体系，同时生日蛋糕的商品属性让业务逻辑有特色，所以选了它。

第二个，用户登录如何使用JWT做验证？你要能说出Token生成、前端存储、请求头携带、后端校验整条链路。如果项目中用的Session，就要把Session的存储原理讲清楚。

第三个，购物车是怎么实现的？要能讲清楚表结构、加购逻辑（同一商品数量累加）、结算逻辑。这是把你和只会复制粘贴的同学区分开来的关键问题。

第四个，如果用户同时下单同一件商品，库存扣减怎么处理？这个问题的完美回答思路是：先判断库存充足，再执行扣减操作，并在SQL语句中加上库存条件：

int updated = cakeMapper.updateStock(cakeId, quantity); // UPDATE cake SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity} if (updated == 0) { throw new BizException("库存不足"); }

这种名为“乐观锁思路”的写法，比先查库存再扣库存更安全。能答出这个思路，老师对你的技术深度会有明显加分。

第五个，系统有哪些不足？不要回答说“没有不足”，任何人都有提升空间。你可以说“当前支付流程是模拟支付，后续可以对接真实支付网关”“会员体系尚未实现，后续可通过积分增加用户粘性”。诚实指出不足并说出改进方向，比说自己项目完美无缺更让老师信服。

7. 从毕设到工作：这个项目还能怎么延续

说一个真实体会。我带过的学生里，有几个做的商城毕设，毕业入职后第一年就在公司负责了订单模块的维护。他们回头看自己毕设代码，一边吐槽当时写得真糙，一边也承认了这个毕设打下的基础确实管用。这就是选对题目的价值：不是为了应付毕业，而是让你在毕业前完整地经历一遍“设计-开发-测试-部署-答辩”的软件生命周期。

如果你学有余力，拿到这套蛋糕商城后，可以从这几个方向继续扩展：引入Redis缓存热门数据、用Vue3重构前端、增加订单导出Excel功能、部署到云服务器上线运行。任何一项做好了，简历上都能多写一条亮点。

最后再分享一个我在调试这个项目时踩过的小坑：订单编号用的时间戳加随机数，某次测试时想到排查问题，发现日志里的订单号看不清是哪一天的。后来我把订单号格式调整为CKyyyyMMddHHmmss加四位随机数，比如CK202412151430121234，问题就解决了。这种小经验看起来不起眼，但能让你在写代码和调试时都舒服得多。

希望这篇内容对正在做毕设或者准备选毕设题目的你有一些帮助。等你的蛋糕商城顺利上线跑通，再回头看看当初纠结的选题和折腾过的Bug，那些都是大学四年里值得记住的时刻。