简介基于SpringBoot仿天猫商城的毕业设计项目源码包面向计算机相关专业毕业生以及需要实战练习的Spring Boot初学者提供一套完整可运行的前后台电商系统。项目基于IntelliJ IDEA开发数据库使用MySQL 5.7前台包含商品检索、购物车、下单支付等流程后台包含商品管理、订单处理、用户管理等模块可帮助深入理解企业级开发规范与电商业务逻辑。压缩包内共1503个文件包括Java源码、JSP页面、XML配置文件、SQL数据库脚本以及大量JPG和PNG图片素材其中图片占据多数用于商品展示和页面装饰XML与Properties文件承担框架配置另有CSS和JS辅助前端样式与交互整体大小约182.52MB。目前已有205人学习下载。资源附有完整导入说明和清晰的目录结构能够快速启动运行并二次扩展既适合作为毕业设计直接参考也适合用于Spring Boot综合项目实训。1. 为什么 SpringBoot 仿天猫商城是毕业设计里最稳的选题电商系统是毕业设计里少有的“业务复杂度足够、技术栈覆盖面广、演示效果直观”的选题。用户注册登录、商品检索、购物车、下单支付、订单状态流转这一套流程不仅贴近真实生产场景而且能自然引出缓存、异步、事务、权限控制这些面试官爱问的点。SpringBoot 在这个项目里的价值不是“能用”而是把一个原本需要大量 XML 配置的分布式应用压缩成可以单人维护的中型工程让开发者把精力放在业务逻辑而非环境搭建上。这个标题真正吸引人的地方在于“仿天猫”三个字——它暗示了一个完整的前后端分离架构而不是单页的 CRUD 演示。后端要提供 RESTful API前端通过 Vue 或 Thymeleaf 消费接口数据层涉及多表关联、库存扣减、订单号生成。任何一个环节做到位都能成为论文里的核心创新点。下面从技术选型、数据库设计、交易链路、性能优化和答辩要点五个层面把这条路径完整铺开。2. SpringBoot 仿天猫商城的技术选型与项目骨架搭建2.1 选型为什么是 SpringBoot MyBatis-Plus 而不是 Spring Cloud单体应用和微服务的边界很容易被毕业设计放大。仿天猫商城这个规模用户量在演示阶段不过几千商品数据几百条根本没有服务拆分的必要。强行引入 Spring Cloud Alibaba、Nacos、Sentinel 会让项目启动时间翻倍答辩时还容易被追问“网关崩了你怎么办”这类问题。正确做法是保持单体架构预留拆分的可能性即可。持久层框架里 MyBatis-Plus 比原生 MyBatis 更适合这个场景。它内置了分页插件、逻辑删除、自动填充能把重复的 CRUD 代码减少 60% 以上同时保留了自定义 SQL 的灵活性。Spring Data JPA 虽然写起来更省事但对多表关联和复杂查询的控制力较弱排错时不如 SQL 直观。2.1.1 前后端分离还是服务端渲染前端选型要看论文的侧重点。如果研究点是后端架构用 Thymeleaf 把页面放在 templates 目录下部署只需一个 jar 包省去跨域和 Nginx 配置的麻烦。如果研究点是分布式或前后端交互则用 Vue 3 Element Plus 做独立前端工程通过 Nginx 反向代理到后端。我一般建议用前后端分离原因是“跨域问题”和“JWT 鉴权”本身就是很好的论文素材面试官也默认现在的新项目就该这么写。2.2 搭建工程时最容易出错的配置项用 IDEA 的 Spring Initializr 创建项目时Java 版本要和本机 JDK 保持一致SpringBoot 版本建议选 2.7.x 而不是 3.x。很多毕业设计的数据库驱动、连接池和 MyBatis-Plus 插件还在用 javax 命名空间SpringBoot 3 强制要求 jakarta升级后会出现大量包名报错。既然标题是“基于 SpringBoot 仿天猫商城”稳定压倒一切。核心配置文件里需要特别注意三组参数spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 redis: host: localhost port: 6379 database: 0 timeout: 5000ms servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: mapper-locations: classpath:/mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里有几个参数值得在答辩时展开。serverTimezoneAsia/Shanghai不配置的话MySQL 8 的驱动会报时区错误useSSLfalse是因为本地开发没有证书浏览器访问静态资源时不会触发安全警告maximum-pool-size默认是 10并发测试时线程等待时间偏长提到 20 能让压测数据好看一些。map-underscore-to-camel-case开启后数据库的create_time能自动映射到实体的createTime字段省去写大量 ResultMap。2.3 推荐的分层结构与包命名规范包结构要能一眼看出职责边界。常见做法是controller、service、mapper、entity、dto、vo、config、common八个包其中dto放接收参数的请求对象vo放返回给前端的视图对象二者不能混用。很多同学直接把 Entity 返回给前端导致密码、手机号等敏感字段泄露这是代码评审里最容易被挑出的问题。common包里放统一响应类我一般命名为ResultT结构如下public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } }前端拿到统一结构后只需要在 Axios 拦截器里判断code是否为 200减少大量重复的错误处理代码。这里要注意Result类不要用 Lombok 的Data直接暴露字段建议手动写 getter防止 JSON 序列化时把 null 也带出去。3. 数据库设计与核心表结构从用户到订单的链路3.1 建表时就要考虑“下单”而不是“展示”仿天猫商城的表至少有八张用户表、商品分类表、商品表、商品图片表、购物车表、订单表、订单明细表、收货地址表。如果要做秒杀或优惠券还需要单独建秒杀商品表和用户优惠券表。设计的关键约束是购物车表存user_id和sku_id下单后把购物车记录的状态置为无效而不是删除——这样用户还能在“已购买”列表里看到历史加购记录。商品表要区分 SPU 和 SKU。SPU 是“iPhone 15”SKU 是“iPhone 15 黑色 256G”。大多数毕业设计只做一张商品表颜色、容量等规格用逗号拼接存在一个字段里这种做法在查询库存时非常痛苦。建议至少拆出product和sku两张表商品详情页展示 SPU点击购买时锁定具体的 SKU。CREATE TABLE order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, user_id bigint NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, pay_type tinyint DEFAULT NULL COMMENT 1微信 2支付宝, receiver_name varchar(20) NOT NULL, receiver_phone varchar(11) NOT NULL, receiver_address varchar(255) NOT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime DEFAULT NULL, deleted tinyint DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里最重要的约束是order_no的唯一索引。订单号必须保证全局唯一不能用数据库自增主键直接展示给用户因为这样会暴露平台的日订单量。常见做法是用 Redis 的 INCR 生成自增序列再拼接时间戳和随机数。status字段加上注释前端展示订单状态时直接映射枚举避免后端写一堆魔法数字判断。3.2 用户认证JWT 拦截器怎么配置才算完整用户模块的技术含量集中在认证和授权。SpringBoot 里常见的方案是 Spring Security JWT但 Security 的过滤器链配置复杂很多人在毕业设计里配一周也跑不通。更务实的做法是用拦截器 HandlerInterceptor 对需要登录的接口做校验把 JWT 解析放在拦裁器里不引入 Security 的重量级依赖。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StringUtils.isBlank(token) || !token.startsWith(Bearer )) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write({\code\:401,\message\:\未登录或token失效\}); return false; } try { Claims claims JwtUtil.parseToken(token.replace(Bearer , )); request.setAttribute(userId, claims.get(userId)); return true; } catch (Exception e) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write({\code\:401,\message\:\token解析失败\}); return false; } } }这个拦截器有三个关键细节。第一OPTIONS请求必须直接放行否则前端跨域预检会永远失败。第二token 解析成功后把userId放在 request attribute 里Controller 通过RequestAttribute Long userId直接取避免每次调用都在 Controller 里重新解析。第三token 过期时间建议设 7 天毕业设计演示期间频繁重新登录会打断答辩节奏实习项目里可以缩短到 2 小时。3.3 商品列表的分页与条件筛选商品模块的核心是“多条件查询 分页”。直接用 MyBatis-Plus 的 LambdaQueryWrapper 做条件拼接注意名称模糊匹配用like分类筛选用eq。价格区间用between上架状态用eq。如果商品表里有全文检索需求可以引入 Elasticsearch但对毕业设计而言 MySQL 的 LIKE 查询在百万级数据内足够。分页插件配置是 MyBatis-Plus 使用中最容易被忽略的环节。没有配置 PaginationInnerInterceptor 时selectPage方法返回的数据是不分页的这个坑能让排错耗掉半天时间。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(100L); interceptor.addInnerInterceptor(pagination); return interceptor; } }setMaxLimit(100L)用来防止用户把pageSize传成 999999相当于给查询加了一道安全闸门。分页查询的 Controller 里要同时返回总记录数和总页数前端才能渲染分页组件。很多同学只返回列表数据前端不知道有多少页只能写死页码这个细节在答辩演示时很容易被发现。4. 购物车与订单流转SpringBoot 事务和 Redis 的配合4.1 购物车选型Redis 还是 MySQL购物车有纯 Redis 和 Redis MySQL 两种实现方案。纯 Redis 的优点是读写极快缺点是用户清缓存后数据丢失纯 MySQL 的优点是可靠缺点是每次增删改都要查库吞吐量上不去。毕业设计的折中方案是把购物车数据存 Rediskey 设计为cart:userIdvalue 用 Hash 结构存skuId - 数量下单成功后把相关 sku 从 Hash 中移除。Redis 的 Hash 结构天然适合购物车一个 key 里有多个字段对应多个商品数量通过 HINCRBY 原子自增。如果用户重复加入同一商品不需要先查再改一条命令就完成数量累加。public void addCart(Long userId, Long skuId, Integer count) { String key cart: userId; String field String.valueOf(skuId); redisTemplate.opsForHash().increment(key, field, count); redisTemplate.expire(key, 7, TimeUnit.DAYS); }这段代码里increment方法返回的是累加后的值业务上可以据此判断是否超过了库存上限。expire设置 7 天用户一周未登录后购物车自动清理符合电商的常见行为。注意 Redis 操作没有事务控制如果需要在加购物车的同时校验商品状态应该先查商品表再写 Redis而不是把两步合并进一个事务——Redis 操作和 MySQL 事务不在同一个 ACID 边界里。4.1.1 购物车字段参数说明购物车表如果用 MySQL 兜底建议字段设计为id、user_id、sku_id、count、checked是否勾选、create_time、update_time、deleted。其中checked字段很关键因为“结算”时勾选状态决定了订单包含哪些商品。前端点选购物车商品后需要把勾选状态同步到后端后端用集合接收skuId再一次性查出对应的价格生成订单。4.2 下单流程的事务边界下单是仿天猫商城里最容易出事务 Bug 的场景。正确的操作顺序是校验用户收货地址 → 锁定商品库存 → 计算订单金额 → 生成订单主表 → 生成订单明细 → 清空购物车对应商品。在这个过程中库存锁定和订单生成要放在同一个事务里否则会出现“订单生成了但库存没扣”的数据不一致。用Transactional标注 Service 方法把事务边界控制在业务逻辑层而不是 Controller 层。Spring 事务默认只在抛出 RuntimeException 时回滚如果手动捕获了异常但没有重新抛出事务不会回滚这是最常见的问题。Transactional(rollbackFor Exception.class) public Long createOrder(Long userId, ListLong skuIds, Long addressId) { // 1. 查询收货地址 Address address addressMapper.selectById(addressId); // 2. 锁定库存 for (Long skuId : skuIds) { int update skuMapper.deductStock(skuId, 1); if (update 0) { throw new BizException(库存不足); } } // 3. 计算总金额 BigDecimal total calculateTotal(skuIds); // 4. 插入订单 Order order new Order(); order.setOrderNo(OrderNoGenerator.generate()); order.setUserId(userId); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 5. 插入明细 insertOrderItems(order.getId(), skuIds); return order.getId(); }deductStock方法对应的 SQL 是update sku set stock stock - 1 where id #{skuId} and stock 0用数据库行锁保证超卖不发生。这里的rollbackFor Exception.class是显式声明因为 BizException 是自定义异常默认情况下 Spring 只知道 RuntimeException 和 Error 才回滚自定义异常如果不继承 RuntimeException 就需要手动指定。开启事务后订单接口的响应时间会变长因为多个写操作要等事务提交。如果答辩时用 JMeter 压测下单接口注意数据库连接池数量要大于并发数否则线程会排队等待连接压测曲线看起来像线程阻塞。4.3 超时未支付订单用 SpringBoot 定时任务处理订单创建后用户可能一直不支付需要有一个任务把超时订单状态改成已取消同时恢复库存。SpringBoot 里最简单的方案是Scheduled定时任务配合 Redis 的过期监听也可以但 Redis 监听需要额外配置 KeyExpirationEventMessageListener而且 Redis 的 key 过期事件存在消息丢失风险毕业设计用定时扫描即可。Component public class OrderTimeoutTask { Scheduled(cron 0 0/1 * * * ?) public void cancelTimeoutOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(15); // 查询所有创建时间早于deadline且状态为0的订单 ListOrder orders orderMapper.selectTimeoutOrders(deadline); for (Order order : orders) { // 恢复库存 skuMapper.restoreStock(order.getId()); // 更新订单状态 order.setStatus(4); orderMapper.updateById(order); } } }定时任务的最小粒度是一分钟执行一次cron 表达式0 0/1 * * * ?表示每分钟的第 0 秒触发。批量查询时用create_time deadline而不是避免边界重复处理。注意要通过订单明细表反查 SKU 再恢复库存因为订单主表不直接关联 SKU。如果项目里配了 Nacos 或 XXL-Job可以把定时调度交给独立中间件但单体项目用 Spring 自带的注解没有任何问题。5. 参数调优、安全加固与答辩前自查清单5.1 让压测数据更好看的三个配置毕业设计答辩时展示一份简单的 JMeter 测试报告能显著提高整体的专业度。在本地环境跑 500 并发用户登录接口默认配置下 TPS每秒事务数通常只有 200 左右经过三个调整能提升到 800 以上。第一个调整是让 HikariCP 连接池的maximum-pool-size与压测并发数匹配过小会导致连接等待过大会浪费内存。第二个调整是 Redis 连接池参数Spring Boot 2.x 默认使用 Lettuce其连接数不设上限压测时为避免大量断连可以设置spring.redis.lettuce.pool.max-active50。第三个调整是开启 Tomcat 的线程池配置。server: tomcat: threads: max: 200 min-spare: 40 accept-count: 100 max-connections: 10000max-threads默认值是 200压测时把它提到 500 会让并发能力明显上升但也会增加每条连接的内存占用。accept-count表示队列里等待的数量超过后直接拒绝新连接这个值不要设太大否则用户的超时时间会拉长。答辩时如果能解释清楚这三个参数的意义比展示截图更有说服力。5.2 两个容易被攻击的接口漏洞及修复方式仿天猫商城项目最容易出现两个安全漏洞。第一个是 SQL 注入——用字符串拼接的方式构建 SQL 查询页面 URL 的参数直接进入 mybatis 的${}语法。修复方式很直接所有输入参数一律用#{}预编译${}只允许用于排序列名这种程序内部传入的固定值。第二个漏洞是越权访问。订单查询接口如果直接用orderId查不做用户归属校验攻击者只需要遍历数字 ID 就能看到所有用户的订单信息。修复方式是在接口里增加当前登录用户 ID 和订单归属用户的比对。GetMapping(/order/detail/{orderId}) public ResultOrderVO detail(PathVariable Long orderId, RequestAttribute(userId) Long userId) { Order order orderMapper.selectById(orderId); if (order null || !order.getUserId().equals(userId)) { throw new BizException(订单不存在); } return Result.ok(convertToVO(order)); }这段代码的关键逻辑是!order.getUserId().equals(userId)这一步。很多人的做法是只判断order null结果任意登录用户都能查看他人订单。答辩时主动提到越权防护会显得你思考过真实系统的安全问题。5.3 答辩前必做的三轮功能自查第一轮要检查所有接口在未登录状态下的返回——Controller 里加了拦截器的接口应该返回 401没加的接口应该能独立访问。第二轮要检查下单流程的边界场景库存为 0 时能否正确提示”、重复点击提交按钮会不会生成两笔订单。前端提交按钮点击后应该立即置灰后端在事务里通过数据库唯一索引或 Redis 分布式锁做二次防护。第三轮要检查部署环境项目打包成 jar 后application.yml里的数据库密码不能是明文生产密码至少改成环境变量读取。这里推荐一个验证接口幂等性的小技巧。在 Redis 里设置一个临时 keykey 为order:token:userId:random用户进入下单页时先申请一个 token 存在前端提交订单时把 token 带给后端。后端判断 Redis 中是否存在该 token存在则执行下单逻辑并删除 token不存在则直接提示重复提交。这个方案只需要十几行代码却能明确写出“使用 Redis 做幂等控制”作为项目的功能亮点是很自然的加码点和亮点。做完上述检查后最终再确认一遍项目能否从零跑通整套流程从 IDEA 启动 SpringBoot 到导入前端工程再到浏览器完成“注册→登录→加购→结算→支付”的完整链路。整个链路能稳定复现答辩基本就稳了。本文还有配套的精品资源点击获取 
长河君 · 2026/9/15 19:56:14 · 阅读 1.2k SpringBoot仿天猫商城毕业设计：从架构到安全的全流程实战解析
简介基于SpringBoot仿天猫商城的毕业设计项目源码包面向计算机相关专业毕业生以及需要实战练习的Spring Boot初学者提供一套完整可运行的前后台电商系统。项目基于IntelliJ IDEA开发数据库使用MySQL 5.7前台包含商品检索、购物车、下单支付等流程后台包含商品管理、订单处理、用户管理等模块可帮助深入理解企业级开发规范与电商业务逻辑。压缩包内共1503个文件包括Java源码、JSP页面、XML配置文件、SQL数据库脚本以及大量JPG和PNG图片素材其中图片占据多数用于商品展示和页面装饰XML与Properties文件承担框架配置另有CSS和JS辅助前端样式与交互整体大小约182.52MB。目前已有205人学习下载。资源附有完整导入说明和清晰的目录结构能够快速启动运行并二次扩展既适合作为毕业设计直接参考也适合用于Spring Boot综合项目实训。1. 为什么 SpringBoot 仿天猫商城是毕业设计里最稳的选题电商系统是毕业设计里少有的“业务复杂度足够、技术栈覆盖面广、演示效果直观”的选题。用户注册登录、商品检索、购物车、下单支付、订单状态流转这一套流程不仅贴近真实生产场景而且能自然引出缓存、异步、事务、权限控制这些面试官爱问的点。SpringBoot 在这个项目里的价值不是“能用”而是把一个原本需要大量 XML 配置的分布式应用压缩成可以单人维护的中型工程让开发者把精力放在业务逻辑而非环境搭建上。这个标题真正吸引人的地方在于“仿天猫”三个字——它暗示了一个完整的前后端分离架构而不是单页的 CRUD 演示。后端要提供 RESTful API前端通过 Vue 或 Thymeleaf 消费接口数据层涉及多表关联、库存扣减、订单号生成。任何一个环节做到位都能成为论文里的核心创新点。下面从技术选型、数据库设计、交易链路、性能优化和答辩要点五个层面把这条路径完整铺开。2. SpringBoot 仿天猫商城的技术选型与项目骨架搭建2.1 选型为什么是 SpringBoot MyBatis-Plus 而不是 Spring Cloud单体应用和微服务的边界很容易被毕业设计放大。仿天猫商城这个规模用户量在演示阶段不过几千商品数据几百条根本没有服务拆分的必要。强行引入 Spring Cloud Alibaba、Nacos、Sentinel 会让项目启动时间翻倍答辩时还容易被追问“网关崩了你怎么办”这类问题。正确做法是保持单体架构预留拆分的可能性即可。持久层框架里 MyBatis-Plus 比原生 MyBatis 更适合这个场景。它内置了分页插件、逻辑删除、自动填充能把重复的 CRUD 代码减少 60% 以上同时保留了自定义 SQL 的灵活性。Spring Data JPA 虽然写起来更省事但对多表关联和复杂查询的控制力较弱排错时不如 SQL 直观。2.1.1 前后端分离还是服务端渲染前端选型要看论文的侧重点。如果研究点是后端架构用 Thymeleaf 把页面放在 templates 目录下部署只需一个 jar 包省去跨域和 Nginx 配置的麻烦。如果研究点是分布式或前后端交互则用 Vue 3 Element Plus 做独立前端工程通过 Nginx 反向代理到后端。我一般建议用前后端分离原因是“跨域问题”和“JWT 鉴权”本身就是很好的论文素材面试官也默认现在的新项目就该这么写。2.2 搭建工程时最容易出错的配置项用 IDEA 的 Spring Initializr 创建项目时Java 版本要和本机 JDK 保持一致SpringBoot 版本建议选 2.7.x 而不是 3.x。很多毕业设计的数据库驱动、连接池和 MyBatis-Plus 插件还在用 javax 命名空间SpringBoot 3 强制要求 jakarta升级后会出现大量包名报错。既然标题是“基于 SpringBoot 仿天猫商城”稳定压倒一切。核心配置文件里需要特别注意三组参数spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 redis: host: localhost port: 6379 database: 0 timeout: 5000ms servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: mapper-locations: classpath:/mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里有几个参数值得在答辩时展开。serverTimezoneAsia/Shanghai不配置的话MySQL 8 的驱动会报时区错误useSSLfalse是因为本地开发没有证书浏览器访问静态资源时不会触发安全警告maximum-pool-size默认是 10并发测试时线程等待时间偏长提到 20 能让压测数据好看一些。map-underscore-to-camel-case开启后数据库的create_time能自动映射到实体的createTime字段省去写大量 ResultMap。2.3 推荐的分层结构与包命名规范包结构要能一眼看出职责边界。常见做法是controller、service、mapper、entity、dto、vo、config、common八个包其中dto放接收参数的请求对象vo放返回给前端的视图对象二者不能混用。很多同学直接把 Entity 返回给前端导致密码、手机号等敏感字段泄露这是代码评审里最容易被挑出的问题。common包里放统一响应类我一般命名为ResultT结构如下public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } }前端拿到统一结构后只需要在 Axios 拦截器里判断code是否为 200减少大量重复的错误处理代码。这里要注意Result类不要用 Lombok 的Data直接暴露字段建议手动写 getter防止 JSON 序列化时把 null 也带出去。3. 数据库设计与核心表结构从用户到订单的链路3.1 建表时就要考虑“下单”而不是“展示”仿天猫商城的表至少有八张用户表、商品分类表、商品表、商品图片表、购物车表、订单表、订单明细表、收货地址表。如果要做秒杀或优惠券还需要单独建秒杀商品表和用户优惠券表。设计的关键约束是购物车表存user_id和sku_id下单后把购物车记录的状态置为无效而不是删除——这样用户还能在“已购买”列表里看到历史加购记录。商品表要区分 SPU 和 SKU。SPU 是“iPhone 15”SKU 是“iPhone 15 黑色 256G”。大多数毕业设计只做一张商品表颜色、容量等规格用逗号拼接存在一个字段里这种做法在查询库存时非常痛苦。建议至少拆出product和sku两张表商品详情页展示 SPU点击购买时锁定具体的 SKU。CREATE TABLE order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, user_id bigint NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, pay_type tinyint DEFAULT NULL COMMENT 1微信 2支付宝, receiver_name varchar(20) NOT NULL, receiver_phone varchar(11) NOT NULL, receiver_address varchar(255) NOT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime DEFAULT NULL, deleted tinyint DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里最重要的约束是order_no的唯一索引。订单号必须保证全局唯一不能用数据库自增主键直接展示给用户因为这样会暴露平台的日订单量。常见做法是用 Redis 的 INCR 生成自增序列再拼接时间戳和随机数。status字段加上注释前端展示订单状态时直接映射枚举避免后端写一堆魔法数字判断。3.2 用户认证JWT 拦截器怎么配置才算完整用户模块的技术含量集中在认证和授权。SpringBoot 里常见的方案是 Spring Security JWT但 Security 的过滤器链配置复杂很多人在毕业设计里配一周也跑不通。更务实的做法是用拦截器 HandlerInterceptor 对需要登录的接口做校验把 JWT 解析放在拦裁器里不引入 Security 的重量级依赖。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StringUtils.isBlank(token) || !token.startsWith(Bearer )) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write({\code\:401,\message\:\未登录或token失效\}); return false; } try { Claims claims JwtUtil.parseToken(token.replace(Bearer , )); request.setAttribute(userId, claims.get(userId)); return true; } catch (Exception e) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write({\code\:401,\message\:\token解析失败\}); return false; } } }这个拦截器有三个关键细节。第一OPTIONS请求必须直接放行否则前端跨域预检会永远失败。第二token 解析成功后把userId放在 request attribute 里Controller 通过RequestAttribute Long userId直接取避免每次调用都在 Controller 里重新解析。第三token 过期时间建议设 7 天毕业设计演示期间频繁重新登录会打断答辩节奏实习项目里可以缩短到 2 小时。3.3 商品列表的分页与条件筛选商品模块的核心是“多条件查询 分页”。直接用 MyBatis-Plus 的 LambdaQueryWrapper 做条件拼接注意名称模糊匹配用like分类筛选用eq。价格区间用between上架状态用eq。如果商品表里有全文检索需求可以引入 Elasticsearch但对毕业设计而言 MySQL 的 LIKE 查询在百万级数据内足够。分页插件配置是 MyBatis-Plus 使用中最容易被忽略的环节。没有配置 PaginationInnerInterceptor 时selectPage方法返回的数据是不分页的这个坑能让排错耗掉半天时间。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(100L); interceptor.addInnerInterceptor(pagination); return interceptor; } }setMaxLimit(100L)用来防止用户把pageSize传成 999999相当于给查询加了一道安全闸门。分页查询的 Controller 里要同时返回总记录数和总页数前端才能渲染分页组件。很多同学只返回列表数据前端不知道有多少页只能写死页码这个细节在答辩演示时很容易被发现。4. 购物车与订单流转SpringBoot 事务和 Redis 的配合4.1 购物车选型Redis 还是 MySQL购物车有纯 Redis 和 Redis MySQL 两种实现方案。纯 Redis 的优点是读写极快缺点是用户清缓存后数据丢失纯 MySQL 的优点是可靠缺点是每次增删改都要查库吞吐量上不去。毕业设计的折中方案是把购物车数据存 Rediskey 设计为cart:userIdvalue 用 Hash 结构存skuId - 数量下单成功后把相关 sku 从 Hash 中移除。Redis 的 Hash 结构天然适合购物车一个 key 里有多个字段对应多个商品数量通过 HINCRBY 原子自增。如果用户重复加入同一商品不需要先查再改一条命令就完成数量累加。public void addCart(Long userId, Long skuId, Integer count) { String key cart: userId; String field String.valueOf(skuId); redisTemplate.opsForHash().increment(key, field, count); redisTemplate.expire(key, 7, TimeUnit.DAYS); }这段代码里increment方法返回的是累加后的值业务上可以据此判断是否超过了库存上限。expire设置 7 天用户一周未登录后购物车自动清理符合电商的常见行为。注意 Redis 操作没有事务控制如果需要在加购物车的同时校验商品状态应该先查商品表再写 Redis而不是把两步合并进一个事务——Redis 操作和 MySQL 事务不在同一个 ACID 边界里。4.1.1 购物车字段参数说明购物车表如果用 MySQL 兜底建议字段设计为id、user_id、sku_id、count、checked是否勾选、create_time、update_time、deleted。其中checked字段很关键因为“结算”时勾选状态决定了订单包含哪些商品。前端点选购物车商品后需要把勾选状态同步到后端后端用集合接收skuId再一次性查出对应的价格生成订单。4.2 下单流程的事务边界下单是仿天猫商城里最容易出事务 Bug 的场景。正确的操作顺序是校验用户收货地址 → 锁定商品库存 → 计算订单金额 → 生成订单主表 → 生成订单明细 → 清空购物车对应商品。在这个过程中库存锁定和订单生成要放在同一个事务里否则会出现“订单生成了但库存没扣”的数据不一致。用Transactional标注 Service 方法把事务边界控制在业务逻辑层而不是 Controller 层。Spring 事务默认只在抛出 RuntimeException 时回滚如果手动捕获了异常但没有重新抛出事务不会回滚这是最常见的问题。Transactional(rollbackFor Exception.class) public Long createOrder(Long userId, ListLong skuIds, Long addressId) { // 1. 查询收货地址 Address address addressMapper.selectById(addressId); // 2. 锁定库存 for (Long skuId : skuIds) { int update skuMapper.deductStock(skuId, 1); if (update 0) { throw new BizException(库存不足); } } // 3. 计算总金额 BigDecimal total calculateTotal(skuIds); // 4. 插入订单 Order order new Order(); order.setOrderNo(OrderNoGenerator.generate()); order.setUserId(userId); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 5. 插入明细 insertOrderItems(order.getId(), skuIds); return order.getId(); }deductStock方法对应的 SQL 是update sku set stock stock - 1 where id #{skuId} and stock 0用数据库行锁保证超卖不发生。这里的rollbackFor Exception.class是显式声明因为 BizException 是自定义异常默认情况下 Spring 只知道 RuntimeException 和 Error 才回滚自定义异常如果不继承 RuntimeException 就需要手动指定。开启事务后订单接口的响应时间会变长因为多个写操作要等事务提交。如果答辩时用 JMeter 压测下单接口注意数据库连接池数量要大于并发数否则线程会排队等待连接压测曲线看起来像线程阻塞。4.3 超时未支付订单用 SpringBoot 定时任务处理订单创建后用户可能一直不支付需要有一个任务把超时订单状态改成已取消同时恢复库存。SpringBoot 里最简单的方案是Scheduled定时任务配合 Redis 的过期监听也可以但 Redis 监听需要额外配置 KeyExpirationEventMessageListener而且 Redis 的 key 过期事件存在消息丢失风险毕业设计用定时扫描即可。Component public class OrderTimeoutTask { Scheduled(cron 0 0/1 * * * ?) public void cancelTimeoutOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(15); // 查询所有创建时间早于deadline且状态为0的订单 ListOrder orders orderMapper.selectTimeoutOrders(deadline); for (Order order : orders) { // 恢复库存 skuMapper.restoreStock(order.getId()); // 更新订单状态 order.setStatus(4); orderMapper.updateById(order); } } }定时任务的最小粒度是一分钟执行一次cron 表达式0 0/1 * * * ?表示每分钟的第 0 秒触发。批量查询时用create_time deadline而不是避免边界重复处理。注意要通过订单明细表反查 SKU 再恢复库存因为订单主表不直接关联 SKU。如果项目里配了 Nacos 或 XXL-Job可以把定时调度交给独立中间件但单体项目用 Spring 自带的注解没有任何问题。5. 参数调优、安全加固与答辩前自查清单5.1 让压测数据更好看的三个配置毕业设计答辩时展示一份简单的 JMeter 测试报告能显著提高整体的专业度。在本地环境跑 500 并发用户登录接口默认配置下 TPS每秒事务数通常只有 200 左右经过三个调整能提升到 800 以上。第一个调整是让 HikariCP 连接池的maximum-pool-size与压测并发数匹配过小会导致连接等待过大会浪费内存。第二个调整是 Redis 连接池参数Spring Boot 2.x 默认使用 Lettuce其连接数不设上限压测时为避免大量断连可以设置spring.redis.lettuce.pool.max-active50。第三个调整是开启 Tomcat 的线程池配置。server: tomcat: threads: max: 200 min-spare: 40 accept-count: 100 max-connections: 10000max-threads默认值是 200压测时把它提到 500 会让并发能力明显上升但也会增加每条连接的内存占用。accept-count表示队列里等待的数量超过后直接拒绝新连接这个值不要设太大否则用户的超时时间会拉长。答辩时如果能解释清楚这三个参数的意义比展示截图更有说服力。5.2 两个容易被攻击的接口漏洞及修复方式仿天猫商城项目最容易出现两个安全漏洞。第一个是 SQL 注入——用字符串拼接的方式构建 SQL 查询页面 URL 的参数直接进入 mybatis 的${}语法。修复方式很直接所有输入参数一律用#{}预编译${}只允许用于排序列名这种程序内部传入的固定值。第二个漏洞是越权访问。订单查询接口如果直接用orderId查不做用户归属校验攻击者只需要遍历数字 ID 就能看到所有用户的订单信息。修复方式是在接口里增加当前登录用户 ID 和订单归属用户的比对。GetMapping(/order/detail/{orderId}) public ResultOrderVO detail(PathVariable Long orderId, RequestAttribute(userId) Long userId) { Order order orderMapper.selectById(orderId); if (order null || !order.getUserId().equals(userId)) { throw new BizException(订单不存在); } return Result.ok(convertToVO(order)); }这段代码的关键逻辑是!order.getUserId().equals(userId)这一步。很多人的做法是只判断order null结果任意登录用户都能查看他人订单。答辩时主动提到越权防护会显得你思考过真实系统的安全问题。5.3 答辩前必做的三轮功能自查第一轮要检查所有接口在未登录状态下的返回——Controller 里加了拦截器的接口应该返回 401没加的接口应该能独立访问。第二轮要检查下单流程的边界场景库存为 0 时能否正确提示”、重复点击提交按钮会不会生成两笔订单。前端提交按钮点击后应该立即置灰后端在事务里通过数据库唯一索引或 Redis 分布式锁做二次防护。第三轮要检查部署环境项目打包成 jar 后application.yml里的数据库密码不能是明文生产密码至少改成环境变量读取。这里推荐一个验证接口幂等性的小技巧。在 Redis 里设置一个临时 keykey 为order:token:userId:random用户进入下单页时先申请一个 token 存在前端提交订单时把 token 带给后端。后端判断 Redis 中是否存在该 token存在则执行下单逻辑并删除 token不存在则直接提示重复提交。这个方案只需要十几行代码却能明确写出“使用 Redis 做幂等控制”作为项目的功能亮点是很自然的加码点和亮点。做完上述检查后最终再确认一遍项目能否从零跑通整套流程从 IDEA 启动 SpringBoot 到导入前端工程再到浏览器完成“注册→登录→加购→结算→支付”的完整链路。整个链路能稳定复现答辩基本就稳了。本文还有配套的精品资源点击获取