本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：专为计算机专业学生准备的毕业设计级蛋糕在线选购系统，基于SpringBoot 2.x构建，后端用Java开发，数据库采用MySQL，配套完整建库脚本cake_mall.sql，导入即可生成分类、商品、用户、订单等全部测试数据。系统包含前后端一体化功能：用户端支持浏览蛋糕列表、按分类筛选、加入购物车、提交模拟订单；后台提供商品增删改查、订单状态管理、基础用户信息维护。技术栈清晰明确——MyBatis-Plus封装数据库操作，Thymeleaf渲染HTML页面，所有配置已标准化，pom.xml依赖齐全，项目结构符合Maven规范，含src源码、resources配置、static静态资源及templates模板目录。支持IDEA直接导入，无需额外配置，可一键以内置Tomcat启动，也可部署到本地独立Tomcat服务器。适合学习SpringBoot分层开发（Controller/Service/Mapper）、RESTful接口编写、MySQL表设计与CRUD实践、电商类业务流程梳理，以及从零搭建JavaWeb项目的完整流程。

1. 这不是“又一个Demo”，而是一套能跑通电商闭环的毕业设计实战样本

你是不是也经历过：翻遍GitHub，下载十几个“SpringBoot商城”项目，解压打开——要么缺数据库脚本，要么报ClassNotFoundException，要么Thymeleaf模板路径404，要么登录接口返回500 Internal Server Error却连日志都找不到在哪看？最后只能硬着头皮自己从零搭框架，结果毕设答辩前一周还在调MyBatis的resultMap嵌套查询……我带过三届计算机专业毕业设计，每年都有至少12个学生卡在“系统跑不起来”这一步。他们缺的从来不是理论，而是一套真正‘开箱即用、错一步都能立刻定位’的完整参照系。

这套“蛋糕商城系统”就是为解决这个问题而生的。它不追求高并发、不堆微服务、不搞分布式事务，但每一条业务线都真实走通：用户从首页看到草莓千层，点击进入详情页，加入购物车（此时库存实时扣减），去结算页填写收货信息，点击“提交订单”后，后台管理端立刻能看到一条待处理订单，管理员点“发货”，订单状态自动更新，用户端刷新页面就能看到物流状态变化。整个流程里，没有一行代码是“为了演示而写”的假逻辑——购物车加减商品会校验库存上限，下单前会检查用户是否已登录并验证地址完整性，后台删除商品时会级联清除关联的购物车记录和历史订单项。这些细节，恰恰是答辩老师最常追问的“你这个功能是怎么保证数据一致性的？”的底气来源。

关键词里的“SpringBoot蛋糕系统”不是噱头——选“蛋糕”而非“图书”或“数码”，是因为品类天然具备强属性：口味、尺寸、奶油类型、是否可定制，这些字段能自然引出多表关联（如cake主表 + cake_flavor口味中间表 + custom_option定制选项表），比单纯“图书-作者-出版社”更能训练数据库设计思维；“Java毕业设计”意味着它规避了所有生产环境才需要的复杂组件（Redis缓存、RabbitMQ消息队列、Elasticsearch搜索），把精力聚焦在SpringBoot核心能力上：@Transactional事务控制怎么写才不漏掉异常回滚？@Valid校验注解如何与自定义错误提示联动？ResponseEntity封装统一返回格式时，如何让前端不用反复判断data字段是否存在？这些，才是本科生该扎实掌握的硬功夫。而“MySQL电商源码”则直指要害——配套的cake_mall.sql不是简单建几张表，它包含12张精心设计的表：从基础的user、product，到业务关键的shopping_cart_item（带is_checked标记实现购物车多选结算）、order_item（冗余商品快照防止下架后订单信息丢失）、admin_log（记录后台操作便于答辩时展示权限控制）。导入脚本后，你得到的不是一个空壳，而是一个有3类管理员、5个真实用户、28款蛋糕（含6种口味组合）、17笔已完成订单的“活系统”。这意味着，你不需要花三天时间伪造测试数据，打开浏览器就能直接点进后台，看到订单列表里那条ID为ORD20240517001的状态正从“待付款”变成“已发货”——这种即时反馈，对建立学习信心太重要了。

2. 系统整体架构与技术选型逻辑拆解：为什么是这套组合，而不是其他？

2.1 不选SpringCloud、不碰Docker：回归教学本质的克制选择

很多同学一上来就想搞“高大上”，看到网上教程讲SpringCloud就热血沸腾，觉得毕设不加个Eureka注册中心都不好意思答辩。但现实是：SpringCloud引入Nacos配置中心后，光是bootstrap.yml和application.yml的加载顺序就能让你debug两天；Docker部署时遇到port already in use，查到最后发现是Windows子系统WSL2的网络模式冲突。这套蛋糕系统刻意保持单体架构，原因很实在——毕业设计的核心目标不是证明你会搭分布式，而是证明你理解分层架构中每一层的职责边界。Controller只做请求路由和参数校验，Service层专注业务规则（比如“同一用户24小时内不能重复提交相同商品订单”），Mapper层严格遵循单一职责（ProductMapper只管商品CRUD，OrderMapper只管订单流转）。当你在IDEA里右键点击一个@Service类，选择“Find Usages”，看到所有调用链清晰落在Controller和Test包里，你就真正理解了“控制反转”的落地形态。这种结构化思维，远比在简历上写“熟悉SpringCloud”更有说服力。

2.2 MyBatis-Plus替代原生MyBatis：效率与教学的双重胜利

为什么用MyBatis-Plus而不是JPA？这里有个关键教学陷阱：JPA的@OneToMany懒加载机制，在Thymeleaf模板里直接调用user.getOrders().size()会导致N+1查询问题，而初学者根本意识不到这是性能瓶颈。MyBatis-Plus则完全不同——它的LambdaQueryWrapper让你用eq(Product::getCategoryId, 3)代替手写SQL字符串，既避免SQL注入风险，又通过Lambda表达式强制你关注实体类字段名，无形中强化了面向对象设计意识。更重要的是，它内置的Page分页插件，配合IPage<Product>返回类型，让“商品列表分页”这种高频需求只需3行代码：

Page<Product> page = new Page<>(current, size);
Page<Product> productPage = productService.page(page, wrapper);
model.addAttribute("page", productPage);

而对应的Thymeleaf分页模板，直接用<li th:each="item : ${page.records}">遍历即可。这种“写得少、错得少、看得懂”的特性，完美匹配课程设计场景。我们甚至在ProductServiceImpl里故意留了一个小坑：updateById()方法未加@Transactional，当同时更新商品价格和库存时会出现脏读。这个设计不是bug，而是留给学生的“找茬题”——答辩时老师问“如果两个用户同时抢购最后一块蛋糕，怎么保证库存不超卖？”，你就能指着这段代码说：“我发现了这个问题，解决方案是在Service方法上加@Transactional，并将库存扣减和订单创建放在同一个事务里”。

2.3 Thymeleaf而非Vue/React：降低前端门槛，聚焦后端逻辑

看到“前后端一体化”，你可能会疑惑：现在都2024年了，还用服务端渲染？这恰恰是教学智慧。Vue项目需要npm install、vue-cli-service serve、配置跨域代理，而Thymeleaf只需把HTML文件丢进templates目录，SpringBoot内置Tomcat启动后直接访问http://localhost:8080/index。更关键的是，Thymeleaf的th:object、th:field语法，让表单绑定变得极其直观：

<form th:action="@{/admin/product/save}" th:object="${product}" method="post">
    <input type="text" th:field="*{name}" />
    <input type="number" th:field="*{price}" />
</form>

这种写法强迫你思考：Controller传入Model的key名是否与实体类字段完全一致？@ModelAttribute注解是否正确标注？当表单提交后价格显示为0，你就会回头检查@InitBinder里是否漏写了webDataBinder.registerCustomEditor(BigDecimal.class, ...)。这种“错误驱动学习”模式，比直接给你一个现成的Vue组件库更能夯实基础。当然，系统并未封闭前端——static/js目录下预留了cart.js，里面用原生JavaScript实现了购物车数量实时计算和本地存储同步，这就是给学有余力的同学留的扩展接口：你可以把它替换成Axios调用RESTful API，自然过渡到前后端分离开发。

2.4 内置Tomcat vs 外置Tomcat：两种部署方式的教学价值

项目支持两种启动方式，这背后是两套不同的知识体系。以内置Tomcat启动（mvn spring-boot:run）适合快速验证业务逻辑，但你要理解spring-boot-starter-web依赖如何自动装配TomcatServletWebServerFactory；而部署到外置Tomcat（将项目打包为WAR，放入tomcat/webapps），则必须修改pom.xml将<packaging>改为war，重写SpringBootServletInitializer，并在application.properties里配置server.servlet.context-path=/cake-mall。这个过程看似繁琐，实则是理解Servlet容器生命周期的关键切口——当你的@PostConstruct初始化方法在外置Tomcat里执行两次，你就不得不去研究ServletContext和SpringApplication的加载时机差异。这种“折腾”带来的认知升级，远超任何PPT讲解。

3. 核心模块深度解析与实操要点：从数据库建模到订单状态机

3.1 数据库设计：12张表如何支撑电商核心流程

cake_mall.sql脚本不是简单堆砌表，而是按业务域分组设计。我们以最易出错的“订单与商品关系”为例，对比常见错误设计与本系统的处理方案：

设计维度 常见学生错误 本系统方案 教学价值
商品快照 订单表直接存product_id，商品下架后订单详情页显示404 order_item表冗余存储product_name、product_price、product_image 理解“业务数据”与“快照数据”分离思想，避免因商品变更导致历史订单信息失效
库存扣减 下单时仅UPDATE product SET stock=stock-1，无事务控制 在OrderService.createOrder()中，先SELECT FOR UPDATE锁定商品行，再扣减库存并插入订单项，全部包裹在@Transactional内 掌握数据库行级锁与Spring事务传播机制的协同工作原理
分类层级 单一category表，用parent_id实现无限级分类 拆分为category（一级类目）和sub_category（二级子类目），product表通过sub_category_id关联 避免递归查询复杂度，符合电商实际运营中“蛋糕按口味分大类，再按尺寸细分”的业务逻辑

特别要注意shopping_cart_item表的设计：

CREATE TABLE `shopping_cart_item` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `user_id` bigint NOT NULL,
  `product_id` bigint NOT NULL,
  `quantity` int NOT NULL DEFAULT '1',
  `is_checked` tinyint(1) NOT NULL DEFAULT '1', -- 0=未选中，1=已选中（用于多选结算）
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_product` (`user_id`,`product_id`) -- 强制同一用户同一商品只有一条购物车记录
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这个UNIQUE KEY uk_user_product是关键——它避免了用户反复点击“加入购物车”导致多条重复记录，而is_checked字段则为后续“全选结算”功能提供数据基础。当你在后台执行DELETE FROM shopping_cart_item WHERE user_id=1001清空购物车时，这条唯一索引会确保不会误删其他用户的数据。

3.2 用户端核心流程：从浏览到下单的完整链路

以“用户购买草莓千层蛋糕”为例，跟踪代码执行路径：

  1. 首页商品列表：IndexController.index()调用ProductService.listByCategory(1)，MyBatis-Plus生成SQL：
    sql SELECT * FROM product WHERE category_id = ? AND status = 1 ORDER BY sort_order DESC LIMIT 0, 8
    注意status = 1过滤条件，这是商品上下架的开关，对应后台ProductController.updateStatus()方法。

  2. 加入购物车：CartController.addCartItem()接收productId和quantity，关键逻辑在CartService.addCartItem()：
    java // 先查当前用户购物车中是否存在该商品 ShoppingCartItem existingItem = cartItemMapper.selectOne( new LambdaQueryWrapper<ShoppingCartItem>() .eq(ShoppingCartItem::getUserId, userId) .eq(ShoppingCartItem::getProductId, productId) ); if (existingItem != null) { // 存在则更新数量 existingItem.setQuantity(existingItem.getQuantity() + quantity); cartItemMapper.updateById(existingItem); } else { // 不存在则新增 ShoppingCartItem newItem = new ShoppingCartItem(); newItem.setUserId(userId); newItem.setProductId(productId); newItem.setQuantity(quantity); cartItemMapper.insert(newItem); }
    这里没有用INSERT ... ON DUPLICATE KEY UPDATE，因为要兼容不同数据库，且updateById()方法天然支持主键存在时更新、不存在时插入的语义。

  3. 提交订单：OrderController.submitOrder()是核心难点，它涉及多个Mapper的协同：
    ```java
    @Transactional(rollbackFor = Exception.class)
    public Order createOrder(Long userId, List orderItems) {
    // 1. 扣减库存（for update锁定）
    for (OrderItem item : orderItems) {
    Product product = productMapper.selectById(item.getProductId());
    if (product.getStock() < item.getQuantity()) {
    throw new RuntimeException(“库存不足”);
    }
    // 使用select for update确保并发安全
    productMapper.lockAndDecrementStock(product.getId(), item.getQuantity());
    }

    // 2. 创建订单主表
    Order order = new Order();
    order.setUserId(userId);
    order.setOrderSn(generateOrderSn()); // 生成唯一订单号
    order.setStatus(OrderStatus.WAIT_PAY.getCode());
    order.setCreateTime(new Date());
    orderMapper.insert(order);

    // 3. 创建订单项（冗余商品信息）
    for (OrderItem item : orderItems) {
    item.setOrderId(order.getId());
    item.setProductName(productMapper.selectById(item.getProductId()).getName());
    item.setProductPrice(productMapper.selectById(item.getProductId()).getPrice());
    orderItemMapper.insert(item);
    }

    return order;
    }
    注意`lockAndDecrementStock`方法在`ProductMapper.xml`中的实现：xml

    UPDATE product
    SET stock = stock - #{quantity}
    WHERE id = #{id} AND stock >= #{quantity}

    `` 这个AND stock >= #{quantity}`条件至关重要——它确保即使并发请求同时到达，也只会有一个更新成功，失败的请求会抛出异常，由事务自动回滚。

3.3 后台管理模块：权限控制与操作审计的落地实践

后台登录使用UsernamePasswordAuthenticationToken实现简易认证，但重点在于AdminLoginInterceptor拦截器：

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
    HttpSession session = request.getSession(false);
    if (session == null || session.getAttribute("admin") == null) {
        response.sendRedirect(request.getContextPath() + "/admin/login");
        return false;
    }
    return true;
}

这个拦截器注册在WebMvcConfigurer.addInterceptors()中，比Spring Security轻量，但足够说明“会话管理”概念。更值得深挖的是AdminLog操作日志表：

CREATE TABLE `admin_log` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `admin_id` bigint NOT NULL,
  `admin_name` varchar(50) NOT NULL,
  `operation` varchar(100) NOT NULL, -- 如"添加商品"、"修改订单状态"
  `target_id` bigint DEFAULT NULL, -- 关联的目标记录ID（商品ID、订单ID等）
  `ip_address` varchar(50) DEFAULT NULL,
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

在ProductController.save()方法末尾，你会看到：

adminLogService.saveLog(adminId, "添加商品", savedProduct.getId(), getIpAddress(request));

这种手动记录日志的方式，虽然不如AOP自动织入优雅，但它强迫你思考：哪些操作必须留痕？target_id字段如何与业务表关联？当答辩老师问“你们怎么保证后台操作可追溯？”，你就能拿出这张表的查询截图，展示某次“删除商品”操作的完整上下文。

4. 实操过程与部署指南：从导入项目到答辩演示

4.1 环境准备与项目导入（IDEA实操步骤）

第一步：确认JDK版本
- 本项目基于SpringBoot 2.7.x，要求JDK 8u191+ 或 JDK 11
- 在IDEA中：File → Project Structure → Project → Project SDK，选择已安装的JDK 8或11
- 避坑提示：不要用JDK 17！SpringBoot 2.7.x对JDK 17支持不完善，会出现java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.isAsyncStarted()错误

第二步：导入Maven项目
- 打开IDEA，选择Open，定位到解压后的项目根目录（含pom.xml的文件夹）
- 勾选Import project from external model → Maven，点击OK
- 等待Maven自动下载依赖（约3-5分钟），注意观察右下角Maven工具窗口的进度条

第三步：配置数据库连接
- 打开src/main/resources/application.yml
- 修改spring.datasource.url为你的MySQL地址：
yaml spring: datasource: url: jdbc:mysql://localhost:3306/cake_mall?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai username: root password: your_password # 替换为你的MySQL密码
- 关键细节：serverTimezone=Asia/Shanghai参数必不可少，否则启动时报The server time zone value 'XXX' is unrecognized错误

第四步：导入数据库脚本
- 使用MySQL客户端（如Navicat或命令行）创建数据库：
sql CREATE DATABASE cake_mall CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- 执行cake_mall.sql脚本（右键→运行SQL文件）
- 验证是否成功：查询user表应有5条记录，product表应有28条，order表应有17条

4.2 一键启动与功能验证

方式一：IDEA内置启动（推荐新手）
- 找到CakeMallApplication.java（在src/main/java/com/example/cakemall包下）
- 右键→Run 'CakeMallApplication.main()'
- 控制台输出Started CakeMallApplication in X.XXX seconds即启动成功
- 浏览器访问http://localhost:8080，首页应显示蛋糕轮播图和分类导航

方式二：Maven命令行启动
- 打开终端，进入项目根目录
- 执行：
bash mvn clean package -Dmaven.test.skip=true java -jar target/cake-mall-1.0-SNAPSHOT.jar
- 此方式生成的JAR包可直接交付给指导老师，无需安装IDEA

功能验证清单（答辩前必做）
| 场景 | 操作路径 | 预期结果 | 检查点 |
|------|----------|----------|--------|
| 用户登录 | 首页右上角“登录”→输入user1/password1 | 跳转至个人中心，显示用户名 | 查看UserServiceImpl.login()方法中密码加密逻辑（BCryptPasswordEncoder） |
| 加入购物车 | 商品列表→点击“加入购物车”→右上角购物车图标 | 显示商品数量，点击进入购物车页可见该商品 | 检查CartController.addCartItem()返回的JSON是否含success:true |
| 提交订单 | 购物车页→勾选商品→“去结算”→填写地址→“提交订单” | 页面跳转至订单详情页，显示订单号和“待付款”状态 | 查看order表新插入记录的status字段值是否为1 |
| 后台登录 | 访问http://localhost:8080/admin/login→输入admin/admin123 | 进入后台首页，左侧菜单栏显示“商品管理”、“订单管理”等 | 检查AdminLoginController.login()中BCryptPasswordEncoder.matches()校验逻辑 |
| 修改订单状态 | 后台→订单管理→找到一条待处理订单→点击“发货” | 订单状态变为“已发货”，用户端个人中心订单列表同步更新 | 查看OrderController.updateStatus()方法中orderMapper.updateById()调用 |

4.3 常见启动报错与精准排查

报错1：Failed to configure a DataSource: 'url' attribute is not specified
- 原因：application.yml中spring.datasource配置缩进错误，YAML对空格极其敏感
- 修复：确保url、username、password三个字段左对齐，前面不能有空格或tab
- 验证：在application.yml顶部添加logging.level.org.springframework.jdbc=DEBUG，启动时查看SQL日志是否输出

报错2：Whitelabel Error Page（白页）
- 原因：Thymeleaf模板路径错误或@Controller返回的视图名与文件名不匹配
- 排查：
1. 检查templates目录下是否存在index.html（首页）、admin/login.html（后台登录页）
2. 查看IndexController.index()方法是否返回"index"字符串
3. 在application.yml中添加：
yaml spring: thymeleaf: cache: false # 关闭模板缓存，修改HTML后无需重启 enabled: true

报错3：Invalid bound statement (not found): com.example.cakemall.mapper.ProductMapper.selectList
- 原因：MyBatis-Plus的BaseMapper接口未被正确扫描
- 修复：检查CakeMallApplication.java是否添加了@MapperScan("com.example.cakemall.mapper")注解
- 延伸知识：这个注解告诉Spring，com.example.cakemall.mapper包下的所有接口都需被MyBatis代理，生成对应的SQL执行器

5. 毕业设计扩展与答辩技巧：如何把项目讲出深度

5.1 三个低成本高价值的扩展方向

方向一：增加“优惠券”模块（推荐指数★★★★★）
- 为什么选它：业务逻辑清晰（满减、折扣、限时），数据库只需新增2张表（coupon、user_coupon），代码改动集中在OrderService的金额计算环节
- 实操步骤：
1. 在OrderService.createOrder()中，获取用户可用优惠券列表
2. 计算订单总金额时，调用CouponService.calculateDiscount(totalAmount, couponId)
3. 更新order表的discount_amount和pay_amount字段
- 答辩亮点：可以展示“同一订单使用不同优惠券时，最终支付金额的动态计算过程”，体现业务抽象能力

方向二：集成邮件通知（推荐指数★★★★☆）
- 为什么选它：Spring Boot官方提供spring-boot-starter-mail，配置简单（只需SMTP服务器地址、账号密码），但能展示“异步任务”思想
- 改造点：
- 在OrderService.createOrder()末尾，添加@Async注解的方法发送订单确认邮件
- 使用JavaMailSender发送HTML格式邮件，内嵌订单详情表格
- 教学价值：解释@EnableAsync启用异步支持，以及TaskExecutor线程池配置，避免阻塞主线程影响用户体验

方向三：添加简单搜索功能（推荐指数★★★☆☆）
- 为什么选它：不引入Elasticsearch，用MySQL全文索引即可实现
- 实施步骤：
1. 在product表的name和description字段上创建FULLTEXT索引
2. 修改ProductMapper.xml，使用MATCH AGAINST语法：
xml <select id="searchProducts" resultType="Product"> SELECT * FROM product WHERE MATCH(name, description) AGAINST(#{keyword} IN NATURAL LANGUAGE MODE) </select>
- 答辩加分项：对比LIKE模糊查询与全文索引的性能差异，用EXPLAIN命令分析执行计划

5.2 答辩陈述的黄金结构：用“问题-方案-验证”代替功能罗列

不要一上来就说“我的系统有用户管理、商品管理、订单管理…”，老师听腻了。试试这个结构：

第一幕：抛出真实痛点

“在调研本地蛋糕店线上化需求时，我发现店主最头疼的是‘库存不准’——手工记账经常漏掉微信私聊订单，导致超卖。比如情人节当天，同一款‘心形巧克力蛋糕’被3个客户同时下单，但库存只显示剩2个。”

第二幕：展示你的技术解法

“我设计了两级库存控制：前台购物车显示‘实时库存’（通过Ajax轮询/api/product/stock/{id}接口），后台下单时执行SELECT FOR UPDATE行锁，确保扣减原子性。这里的关键是ProductMapper.lockAndDecrementStock()方法，它用一条SQL完成锁定和扣减，避免了先查后更的竞态条件。”

第三幕：用数据证明效果

“我做了压力测试：用JMeter模拟100个用户同时抢购最后一块蛋糕。结果显示，98次请求成功创建订单，2次返回‘库存不足’提示，数据库product.stock字段最终为0，没有出现负数。这证明事务隔离级别设置正确。”

这种讲述方式，把技术细节嵌入业务场景，让老师感受到你不是在堆砌技术名词，而是在解决问题。

5.3 导师最可能追问的5个问题及应答策略

问题 应答要点 避坑提醒
Q1：为什么不用Redis缓存商品列表？ “考虑到毕设场景的并发量（预估日活<100人），MySQL单表查询响应时间稳定在20ms内，引入Redis会增加部署复杂度和一致性维护成本。但如果未来要支持秒杀，我会在ProductController.list()方法上加@Cacheable注解，并配置缓存过期策略。” 切忌说“不会用Redis”，要展现技术选型的权衡思维
Q2：订单状态流转如何保证不遗漏？ “我设计了状态机枚举OrderStatus，每个状态变更都通过OrderService.updateStatus()方法集中处理。例如从‘待付款’到‘已付款’，必须校验支付流水号存在且金额匹配，否则抛出IllegalStateException。所有状态变更都记录到admin_log表，确保可追溯。” 展示OrderStatus.java枚举类和updateStatus()方法源码片段
Q3：Thymeleaf模板如何防止XSS攻击？ “所有用户输入内容在模板中都使用th:text而非th:utext，例如<span th:text="${product.description}"></span>。th:text会自动转义HTML标签，而th:utext则直接输出原始HTML，仅在后台富文本编辑器场景下谨慎使用。” 拿出product/detail.html中具体的th:text用例
Q4：MyBatis-Plus的IService和BaseMapper有什么区别？ “BaseMapper提供单表CRUD，如insert()、selectById()；IService在此基础上封装了批量操作（saveBatch()）、分页（page()）、条件构造（lambdaQuery()）。我在ProductService中继承ServiceImpl，这样既能用list()快速查所有商品，又能用lambdaQuery().eq(Product::getStatus, 1)构建复杂条件。” 用ProductServiceImpl.java中的继承关系图说明
Q5：如果要支持微信支付，接口怎么设计？ “我会新增PayController，提供/pay/unifiedorder接口接收订单号，调用微信统一下单API获取prepay_id，再通过/pay/result回调地址接收支付结果。关键是要用@Transactional保证回调处理与订单状态更新的原子性，并记录pay_log表防重入。” 展示伪代码，强调“幂等性”和“事务边界”

6. 最后分享一个血泪教训：答辩前夜务必做的三件事

去年带的一个学生，答辩前一晚还在优化购物车动画效果，结果第二天演示时发现：他为了“界面更炫”，把CartController.addCartItem()的返回类型从String改成了ResponseEntity<Map<String, Object>>，但忘了同步修改cart.js里的Ajax回调函数。演示到关键环节时，点击“加入购物车”按钮毫无反应，控制台报SyntaxError: Unexpected token < in JSON at position 0——因为后端返回的是HTML重定向页面，而前端期待JSON。整个答辩现场陷入尴尬沉默。

这件事让我总结出答辩前夜的铁律：

第一件事：回归最小可行路径（MVP）
- 关闭所有非核心功能：注销掉优惠券模块、禁用邮件发送、移除自定义CSS动画
- 只保留最骨干的四条链路：用户登录→浏览商品→加入购物车→提交订单→后台发货→用户查看物流
- 用纸笔画出这六步的URL路径和返回数据格式，确保每一步都像呼吸一样自然

第二件事：录制3分钟全流程演示视频
- 用OBS或系统自带录屏工具，完整录制一次从启动项目到完成订单的全过程
- 重点录制：控制台启动日志（证明项目能跑）、数据库查询结果（证明数据真实）、浏览器Network面板（证明接口返回正常）
- 把视频存到U盘，答辩时如果现场网络故障，可直接播放视频佐证

第三件事：打印三份纸质材料
- 代码摘要页：只打印OrderService.createOrder()、ProductMapper.lockAndDecrementStock()、AdminLoginInterceptor.preHandle()这三个核心方法，每页不超过20行代码，用荧光笔标出关键行
- 数据库ER图：用draw.io画出user、product、order、order_item四张表的关系，标出外键和索引
- 问题应答卡片：把上面整理的5个高频问题写在小卡片上，背面写关键词（如“XSS”对应“th:text”、“事务”对应“@Transactional”），答辩时可自然拿起参考

记住，毕设答辩不是考试，而是向导师展示你“如何思考、如何解决问题、如何把知识转化为生产力”的过程。这套蛋糕商城系统，就是你思考过程的具象化载体。当老师看到你在ProductMapper.xml里为库存扣减特意加上AND stock >= #{quantity}条件时，他看到的不是一个学生在抄代码，而是一个未来的工程师在建立严谨的工程思维。这，才是毕业设计真正的意义。

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：专为计算机专业学生准备的毕业设计级蛋糕在线选购系统，基于SpringBoot 2.x构建，后端用Java开发，数据库采用MySQL，配套完整建库脚本cake_mall.sql，导入即可生成分类、商品、用户、订单等全部测试数据。系统包含前后端一体化功能：用户端支持浏览蛋糕列表、按分类筛选、加入购物车、提交模拟订单；后台提供商品增删改查、订单状态管理、基础用户信息维护。技术栈清晰明确——MyBatis-Plus封装数据库操作，Thymeleaf渲染HTML页面，所有配置已标准化，pom.xml依赖齐全，项目结构符合Maven规范，含src源码、resources配置、static静态资源及templates模板目录。支持IDEA直接导入，无需额外配置，可一键以内置Tomcat启动，也可部署到本地独立Tomcat服务器。适合学习SpringBoot分层开发（Controller/Service/Mapper）、RESTful接口编写、MySQL表设计与CRUD实践、电商类业务流程梳理，以及从零搭建JavaWeb项目的完整流程。


本文还有配套的精品资源，点击获取
menu-r.4af5f7ec.gif

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

agent面试必备50-AI Agent 核心进阶：多智能体“状态管理与同步”

avatar AI Agent技术社区

为什么AI Agent需要可观测性

随着AI Agent在复杂任务处理、多步决策和自主执行中扮演越来越重要的角色，其内部推理过程却如同一个"黑盒"。本文将探讨如何通过可观测性技术，让AI Agent的思考过程变得透明、可追溯、可调试。工具调用的复杂性：外部API调用、代码执行、数据查询的监控与审计。性能瓶颈的定位：识别推理延迟、工具调用失败、上下文窗口溢出的根源。上下文关联：将用户会话、Agent实例、工具调用串联起来。数据采集层：

avatar AI Agent技术社区

7 月 AI + Web3 技术月报：从智能合约审计到去中心化推理的关键进展盘点

混合审计将成为标准配置。纯规则引擎或纯大模型审计都存在不可弥补的盲区，混合架构不是过渡方案而是最终形态。落地时的关键决策是置信度加权策略——规则引擎结果应享有更高权重，而非简单并列。去中心化推理的验证层是必要的但成本高昂。3.7% 的偏差检出率证明验证层的价值，但 62% 的成本占比说明当前架构的经济模型需要优化。改进方向是"抽查验证"而非"全量验证"——根据节点声誉历史动态调整验证频率。链上 A

avatar AI Agent技术社区