SpringBoot电商平台实战：从建表到下单链路，避开超卖与幂等坑

简介这份资源是面向计算机专业学生与Java Web开发初学者的电商平台毕业设计完整资料包含设计文档与项目源码可用于课程设计、毕业设计参考或Spring Boot入门实战。压缩包内共1个doc文件约4.5MB文档涵盖绪论、开发环境与技术、系统分析、数据库设计及功能实现等章节系统梳理了从需求分析到编码落地的完整流程。项目采用Java语言、MySQL数据库与Spring Boot框架实现功能覆盖商家管理、商品与订单管理、用户管理、商品评价管理并延伸至购物车、订单支付与物流跟踪等模块文档中对各模块的表结构设计与业务逻辑均有说明。目前已有35人学习下载适合需要一份结构完整、技术栈主流的电商项目方案作为参考的读者可据此理解Spring Boot项目的分层组织方式与数据库设计思路并在此基础上进行二次开发或功能扩展。1. 从一份 kaic.doc 说起SpringBoot 电商平台到底要落地哪些东西很多人拿到「基于SpringBoot电商平台的设计与实现(文档源码)」这类标题第一反应是去搜一份能跑的代码结果下载下来发现只有几个实体类和一个空荡荡的 Controller。真正卡住人的从来不是 SpringBoot 本身而是电商这个业务域里那些绕不开的硬骨头商品 SKU 怎么建模、订单状态机怎么收敛、库存扣减怎么保证不超卖、支付回调怎么做到幂等。这份文档加源码的组合价值不在于「能跑」而在于它把一套完整的业务闭环拆成了可复现的工程结构。适合谁看适合已经会写增删改查、但第一次独立扛一个电商后端的人也适合课程设计需要交付完整文档加源码的同学。接下来我按自己做过几套类似系统的经验把从建表到下单链路的落地路径讲清楚参数怎么设、坑在哪都摊开说。2. 先把领域模型定死商品、订单、库存三张核心表的字段设计电商系统的地基是表结构表结构错了后面全是补丁。我见过太多项目把商品和 SKU 塞在一张表里结果一个商品多个规格时价格和库存全乱套。正确的做法是 SPU 和 SKU 分离SPU 管描述性信息SKU 管可售单元。2.1 SPU 与 SKU 的拆分逻辑与建表语句SPUStandard Product Unit是标准化产品单元比如「iPhone 15」SKUStock Keeping Unit是库存进出计量的最小单位比如「iPhone 15 128G 黑色」。用户下单买的是 SKU不是 SPU。这个区分决定了价格、库存、订单明细全部挂在 SKU 上。-- 商品 SPU 表只存与规格无关的描述信息 CREATE TABLE product_spu ( id bigint NOT NULL AUTO_INCREMENT, name varchar(128) NOT NULL COMMENT 商品名称, category_id bigint NOT NULL COMMENT 分类ID, brand_id bigint DEFAULT NULL COMMENT 品牌ID, description text COMMENT 商品详情, status tinyint DEFAULT 0 COMMENT 0下架 1上架, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 商品 SKU 表价格和库存的真正载体 CREATE TABLE product_sku ( id bigint NOT NULL AUTO_INCREMENT, spu_id bigint NOT NULL COMMENT 所属SPU, sku_code varchar(64) NOT NULL COMMENT SKU编码全局唯一, specs json DEFAULT NULL COMMENT 规格JSON如{颜色:黑色,容量:128G}, price decimal(10,2) NOT NULL COMMENT 售价, stock int NOT NULL DEFAULT 0 COMMENT 可售库存, locked_stock int NOT NULL DEFAULT 0 COMMENT 锁定库存, PRIMARY KEY (id), UNIQUE KEY uk_sku_code (sku_code), KEY idx_spu (spu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明specs用 JSON 字段存规格好处是新增规格维度不用改表结构查询时用 MySQL 的 JSON 函数提取。stock和locked_stock分开是关键下单时锁库存而不是直接扣支付成功才真正扣减取消订单则释放锁定。参数说明price用decimal(10,2)而不是float金额计算绝不能用浮点。sku_code加唯一索引防止重复铺货。locked_stock默认 0所有扣减操作走UPDATE ... SET stock stock - N, locked_stock locked_stock N WHERE stock N靠数据库行锁保证原子性。2.2 订单主表与明细表的状态字段设计订单表最容易翻车的地方是状态字段。很多人用一个status字段表示所有状态结果退款、发货、完成全挤在一起查询条件写成一团乱麻。我的做法是主表存订单级状态明细表存商品级状态两者独立演进。CREATE TABLE order_main ( 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, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消 5已退款, pay_time datetime DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_status (user_id,status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order_item ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL, sku_id bigint NOT NULL, sku_price decimal(10,2) NOT NULL COMMENT 下单时快照价格, quantity int NOT NULL, item_status tinyint DEFAULT 0 COMMENT 0正常 1退款中 2已退款, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明order_item里的sku_price是下单那一刻的价格快照不能关联查 SKU 当前价否则商品调价后历史订单金额就变了。order_no用唯一索引配合业务侧生成的规则比如时间戳加用户ID后四位防止重复提交。参数说明status用 tinyint 而不是 varchar索引效率高。idx_user_status联合索引支撑「我的订单」按状态筛选的高频查询。pay_amount和total_amount分开为后续优惠券、积分抵扣留扩展位。3. 下单链路的三个关键动作锁库存、生成订单、支付回调表建好只是开始真正决定系统能不能用的是下单这条链路。我把它拆成三个动作每个动作都有对应的失败场景和补偿逻辑。3.1 用乐观锁加库存预占实现不超卖超卖是电商最经典的问题。两个人同时买最后一件不加控制就会都下单成功。常见做法有两种悲观锁SELECT ... FOR UPDATE和乐观锁版本号或条件更新。高并发下悲观锁会拖垮数据库我一般用条件更新做乐观锁。// SKU 库存扣减条件更新保证原子性 Update(UPDATE product_sku SET stock stock - #{qty}, locked_stock locked_stock #{qty} WHERE id #{skuId} AND stock #{qty}) int lockStock(Param(skuId) Long skuId, Param(qty) Integer qty);逻辑说明这条 SQL 的WHERE stock #{qty}是灵魂。数据库执行更新时会加行锁两个并发请求串行执行第一个扣完 stock 变成 0第二个的stock qty不成立返回影响行数 0业务层据此判断库存不足并回滚。整个过程不需要显式加锁靠 InnoDB 的行锁和条件判断完成。参数说明qty是购买数量必须大于 0业务层要校验。返回值是影响行数等于 1 表示锁定成功等于 0 表示库存不足。注意这个方法要在事务里调用锁定库存和生成订单要么都成功要么都失败。3.2 订单号生成与重复提交的幂等处理订单号生成看似简单实际坑很多。用数据库自增 ID 会暴露业务量用 UUID 又太长影响索引。我一般用「时间戳 用户ID后四位 随机数」的组合长度控制在 32 位以内。public String generateOrderNo(Long userId) { // 时间戳到秒保证趋势递增 String ts String.valueOf(System.currentTimeMillis() / 1000); // 用户ID后四位便于排查问题时定位用户 String uid String.format(%04d, userId % 10000); // 三位随机数降低同一秒内碰撞概率 String rand String.format(%03d, ThreadLocalRandom.current().nextInt(1000)); return ts uid rand; }逻辑说明时间戳保证订单号整体递增对 B 树索引友好。用户ID后四位让运维能快速定位订单归属。随机数解决同一用户同一秒多次下单的碰撞。生成后插入数据库靠uk_order_no唯一索引兜底插入失败就重试一次。参数说明userId % 10000取后四位如果用户量超过一万会有重复但配合时间戳和随机数实际碰撞概率极低。重试次数建议设为 1 次避免无限循环。前端提交按钮要做防抖后端接口用 token 机制防重复提交。3.3 支付回调的验签与状态机流转支付回调是外部系统触发的必须做验签和幂等。我见过有人直接把回调参数拿来更新订单状态结果被伪造请求刷了一堆已支付订单。正确流程是验签 → 查订单 → 判断状态 → 更新 → 返回成功。Transactional public String handlePayCallback(PayCallbackDTO dto) { // 1. 验签失败直接返回不处理 if (!payService.verifySign(dto)) { return FAIL; } // 2. 查询订单加行锁防止并发回调 OrderMain order orderMapper.selectForUpdate(dto.getOrderNo()); if (order null) { return FAIL; } // 3. 幂等判断已支付或已取消的订单不再处理 if (order.getStatus() ! OrderStatus.UNPAID.getCode()) { return SUCCESS; } // 4. 更新订单状态和支付时间 orderMapper.updateStatus(order.getId(), OrderStatus.PAID.getCode(), new Date()); // 5. 扣减锁定库存转为实际扣减 skuService.confirmStock(order.getId()); return SUCCESS; }逻辑说明selectForUpdate加行锁防止支付平台重复回调时两个线程同时读到待支付状态。幂等判断放在锁内确保只有一个线程能推进状态。返回SUCCESS告诉支付平台不用再重试返回FAIL则会触发重试。参数说明PayCallbackDTO包含订单号、支付流水号、金额、签名等字段。验签用支付平台提供的公钥金额要核对是否与订单pay_amount一致不一致说明被篡改。confirmStock把locked_stock减掉完成库存的最终扣减。4. 避坑与排查那些文档里不会写的血泪经验这一章是我踩过的坑每条都对应真实故障。文档和源码通常只给正确路径但生产环境出问题时能救你的往往是这些排查思路。4.1 事务失效导致库存扣了订单没生成现象用户下单后库存少了但订单列表里查不到订单。原因Transactional注解加在 private 方法上或者同类内部方法调用Spring AOP 代理不生效事务根本没开。解决确保事务方法都是 public且通过注入的代理对象调用。排查时在方法入口打日志看是否进入事务。更隐蔽的一种是异常被 catch 吞掉事务不回滚这种要在 catch 里手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。4.2 支付回调重复执行导致库存多扣现象一笔订单支付成功后库存被扣了两次。原因支付平台在没收到SUCCESS响应时会重试回调如果第一次回调处理成功但响应超时第二次回调又进来幂等判断没做好就会重复扣。解决幂等判断必须在行锁内做且判断依据是订单状态而不是支付流水号。另外confirmStock方法本身也要幂等用UPDATE ... WHERE locked_stock qty做条件更新。4.3 JSON 规格字段查询慢拖垮商品列表现象商品列表接口响应从 50ms 涨到 2s。原因用specs-$.颜色这种 JSON 函数做筛选无法走索引全表扫描。解决如果规格筛选是高频需求把常用规格维度抽成独立列加索引JSON 只存不参与查询的扩展信息。或者引入 Elasticsearch 做商品搜索MySQL 只存基础数据。这个决策要在项目初期做后期改代价很大。4.4 订单号唯一索引冲突导致下单失败现象高峰期偶发下单失败日志报Duplicate entry。原因订单号生成规则在同一秒内碰撞唯一索引拦截。解决随机数位数从 3 位加到 4 位或者引入 Redis 自增序列。更稳妥的做法是订单号生成后先查一次数据库存在则重新生成虽然多一次查询但能彻底避免冲突。注意重试要有次数上限避免死循环。4.5 金额计算用 double 导致对账差几分钱现象订单实付金额和支付平台对账差 0.01 元。原因Java 里用double做金额加减浮点精度丢失。解决所有金额字段用BigDecimal数据库用decimal。BigDecimal比较用compareTo而不是equals因为equals会比较精度。乘除时指定RoundingMode.HALF_UP避免银行家舍入带来的差异。5. 从能跑到能扛压测验证与几个提效技巧系统跑通之后下一步是验证它能不能扛住真实流量。我一般用 JMeter 或 wrk 对下单接口做压测重点看三个指标TPS、错误率、库存扣减的准确性。压测时把库存设成一个固定值比如 1000然后用 200 个并发线程各下单 10 次跑完后检查订单数是否等于 1000库存是否归零。如果订单数大于 1000说明超卖没防住如果小于 1000说明有请求被误杀。压测环境要和生产环境配置接近尤其是数据库连接池大小。SpringBoot 默认 HikariCP 最大连接数是 10压测时很容易成为瓶颈。我一般调到 CPU 核数乘以 2 再加磁盘数比如 8 核机器设 20 左右。同时把connection-timeout设成 3000ms避免请求堆积。spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000参数说明maximum-pool-size是最大连接数设太大反而增加数据库上下文切换开销。connection-timeout是获取连接的超时时间设短一点让请求快速失败而不是排队。max-lifetime要小于数据库的wait_timeout避免连接被数据库单方面关闭后报错。另一个提效技巧是给热点商品做本地缓存。商品详情页的 SKU 信息读多写少用 Caffeine 做一级缓存Redis 做二级缓存能挡掉大部分数据库查询。但库存字段不能缓存必须实时查库否则超卖防不住。缓存更新策略用「失效」而不是「更新」商品变更时删掉缓存下次读取时重建。验证库存准确性还有一个笨办法但很有效压测前后各跑一次SELECT SUM(stock) SUM(locked_stock) FROM product_sku看总量是否守恒。如果压测后总量少了说明有库存被扣了但订单没生成事务回滚有问题如果多了说明有订单生成了但库存没扣锁库存逻辑有漏洞。这个对账思路在真实故障排查时也管用。最后说个习惯每次改完下单链路我都会手动模拟三种异常——库存不足、支付回调重复、订单号冲突确认系统能正确处理再提交代码。这三条路径覆盖了 90% 的线上故障场景比写一堆单元测试更直接。希望帮到你。本文还有配套的精品资源点击获取