简介基于SpringBoot的电商平台设计与实现资源包以毕业设计论文形式呈现覆盖课题背景、系统分析、开发环境、系统设计等章节完整还原项目从需求到落地的思路。资源面向计算机相关专业学生可作为毕业设计、课程设计或实训项目的参考范本重点解决传统商品交易信息管理效率低、容错率低等痛点。系统功能涵盖商家管理、用户管理、商品上下架与库存、订单管理、商品评价、购物车、订单支付及物流跟踪等模块技术方案选用Mysql数据库存储用户、商品、订单等核心数据利用Java语言的跨平台特性与Spring Boot框架简化配置、提升开发效率。整份资源仅包含1个doc文件压缩包大小4.5MB文件虽少但内容紧凑以论文加核心代码段落的形式集中呈现了系统设计思路、数据库方案与实现细节便于快速对照改写。目前已有35人学习适合需要掌握Spring Boot电商项目结构、撰写毕设文档或借鉴功能设计的开发者参考。1. 基于SpringBoot电商平台为什么这个老选题还是年年有人抢着做后台管理系统 商品浏览 购物车 下单支付这套基于SpringBoot的电商平台几乎每年都是毕业设计和自学项目里出现频率最高的选题之一。很多人觉得它太常见、没新意但真正动手的人会发现把商品列表跑通不难难的是订单状态机怎么设计、并发扣库存怎么不超卖、支付回调怎么验签、本地图片上传后刷新就丢怎么兜底。这些问题恰恰是电商项目区别于普通CRUD的价值所在。我见过太多人在答辩前一周还在改订单状态的bug也见过不少人照着开源商城敲了一遍简历上写“熟悉电商秒杀场景”问到Redis原子操作却说不出所以然。这篇笔记想把一条能跑通、能讲清、能二开的路径讲透从环境选型和表结构设计开始到JWT登录、商品搜索、下单事务三个核心模块的代码落地再给出几个必踩的坑和对应解法最后聊聊二开方向和文档怎么配合。适合谁正在做毕设的技术学生或者想往电商后端方向求职、需要一个拿得出手的项目储备的人。前者照着能做完后者能从中提炼出可讲的难点和优化点。两种目标不同但起点一致先让它本地跑起来。2. 开工前的选型与技术决策SpringBoot版本、ORM和鉴权方案怎么定2.1 SpringBoot版本选哪个稳定优先还是新特性优先电商项目不像中间件研发不需要追最新版本。SpringBoot 3.x 已经成熟但如果你在本地用的是 JDK 8那只能选 2.7.x如果环境是 JDK 17 及以上3.x 是更合理的选择。我在实际带项目时一般这么定默认 SpringBoot 2.7.18 JDK 8这套组合兼容性最好网上遇到的坑基本都已经有人踩过资料最全。SpringBoot 3.x 的 jakarta 命名空间变化不大但部分老教程里的 javax 包名会让你复制代码后直接编译报错对新手不友好。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent依赖版本统一交给 parent 管理除非个别包需要覆盖否则不要手动指定版本避免传递依赖冲突。SpringBoot 2.7.x 默认的Maven插件能正常打可执行jar包部署时用java -jar就可以跑。什么情况选 3.x你明确要用的中间件版本只支持 3.x或者你想借这个项目顺便把 jakarta 迁移植也熟悉一下。否则没有必要冒险。2.2 ORM 选 MyBatis-Plus 还是 JPA先想清楚你要“讲”什么电商项目里查询场景多分页、条件筛选、联表查商品和订单MyBatis-Plus 写起来比 JPA 直观也比原生 MyBatis 少写一堆 XML。我强烈建议第一次做电商后端的人选 MyBatis-Plus理由很简单你能把注意力放在业务逻辑本身而不是纠结查询怎么写。MyBatis-Plus 的逻辑删除、自动填充、分页插件三件套正好对应电商后台的常见需求。TableName(product) public class Product { TableId(type IdType.AUTO) private Long id; private String name; private BigDecimal price; private Integer stock; private String imageUrl; private Integer status; TableField(fill FieldFill.INSERT) private LocalDateTime createTime; TableField(fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }逻辑删除默认找deleted字段如果用别的字段名要在配置里指定。自动填充需要实现MetaObjectHandler接口否则createTime不会自己赋值。MyBatis-Plus 分页插件也要显式配置不配置的话Page对象查出来是空的这是新人最容易踩的坑原因其实是分页拦截器没注册。如果你已经能用原生 SQL 顺手写联表查询再考虑 JPA 也不迟。JPA 做关联映射方便但懒加载和 N1 查询问题在答辩时容易被追问讲不清楚反而扣分。2.3 鉴权方案JWT 拦截器就够了别一上来就上 Spring Security电商平台的登录鉴权最朴素的方案是 JWT HandlerInterceptor。不是 Spring Security 不好而是它的过滤器链和安全上下文对第一次做项目的人来说是黑匣子配置错了不知道去哪看日志答辩时也容易被问住。用 JWT你能说出 token 的生成、校验、过期这三件事整个链路清晰可控。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); } // 校验逻辑过期、签名、用户是否存在 // 通过后把用户id放request attribute供Controller取用 return true; } }拦截器只做 token 合法性校验用户的真实信息从 Redis 或数据库补查避免 token 里塞太多敏感数据。JWT 的签名密钥不要写在代码里放到application.yml的配置项中。登录接口返回 token 时要带上用户基础信息前端存起来后续请求头携带。拦截器还顺便解决了写操作权限的基本校验——没有有效 token 的人根本进不了下单接口。3. 数据库设计与表结构落地九张核心表的建表 SQL 和设计理由3.1 电商库的核心是“订单主表 订单项表”这套关系电商平台的表结构大体上可以分成四组用户与权限体系、商品与分类体系、订单与支付体系、购物车等辅助体系。这里分享一套我实际用过的结构一共九张表可以覆盖商品浏览、加购物车、下单、支付回调、订单管理的完整链路。设计上坚持一个原则订单下单项和商品表之间只用productId关联下单时把商品名称和价格快照到订单项里这样商品改价或删除后历史订单不受影响。CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL, password varchar(255) NOT NULL, email varchar(100) DEFAULT NULL, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;用户表密码字段存的是 BCrypt 加密后的密文这一步非常重要——千万不要明文存密码。账号唯一约束要建上注册时先查后插不是原子操作并发下可能插入两条相同用户名记录唯一索引是最后的兜底防线。CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint(20) NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, receiver_name varchar(50) DEFAULT NULL, receiver_phone varchar(20) DEFAULT NULL, receiver_address varchar(255) DEFAULT NULL, pay_time datetime DEFAULT NULL, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单金额用decimal(10,2)而不是 float/double这个属于电商开发的基本常识浮点数存金额累计相加后会出现精度问题涉及钱的字段必须用定点数。order_no要求全局唯一不能用自增id直接当订单号对外暴露否则订单量可以被别人推出来。添加订单表和订单项表之间的外键约束在日常开发中我反而不建议加原因放到最后一章说。CREATE TABLE order_item ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) NOT NULL, product_id bigint(20) NOT NULL, product_name varchar(100) NOT NULL COMMENT 商品名称快照, product_image varchar(255) DEFAULT NULL, current_price decimal(10,2) NOT NULL COMMENT 下单时价格快照, quantity int(11) NOT NULL, PRIMARY KEY (id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;3.2 商品和购物车状态字段的设计能省掉一大堆联表查询商品表product需要状态字段上下架直接改状态不删除记录购物车表cart用user_id product_id做唯一索引相同商品再次添加时走更新数量的逻辑而不是插两条记录。这两个设计非常关键很多教程里为了图省事不建状态字段后面做后台商品管理时就要重写表结构。ALTER TABLE cart ADD UNIQUE KEY uk_user_product (user_id, product_id);分类表category设计成单级就够了不要一上来就做无限级分类。电商项目的分类层级联动的复杂度远超预期单级分类对毕设和学习项目来说完全够用。咨询表或留言表可以放业务扩展场景里加不影响主流程。表建完后用真正的数据跑一遍业务流——注册用户、添加商品、加购、下单、改订单状态核对每个环节有没有缺字段。4. 核心模块代码落地登录、商品搜索和下单事务的教科书式实现4.1 登录与JWT发放密码加密校验和token生成放到一处搞定登录逻辑集中在UserService里Controller 只负责接收参数和返回结果。BCrypt 校验用matches方法密文库里取出后和明文比对。注意JWT 生成时subject存用户 id不要存用户名用户名可能被修改id 不会变。过期时间定 2 小时对学习项目足够。public String login(String username, String password) { User user userMapper.selectOne( new LambdaQueryWrapperUser().eq(User::getUsername, username)); if (user null || !BCrypt.checkpw(password, user.getPassword())) { throw new BizException(用户名或密码错误); } String token JwtUtil.createToken(user.getId(), user.getUsername()); // 可选把token存入Redis设置过期时间实现强制下线 return token; }密码错误和用户不存在返回同样的提示防止别人通过提示差异探测用户名是否注册过。这个细节在答辩时主动说出来能体现安全意识。JWT 天然无状态服务端重启后 token 依然有效这是它和 Session 方案最大的区别——也意味着无法主动让某个 token 失效。如果后续想支持“管理员禁用某用户”就需要把 token 存 Redis校验时查一下这是常见的演进路线。4.2 商品搜索的三种境界关键字匹配、分类筛选、价格排序商品搜索是电商平台的查询门面。用 MyBatis-Plus 的LambdaQueryWrapper可以拼出动态条件不需要手写 XML。搜索接口要支持三个参数keyword商品名模糊匹配、categoryId分类筛选、sort排序方式。排序白名单校验必须做否则前端传一个orderBy字段直接拼到 SQL 里就是典型的 SQL 注入点。public IPageProduct search(Integer categoryId, String keyword, Integer sort, Integer pageNum, Integer pageSize) { LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(categoryId ! null, Product::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(Product::getStatus, 1); // sort: 1按价格升序 2按价格降序 3按销量降序 4按上架时间倒序 switch (sort) { case 1: wrapper.orderByAsc(Product::getPrice); break; case 2: wrapper.orderByDesc(Product::getPrice); break; case 3: wrapper.orderByDesc(Product::getSales); break; default: wrapper.orderByDesc(Product::getCreateTime); } return productMapper.selectPage(new Page(pageNum, pageSize), wrapper); }eq方法配合categoryId ! null条件参数为空时不会拼上这条 SQL这是动态查询的常规写法。排序放在服务层做白名单映射而不是直接接受前端传的排序字段名。商品状态加eq(Product::getStatus, 1)保证下架商品不展示。搜索之外还有分类下的商品列表这个接口可以直接复用传 categoryId 就行。4.3 下单事务扣库存、生成订单、计算总价的完整性保证下单是电商项目的核心事务场景。以单商品下单为例完整流程是查商品 → 校验状态和库存 → 扣减库存 → 生成订单主记录 → 生成订单项记录 → 返回订单号。整个过程必须在一个事务里任何一步失败都要整体回滚否则会出现库存扣了但订单没生成的情况。Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, Long productId, Integer quantity) { Product product productMapper.selectById(productId); if (product null || product.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } // 精确扣减UPDATE语句里带stock quantity条件 int rows productMapper.deductStock(productId, quantity); if (rows 0) { throw new BizException(库存不足); } String orderNo OrderNoGenerator.generate(); BigDecimal total product.getPrice().multiply(BigDecimal.valueOf(quantity)); // 插入订单主表和订单项表 // 返回orderNo给前端支付时用 }deductStock对应一条带条件的 UPDATE SQLUPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}。返回受影响行数0 说明库存不够直接抛异常回滚。这个做法能在单表单商品场景下避免超卖不需要加悲观锁性能也够用。如果后续做多商品下单或者引入 Redis 库存预扣再考虑 Lua 脚本或分布式锁那是第二个阶段的优化方向。下单接口要设置幂等性最简单的做法是前端生成一个clientToken后端收到后先查 Redis 里有没有这个 token有就直接返回上次的订单号否则执行下单逻辑并写入 token过期时间和订单创建时间对齐。否则用户手抖点两次提交就会产生两笔订单。这个细节属于高并发场景的必备意识面试时讲出来非常加分。5. SpringBoot电商项目避坑指南金额精度、并发库存和图片上传的翻车现场5.1 金额字段用错类型float导致的精度玄学现象订单总金额算出来是 39.599999页面显示错误对账不平。原因用过 float 或 double 存单价二进制浮点数无法精确表示十进制小数累加时误差被放大。解决数据库列和 Java 字段统一用decimal/BigDecimal运算用BigDecimal.valueOf()构造禁止用new BigDecimal(double)。这与电商平台金额处理的最基本要求相关任何金额字段从表结构到实体类到运算逻辑整条链路不允许出现浮点类型。5.2 并发扣库存超卖扣减时没带库存条件现象库存只剩 1 件两个人同时下单都成功了。原因先 select 查库存判断大于 0后 update 扣减两步之间存在时间差第二个请求读到旧值。解决把判断并入 UPDATE 的 WHERE 条件一次原子操作完成“判断 扣减”。承不承认这个问题往往是答辩分水岭——只做校验型扣减的同学被追问时容易卡壳用条件更新的人能立刻讲出思路。5.3 本地图片上传后刷新就丢没配虚拟路径映射现象开发环境下图片上传成功刷新页面图片 404。原因图片写到了本地磁盘目录但没有把 URL 映射到该目录SpringBoot 默认只处理 classpath 静态资源。解决实现WebMvcConfigurer的addResourceHandlers方法把/images/**映射到上传目录生产环境用 Nginx 或对象存储不经过应用服务器。文件上传这类场景里本地磁盘方案只能用于开发换到服务器部署时必须换存储方案这是架构演进的自然过程。5.4 JWT 过期时间太短或太长前后端时间同步问题现象用户操作到一半被踢下线或者 token 一个月不过期安全性堪忧。原因过期时间设不合理刷新逻辑也没做。解决token 有效期 2 小时前端在请求拦截器里判断 token 即将过期时调用刷新接口用 refreshToken 换取新 token。实现不复杂但前后端要约定好状态码。5.5 接口文档缺失方法注释和请求参数全靠猜现象前端对接时反复问字段含义参数名是拼音缩写完全看不明白。原因后端没有生成接口文档写完代码就算完事。解决接入 SpringDoc 或 Knife4j在 Controller 类上加注解自动生成在线接口文档。这一步成本极低但能显著减少联调期的无效沟通也是项目加分项。6. 从能跑到能讲二开方向、简历讲法和文档配合技巧项目跑通了只是第一步。如何让它变成简历上站得住的项目以及答辩时能撑住追问是这个阶段的核心问题。我建议往下二开三个方向按性价比排序第一订单超时未支付自动关闭。用定时任务扫订单表即可简单可靠适合学习项目进阶一点用延迟队列或 Redis 过期监听能引出消息中间件的扩展话题。第二多商品下单。核心改动在下单事务校验多个商品库存和状态批量扣减订单表存总金额订单项表存多个记录。这能引出事务边界和分布式事务的讨论。第三秒杀接口。Redis 预扣库存 Lua 脚本实际扣减走一遍流程商品详情接口加 Redis 缓存。这个方向是面试高频考点。文档配合上要做三件事。设计文档写清楚表结构设计的理由特别是订单为什么冗余商品快照接口文档把每个接口的入参、出参、错误码列全部署文档写清 JDK 版本、MySQL 版本、初始化数据脚本的执行顺序。答辩或者面试时按“整体架构 → 数据库设计 → 核心模块实现 → 踩过的坑与优化”四层讲每层都能对应到你写过的代码和文档。这套方案从选型到落地走的是一条经过多次验证的生产路线。最后分享两个习惯一是写完接口先自己用 curl 或 Postman 过一遍完整链路再交给前端二是 SQL 改过表结构后一定要把schema.sql同步更新。我吃过一次亏——改过购物车表后没更新初始化脚本换了台电脑环境重建库时翻车排查了一个小时才找到原因从那以后再也没敢偷懒。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/17 20:50:13 · 阅读 1.2k SpringBoot电商平台项目实战：从数据库设计到订单并发避坑指南
简介基于SpringBoot的电商平台设计与实现资源包以毕业设计论文形式呈现覆盖课题背景、系统分析、开发环境、系统设计等章节完整还原项目从需求到落地的思路。资源面向计算机相关专业学生可作为毕业设计、课程设计或实训项目的参考范本重点解决传统商品交易信息管理效率低、容错率低等痛点。系统功能涵盖商家管理、用户管理、商品上下架与库存、订单管理、商品评价、购物车、订单支付及物流跟踪等模块技术方案选用Mysql数据库存储用户、商品、订单等核心数据利用Java语言的跨平台特性与Spring Boot框架简化配置、提升开发效率。整份资源仅包含1个doc文件压缩包大小4.5MB文件虽少但内容紧凑以论文加核心代码段落的形式集中呈现了系统设计思路、数据库方案与实现细节便于快速对照改写。目前已有35人学习适合需要掌握Spring Boot电商项目结构、撰写毕设文档或借鉴功能设计的开发者参考。1. 基于SpringBoot电商平台为什么这个老选题还是年年有人抢着做后台管理系统 商品浏览 购物车 下单支付这套基于SpringBoot的电商平台几乎每年都是毕业设计和自学项目里出现频率最高的选题之一。很多人觉得它太常见、没新意但真正动手的人会发现把商品列表跑通不难难的是订单状态机怎么设计、并发扣库存怎么不超卖、支付回调怎么验签、本地图片上传后刷新就丢怎么兜底。这些问题恰恰是电商项目区别于普通CRUD的价值所在。我见过太多人在答辩前一周还在改订单状态的bug也见过不少人照着开源商城敲了一遍简历上写“熟悉电商秒杀场景”问到Redis原子操作却说不出所以然。这篇笔记想把一条能跑通、能讲清、能二开的路径讲透从环境选型和表结构设计开始到JWT登录、商品搜索、下单事务三个核心模块的代码落地再给出几个必踩的坑和对应解法最后聊聊二开方向和文档怎么配合。适合谁正在做毕设的技术学生或者想往电商后端方向求职、需要一个拿得出手的项目储备的人。前者照着能做完后者能从中提炼出可讲的难点和优化点。两种目标不同但起点一致先让它本地跑起来。2. 开工前的选型与技术决策SpringBoot版本、ORM和鉴权方案怎么定2.1 SpringBoot版本选哪个稳定优先还是新特性优先电商项目不像中间件研发不需要追最新版本。SpringBoot 3.x 已经成熟但如果你在本地用的是 JDK 8那只能选 2.7.x如果环境是 JDK 17 及以上3.x 是更合理的选择。我在实际带项目时一般这么定默认 SpringBoot 2.7.18 JDK 8这套组合兼容性最好网上遇到的坑基本都已经有人踩过资料最全。SpringBoot 3.x 的 jakarta 命名空间变化不大但部分老教程里的 javax 包名会让你复制代码后直接编译报错对新手不友好。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent依赖版本统一交给 parent 管理除非个别包需要覆盖否则不要手动指定版本避免传递依赖冲突。SpringBoot 2.7.x 默认的Maven插件能正常打可执行jar包部署时用java -jar就可以跑。什么情况选 3.x你明确要用的中间件版本只支持 3.x或者你想借这个项目顺便把 jakarta 迁移植也熟悉一下。否则没有必要冒险。2.2 ORM 选 MyBatis-Plus 还是 JPA先想清楚你要“讲”什么电商项目里查询场景多分页、条件筛选、联表查商品和订单MyBatis-Plus 写起来比 JPA 直观也比原生 MyBatis 少写一堆 XML。我强烈建议第一次做电商后端的人选 MyBatis-Plus理由很简单你能把注意力放在业务逻辑本身而不是纠结查询怎么写。MyBatis-Plus 的逻辑删除、自动填充、分页插件三件套正好对应电商后台的常见需求。TableName(product) public class Product { TableId(type IdType.AUTO) private Long id; private String name; private BigDecimal price; private Integer stock; private String imageUrl; private Integer status; TableField(fill FieldFill.INSERT) private LocalDateTime createTime; TableField(fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }逻辑删除默认找deleted字段如果用别的字段名要在配置里指定。自动填充需要实现MetaObjectHandler接口否则createTime不会自己赋值。MyBatis-Plus 分页插件也要显式配置不配置的话Page对象查出来是空的这是新人最容易踩的坑原因其实是分页拦截器没注册。如果你已经能用原生 SQL 顺手写联表查询再考虑 JPA 也不迟。JPA 做关联映射方便但懒加载和 N1 查询问题在答辩时容易被追问讲不清楚反而扣分。2.3 鉴权方案JWT 拦截器就够了别一上来就上 Spring Security电商平台的登录鉴权最朴素的方案是 JWT HandlerInterceptor。不是 Spring Security 不好而是它的过滤器链和安全上下文对第一次做项目的人来说是黑匣子配置错了不知道去哪看日志答辩时也容易被问住。用 JWT你能说出 token 的生成、校验、过期这三件事整个链路清晰可控。Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { token token.substring(7); } // 校验逻辑过期、签名、用户是否存在 // 通过后把用户id放request attribute供Controller取用 return true; } }拦截器只做 token 合法性校验用户的真实信息从 Redis 或数据库补查避免 token 里塞太多敏感数据。JWT 的签名密钥不要写在代码里放到application.yml的配置项中。登录接口返回 token 时要带上用户基础信息前端存起来后续请求头携带。拦截器还顺便解决了写操作权限的基本校验——没有有效 token 的人根本进不了下单接口。3. 数据库设计与表结构落地九张核心表的建表 SQL 和设计理由3.1 电商库的核心是“订单主表 订单项表”这套关系电商平台的表结构大体上可以分成四组用户与权限体系、商品与分类体系、订单与支付体系、购物车等辅助体系。这里分享一套我实际用过的结构一共九张表可以覆盖商品浏览、加购物车、下单、支付回调、订单管理的完整链路。设计上坚持一个原则订单下单项和商品表之间只用productId关联下单时把商品名称和价格快照到订单项里这样商品改价或删除后历史订单不受影响。CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL, password varchar(255) NOT NULL, email varchar(100) DEFAULT NULL, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;用户表密码字段存的是 BCrypt 加密后的密文这一步非常重要——千万不要明文存密码。账号唯一约束要建上注册时先查后插不是原子操作并发下可能插入两条相同用户名记录唯一索引是最后的兜底防线。CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, user_id bigint(20) NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, receiver_name varchar(50) DEFAULT NULL, receiver_phone varchar(20) DEFAULT NULL, receiver_address varchar(255) DEFAULT NULL, pay_time datetime DEFAULT NULL, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单金额用decimal(10,2)而不是 float/double这个属于电商开发的基本常识浮点数存金额累计相加后会出现精度问题涉及钱的字段必须用定点数。order_no要求全局唯一不能用自增id直接当订单号对外暴露否则订单量可以被别人推出来。添加订单表和订单项表之间的外键约束在日常开发中我反而不建议加原因放到最后一章说。CREATE TABLE order_item ( id bigint(20) NOT NULL AUTO_INCREMENT, order_id bigint(20) NOT NULL, product_id bigint(20) NOT NULL, product_name varchar(100) NOT NULL COMMENT 商品名称快照, product_image varchar(255) DEFAULT NULL, current_price decimal(10,2) NOT NULL COMMENT 下单时价格快照, quantity int(11) NOT NULL, PRIMARY KEY (id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;3.2 商品和购物车状态字段的设计能省掉一大堆联表查询商品表product需要状态字段上下架直接改状态不删除记录购物车表cart用user_id product_id做唯一索引相同商品再次添加时走更新数量的逻辑而不是插两条记录。这两个设计非常关键很多教程里为了图省事不建状态字段后面做后台商品管理时就要重写表结构。ALTER TABLE cart ADD UNIQUE KEY uk_user_product (user_id, product_id);分类表category设计成单级就够了不要一上来就做无限级分类。电商项目的分类层级联动的复杂度远超预期单级分类对毕设和学习项目来说完全够用。咨询表或留言表可以放业务扩展场景里加不影响主流程。表建完后用真正的数据跑一遍业务流——注册用户、添加商品、加购、下单、改订单状态核对每个环节有没有缺字段。4. 核心模块代码落地登录、商品搜索和下单事务的教科书式实现4.1 登录与JWT发放密码加密校验和token生成放到一处搞定登录逻辑集中在UserService里Controller 只负责接收参数和返回结果。BCrypt 校验用matches方法密文库里取出后和明文比对。注意JWT 生成时subject存用户 id不要存用户名用户名可能被修改id 不会变。过期时间定 2 小时对学习项目足够。public String login(String username, String password) { User user userMapper.selectOne( new LambdaQueryWrapperUser().eq(User::getUsername, username)); if (user null || !BCrypt.checkpw(password, user.getPassword())) { throw new BizException(用户名或密码错误); } String token JwtUtil.createToken(user.getId(), user.getUsername()); // 可选把token存入Redis设置过期时间实现强制下线 return token; }密码错误和用户不存在返回同样的提示防止别人通过提示差异探测用户名是否注册过。这个细节在答辩时主动说出来能体现安全意识。JWT 天然无状态服务端重启后 token 依然有效这是它和 Session 方案最大的区别——也意味着无法主动让某个 token 失效。如果后续想支持“管理员禁用某用户”就需要把 token 存 Redis校验时查一下这是常见的演进路线。4.2 商品搜索的三种境界关键字匹配、分类筛选、价格排序商品搜索是电商平台的查询门面。用 MyBatis-Plus 的LambdaQueryWrapper可以拼出动态条件不需要手写 XML。搜索接口要支持三个参数keyword商品名模糊匹配、categoryId分类筛选、sort排序方式。排序白名单校验必须做否则前端传一个orderBy字段直接拼到 SQL 里就是典型的 SQL 注入点。public IPageProduct search(Integer categoryId, String keyword, Integer sort, Integer pageNum, Integer pageSize) { LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(categoryId ! null, Product::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(Product::getStatus, 1); // sort: 1按价格升序 2按价格降序 3按销量降序 4按上架时间倒序 switch (sort) { case 1: wrapper.orderByAsc(Product::getPrice); break; case 2: wrapper.orderByDesc(Product::getPrice); break; case 3: wrapper.orderByDesc(Product::getSales); break; default: wrapper.orderByDesc(Product::getCreateTime); } return productMapper.selectPage(new Page(pageNum, pageSize), wrapper); }eq方法配合categoryId ! null条件参数为空时不会拼上这条 SQL这是动态查询的常规写法。排序放在服务层做白名单映射而不是直接接受前端传的排序字段名。商品状态加eq(Product::getStatus, 1)保证下架商品不展示。搜索之外还有分类下的商品列表这个接口可以直接复用传 categoryId 就行。4.3 下单事务扣库存、生成订单、计算总价的完整性保证下单是电商项目的核心事务场景。以单商品下单为例完整流程是查商品 → 校验状态和库存 → 扣减库存 → 生成订单主记录 → 生成订单项记录 → 返回订单号。整个过程必须在一个事务里任何一步失败都要整体回滚否则会出现库存扣了但订单没生成的情况。Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, Long productId, Integer quantity) { Product product productMapper.selectById(productId); if (product null || product.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } // 精确扣减UPDATE语句里带stock quantity条件 int rows productMapper.deductStock(productId, quantity); if (rows 0) { throw new BizException(库存不足); } String orderNo OrderNoGenerator.generate(); BigDecimal total product.getPrice().multiply(BigDecimal.valueOf(quantity)); // 插入订单主表和订单项表 // 返回orderNo给前端支付时用 }deductStock对应一条带条件的 UPDATE SQLUPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}。返回受影响行数0 说明库存不够直接抛异常回滚。这个做法能在单表单商品场景下避免超卖不需要加悲观锁性能也够用。如果后续做多商品下单或者引入 Redis 库存预扣再考虑 Lua 脚本或分布式锁那是第二个阶段的优化方向。下单接口要设置幂等性最简单的做法是前端生成一个clientToken后端收到后先查 Redis 里有没有这个 token有就直接返回上次的订单号否则执行下单逻辑并写入 token过期时间和订单创建时间对齐。否则用户手抖点两次提交就会产生两笔订单。这个细节属于高并发场景的必备意识面试时讲出来非常加分。5. SpringBoot电商项目避坑指南金额精度、并发库存和图片上传的翻车现场5.1 金额字段用错类型float导致的精度玄学现象订单总金额算出来是 39.599999页面显示错误对账不平。原因用过 float 或 double 存单价二进制浮点数无法精确表示十进制小数累加时误差被放大。解决数据库列和 Java 字段统一用decimal/BigDecimal运算用BigDecimal.valueOf()构造禁止用new BigDecimal(double)。这与电商平台金额处理的最基本要求相关任何金额字段从表结构到实体类到运算逻辑整条链路不允许出现浮点类型。5.2 并发扣库存超卖扣减时没带库存条件现象库存只剩 1 件两个人同时下单都成功了。原因先 select 查库存判断大于 0后 update 扣减两步之间存在时间差第二个请求读到旧值。解决把判断并入 UPDATE 的 WHERE 条件一次原子操作完成“判断 扣减”。承不承认这个问题往往是答辩分水岭——只做校验型扣减的同学被追问时容易卡壳用条件更新的人能立刻讲出思路。5.3 本地图片上传后刷新就丢没配虚拟路径映射现象开发环境下图片上传成功刷新页面图片 404。原因图片写到了本地磁盘目录但没有把 URL 映射到该目录SpringBoot 默认只处理 classpath 静态资源。解决实现WebMvcConfigurer的addResourceHandlers方法把/images/**映射到上传目录生产环境用 Nginx 或对象存储不经过应用服务器。文件上传这类场景里本地磁盘方案只能用于开发换到服务器部署时必须换存储方案这是架构演进的自然过程。5.4 JWT 过期时间太短或太长前后端时间同步问题现象用户操作到一半被踢下线或者 token 一个月不过期安全性堪忧。原因过期时间设不合理刷新逻辑也没做。解决token 有效期 2 小时前端在请求拦截器里判断 token 即将过期时调用刷新接口用 refreshToken 换取新 token。实现不复杂但前后端要约定好状态码。5.5 接口文档缺失方法注释和请求参数全靠猜现象前端对接时反复问字段含义参数名是拼音缩写完全看不明白。原因后端没有生成接口文档写完代码就算完事。解决接入 SpringDoc 或 Knife4j在 Controller 类上加注解自动生成在线接口文档。这一步成本极低但能显著减少联调期的无效沟通也是项目加分项。6. 从能跑到能讲二开方向、简历讲法和文档配合技巧项目跑通了只是第一步。如何让它变成简历上站得住的项目以及答辩时能撑住追问是这个阶段的核心问题。我建议往下二开三个方向按性价比排序第一订单超时未支付自动关闭。用定时任务扫订单表即可简单可靠适合学习项目进阶一点用延迟队列或 Redis 过期监听能引出消息中间件的扩展话题。第二多商品下单。核心改动在下单事务校验多个商品库存和状态批量扣减订单表存总金额订单项表存多个记录。这能引出事务边界和分布式事务的讨论。第三秒杀接口。Redis 预扣库存 Lua 脚本实际扣减走一遍流程商品详情接口加 Redis 缓存。这个方向是面试高频考点。文档配合上要做三件事。设计文档写清楚表结构设计的理由特别是订单为什么冗余商品快照接口文档把每个接口的入参、出参、错误码列全部署文档写清 JDK 版本、MySQL 版本、初始化数据脚本的执行顺序。答辩或者面试时按“整体架构 → 数据库设计 → 核心模块实现 → 踩过的坑与优化”四层讲每层都能对应到你写过的代码和文档。这套方案从选型到落地走的是一条经过多次验证的生产路线。最后分享两个习惯一是写完接口先自己用 curl 或 Postman 过一遍完整链路再交给前端二是 SQL 改过表结构后一定要把schema.sql同步更新。我吃过一次亏——改过购物车表后没更新初始化脚本换了台电脑环境重建库时翻车排查了一个小时才找到原因从那以后再也没敢偷懒。希望帮到你。本文还有配套的精品资源点击获取