Spring Boot社区团购系统源码：从模块拆解到部署踩坑全解析

简介这是一份基于 SpringBoot 与 Vue 的社区团购系统完整源码面向 Java 初学者、毕业设计开发者以及需要快速搭建社区团购平台的工程师。项目涵盖用户端和管理端实现商品管理、订单处理、用户信息管理、图片素材与视频素材管理等功能技术栈涉及 SpringBoot、MyBatisPlus、MySQL、Maven、AJAX、ElementUI 等前后端分离采用 B/S 架构。资源包共 810 个文件压缩后约 16.06MB包含 130 个 Java 后端代码、48 个 Vue 前端组件、153 个 JavaScript 脚本、162 个 SVG 图标资源以及 HTML/CSS/XML/配置文件等目录结构清晰并附有安装、运行、构建的 bat 脚本方便本地直接部署调试。同时提供数据库文件、项目配置及文档资料。目前已有 240 人学习下载适合用来理解 SpringBoot 与 Vue 整合开发流程也可作为毕业设计或课程项目的参考蓝本直接在其基础上扩展功能或修改业务逻辑。1. 社区团购系统为什么 Spring Boot 是这个方向最稳妥的选择社区团购系统说白了就是“预售 集采 自提”的电商模型用户今天下单平台明天统一采购货到团长自提点用户下班顺路取走。这套系统要管的不只是商品和订单还有团长佣金、自提点、小区级配送批次、售后核销。如果你正在找一套基于 Spring Boot 的社区团购系统源码或者在评估这个方向能不能用 Java 自研我可以直接给你结论Spring Boot 做这个业务是够用的而且比微服务那一套更实际。这套系统的核心矛盾不在高并发而在业务状态多一个订单要经历支付、采购、到货、核销、售后五个阶段每个阶段都牵扯库存、资金和佣金。Spring Boot 的生态成熟、上手快MyBatis-Plus 做数据层、Redis 扛热点、定时任务跑日报表一个人就能撑起一个区域的业务。适合的人群也很明确接私活要交付的 Java 工程师、打算给社区生鲜业务做信息化的创业者、以及想拿一套完整业务源码练手的新手。下面我从模块拆解、数据模型、核心代码到部署踩坑把这套系统完整讲一遍。2. 从业务到模块拆分社区团购系统源码里必须有哪几个端社区团购不是简单地把淘宝搬到微信里它的业务链路决定了系统必须拆成用户端、团长端、管理端三条线。很多第一次做这个方向的人上来就写商品和订单两个模块等做到团长佣金和对账时才发现数据库设计得推翻重来。我在这里先把业务模块讲透因为模块边界就是将来数据库表边界。2.1 用户端、团长端、管理端三方角色的权限边界用户端不是一个独立的 Spring Boot 项目而是一组 Controller 和 Service 的组合。用户能做的事浏览商品、发起拼团、支付、申请退款、核销提货码。这里最容易被忽略的是“核销”这个动作——用户在团长那里取货时团长扫用户的提货码完成核销这个操作要落在团长端而不是用户端。团长端的核心是佣金管理。社区团购的团长承担了自提点、二次分拣和售后安抚的职责所以佣金不再是简单的“卖一单提一单”而是要按订单实付金额、售后扣减、批量结算周期三件事联动。设计团长端时我一般会把“可提现佣金”和“结算中佣金”拆成两个字段而不是只存一个总佣金否则月底对账时会很痛苦。管理端则是标准的后台管理系统商品上下架、采购单生成、小区自提点维护、团长审核、财务对账。Spring Boot 里我用 Sa-Token 或者 Spring Security 做三个端各自的登录和权限拦截。需要注意一点三个端的用户表尽量分开或者至少用 user_type 字段区分不要把团长和普通用户混在同一张表里后面做佣金结算的 SQL 会绕很多弯。2.2 Spring Boot 技术栈选型为什么不是 Spring Cloud也不是 PHP社区团购系统的并发量级绝大多数区域运营一天几千单峰值也就每秒几十个请求。这个量级用 Spring Boot 单体应用加 Redis 缓存完全能扛住强行上 Spring Cloud 会让开发和部署成本翻倍。Spring Boot 在这个场景下的优势有两点第一自动配置让 MyBatis-Plus、Redis、定时任务这些组件十五分钟内全部接好第二打包成 fat jar 后部署到一台 4C8G 的服务器上就能跑一整个区域的业务。技术栈上我推荐的是 Spring Boot 2.7.x MyBatis-Plus 3.5.x Redis MySQL 5.7 或 8.0。不用最新的 Spring Boot 3.x因为 Spring Boot 3 强制要求 JDK 17而且很多老的依赖和兼容性问题会拖慢交付节奏。如果源码包里给你的就是 Spring Boot 2.x那就更别折腾升级。Java 版本选 JDK 8 或 11这是目前大量生产环境仍在用的版本踩坑资料也最多。注意Spring Boot 版本不是越高越好。社区团购系统的核心价值在业务逻辑闭环不在框架版本新。2.7.x 足够遇到“springboot版本太高”导致依赖冲突时降回 2.7.x 反而省事。2.3 核心表结构一张表清单看清数据模型数据模型是整个系统能不能落地的关键。我按业务链路整理出下面这张表清单照着建库就行字段细节在后面讲代码时再补充。模块表名关键字段说明用户user用户 id、手机号、微信 openid、所在小区、余额团长group_leader团长 id、审核状态、自提点 id、佣金比例自提点pickup_point小区名、地址、经纬度、负责人手机号商品product商品名、售价、采购价、库存、单位、起购数量商品规格product_sku商品 id、规格名、售价、库存订单order订单号、用户 id、团长 id、实付金额、状态订单明细order_item订单 id、商品 id、数量、单价、小计购物车cart用户 id、商品 id、数量、选中状态佣金流水commission_log团长 id、订单 id、金额、状态、结算时间售后refund_record订单 id、退款金额、原因、处理状态采购单purchase_order商品 id、预计采购量、采购价、状态这里要特别强调 order_item 和 commission_log 这两张表。order_item 里的商品快照商品名、单价一定要冗余一份因为商品改价后历史订单不能被影响commission_log 要记录佣金计算时的订单实付金额和当时佣金比例这样售后发生时只冲正这笔流水不影响其他订单。3. 数据模型与核心代码把订单、库存、佣金三条链路写透模块想清楚了接下来就是动手写代码。这一章我给出一套可复现的核心代码从数据库建表开始到订单下单、库存扣减、佣金计算三个核心服务。这套代码的组织方式是我做过几个同类项目后固定下来的结构目录层级按 springboot 项目结构来任何人接手都能三分钟定位到对应代码。3.1 建表脚本与 MyBatis-Plus 逆向工程配置先用一段 SQL 把两个最核心的表建出来——订单表和佣金流水表这两张表的设计决定了后续百分之八十的业务能顺畅跑。CREATE TABLE t_order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号规则是日期随机数, user_id bigint NOT NULL COMMENT 用户ID, leader_id bigint NOT NULL COMMENT 团长ID决定自提点和佣金归属, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额优惠后, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已采购 3待到货 4待核销 5已完成 6已退款, pickup_code varchar(6) DEFAULT NULL COMMENT 核销码6位数字, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_leader_id (leader_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表; CREATE TABLE t_commission_log ( id bigint NOT NULL AUTO_INCREMENT, leader_id bigint NOT NULL COMMENT 团长ID, order_no varchar(32) NOT NULL COMMENT 关联订单号, order_amount decimal(10,2) NOT NULL COMMENT 订单实付金额, commission_rate decimal(5,4) NOT NULL COMMENT 当时佣金比例如0.1000, commission_amount decimal(10,2) NOT NULL COMMENT 佣金金额, status tinyint NOT NULL DEFAULT 0 COMMENT 0待结算 1已结算 2已冲正, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_leader_id (leader_id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT团长佣金流水表;这段 SQL 里我刻意踩了两个点第一个是订单号用日期加随机数组合生成唯一键不用自增 id 做订单号方便复制到 Excel 里和人沟通。第二个是佣金比例用 decimal(5,4)存的是 0.1000 而不是 10这样计算佣金时直接乘就行不用再除一百。建好表之后用 MyBatis-Plus 的代码生成器把实体类和 Mapper 生成出来。我一般会把 template 里的 TableName 注解确认一遍因为表名带 t_ 前缀时经常有自动映射找不到表的问题。配置文件里要把驼峰命名映射打开否则数据库字段 user_id 映射不到实体类的 userId。mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: id-type: auto logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里 map-underscore-to-camel-case 必须设为 true这是 mybatis 的经典配置。逻辑删除配置加上了 deleted 字段社区团购的订单和商品不要物理删除否则售后查历史记录时全没了。3.2 用户下单完整流程库存预占、订单生成、核销码分配下单是一个跨多表的联动操作也是整个系统最容易写乱的地方。核心流程是校验商品库存和购买数量 → 锁定库存 → 生成订单和明细 → 生成核销码 → 返回支付参数。这段代码我简化了支付部分重点看库存和订单的联动。Service public class OrderServiceImpl implements OrderService { Resource private ProductSkuMapper productSkuMapper; Resource private OrderMapper orderMapper; Resource private OrderItemMapper orderItemMapper; Override Transactional(rollbackFor Exception.class) public Order createOrder(CreateOrderRequest request) { // 1. 先查商品SKU并校验状态 ProductSku sku productSkuMapper.selectById(request.getSkuId()); if (sku null || sku.getStatus() ! 1) { throw new BusinessException(商品已下架); } if (request.getQuantity() sku.getStock()) { throw new BusinessException(库存不足当前剩余 sku.getStock()); } // 2. 扣减库存使用乐观锁防止超卖 int updated productSkuMapper.deductStock(request.getSkuId(), request.getQuantity()); if (updated 0) { throw new BusinessException(扣库存失败请重试); } // 3. 生成订单主记录 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(request.getUserId()); order.setLeaderId(request.getLeaderId()); order.setTotalAmount(sku.getPrice().multiply(new BigDecimal(request.getQuantity()))); order.setPayAmount(order.getTotalAmount()); order.setStatus(0); order.setPickupCode(generatePickupCode()); orderMapper.insert(order); // 4. 生成订单明细 OrderItem item new OrderItem(); item.setOrderId(order.getId()); item.setSkuId(sku.getId()); item.setProductName(sku.getProductName()); item.setPrice(sku.getPrice()); item.setQuantity(request.getQuantity()); orderItemMapper.insert(item); return order; } private String generateOrderNo() { return LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)) String.format(%04d, new Random().nextInt(9999)); } }这段代码的逻辑顺序是刻意安排的先校验再扣库存扣库存成功后才插入订单主记录最后插入明细。Transactional保证三步要么全成功要么全回滚不会出现库存扣了但订单没生成的情况。这里有个关键参数要说明deductStock这个方法用了数据库行级锁机制来防超卖。对应 SQL 是UPDATE product_sku SET stock stock - #{quantity} WHERE id #{skuId} AND stock #{quantity}MyBatis-Plus 的 UpdateWrapper 也可以实现同样的效果。它是行锁不是表锁并发很高时不会相互阻塞太多。提示扣库存的 SQL 里那个stock #{quantity}条件是这个方法的核心。没有这个条件两个用户同时买最后一件商品时会双双扣成负数这就是超卖。3.3 团长佣金计算与售后冲正先算后核还是先核后算佣金是团长最关心的事也是源码里最容易给错的地方。我的方案是订单支付完成后生成佣金流水状态为待结算团长后台的“可提现佣金”只统计已结算的部分。这样设计的好处是自然解决了“订单退款后佣金怎么办”的问题——退款的订单把待结算的佣金流水改成冲正状态就行。Service public class CommissionServiceImpl implements CommissionService { Resource private CommissionLogMapper commissionLogMapper; Resource private GroupLeaderMapper groupLeaderMapper; Override Transactional(rollbackFor Exception.class) public void createCommission(String orderNo, Long leaderId, BigDecimal orderAmount) { // 查询团长当前佣金比例 GroupLeader leader groupLeaderMapper.selectById(leaderId); BigDecimal rate leader.getCommissionRate(); BigDecimal amount orderAmount.multiply(rate).setScale(2, RoundingMode.HALF_UP); // 生成待结算佣金流水 CommissionLog log new CommissionLog(); log.setLeaderId(leaderId); log.setOrderNo(orderNo); log.setOrderAmount(orderAmount); log.setCommissionRate(rate); log.setCommissionAmount(amount); log.setStatus(0); commissionLogMapper.insert(log); } Override Transactional(rollbackFor Exception.class) public void reverseCommission(String orderNo) { LambdaQueryWrapperCommissionLog wrapper new LambdaQueryWrapper(); wrapper.eq(CommissionLog::getOrderNo, orderNo) .eq(CommissionLog::getStatus, 0); ListCommissionLog logs commissionLogMapper.selectList(wrapper); for (CommissionLog log : logs) { log.setStatus(2); // 冲正 commissionLogMapper.updateById(log); } } }佣金比例和订单实付金额都存在流水表里这个是刻意的。将来团长佣金比例调整过既往的流水还是按当时比例计算对账时不会乱。setScale(2, RoundingMode.HALF_UP)是金额计算的标配Java 里用 double 算钱会出精度问题BigDecimal 配合四舍五入是唯一安全的做法。这里要说明售后退款和佣金冲正的关系。社区团购的售后通常是小金额退款比如一把青菜坏了一半退 3 块钱。这种情况不需要把整个订单的佣金全冲正只需要按退款比例重新算那部分佣金。常见做法是退款成功时先对该订单执行reverseCommission把原流水作废再用剩余实付金额重新生成一条新佣金流水。这样双保险月底看流水表一目了然。4. 跑起这套 Spring Boot 源码环境配置、初始化数据与部署清单源码到手第一件事不是看代码而是把环境配好、把项目跑起来。很多人在这一步被卡住不是因为代码有问题而是 JDK、Maven、MySQL 的版本对不对齐。我按自己惯用的顺序整理一份照做能跑的清单你照着操作十分钟内应该能看到登录页。4.1 本地开发环境准备JDK、Maven、MySQL 和 Redis 版本对齐我的环境组合是JDK 8如果你手头源码用了新语法可以升 JDK 11但别直接跳 17、Maven 3.6.3、MySQL 5.7、Redis 6.x。这套组合跟 Spring Boot 2.7 的兼容性已经被大量生产环境验证过遇到问题搜解决方案也最容易命中。应用配置文件里最可能需要改的是数据源和 Redis 地址。拿到源码后先打开application.yml或application-dev.yml把数据库账号密码改成自己本地的再把 Redis 的连接信息确认一遍。如果源码里配置的是 127.0.0.1而你本地的 Redis 开在别的端口记得同步改掉。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/community_group_buy?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0这段配置里的serverTimezoneAsia/Shanghai是必须的不设置的话 MySQL 8 的时区报错会直接让你启动失败。Redis 的 database 用 0 就行如果同一台机器上跑了多个项目各自指定不同 database 可以避免 key 冲突。初始化数据库时源码包一般会带sql/目录下的建表脚本。我的习惯是先执行一遍建表脚本再执行data.sql里的初始化数据——注意顺序不能反先有表才能插数据。初始化数据里一般包含测试用户、测试团长、测试商品分类和一个管理员账号。找到管理员账号密码记下来后面登录管理系统要用。4.2 Maven 构建与启动命令第一个能用的 Spring Boot 实例构建和启动是流程化的操作直接用 Maven 命令跑。项目根目录下打开终端先执行依赖下载再执行打包。如果之前机器上没有装 Maven直接用 IDEA 自带的 Maven 插件也能构建。# 清理并打包跳过测试可以省很多时间 mvn clean package -DskipTests # 直接启动看控制台日志里有没有 Started Application java -jar target/community-group-buy-1.0.0.jar --spring.profiles.activedev打包完成后控制台会打印Started Application in x seconds或者在 Tomcat started on port(s): 8080 这一行说明 Spring Boot 实例已经跑起来。浏览器访问http://localhost:8080应该会跳转到登录页。如果访问不了先确认 8080 端口是否被占用再来查看应用日志里的异常堆栈。启动成功后别急着写业务代码先把管理后台完整操作一遍创建商品、设置价格、新增团长、模拟用户下单。这样能验证表结构和基础代码没有问题后续改代码才有底。如果一上来就改业务逻辑出了问题很难判断是环境问题还是代码逻辑问题。4.3 前端分离部署vue 打包放进 springboot 的 static 目录社区团购系统的前端接近一半的场景是 Vue 项目管理和用户端都要一套页面。部署时有个取巧但很实用的做法把 Vue 打包后的 dist 文件复制到 Spring Boot 的 static 目录下让 Spring Boot 同时托管前端静态资源一台服务器就能部署整个系统。# 前端打包命令生成的 dist 目录直接复制到 Spring Boot 项目的 static 目录 npm run build # 将 dist 内容复制到 spring-boot 项目的 src/main/resources/static/ cp -r dist/* ../community-group-buy/src/main/resources/static/这个方式的优点是省一台服务器和一个 Nginx 配置缺点是前后端联调时不够灵活。日常开发时前端跑npm run dev配代理部署时就打一个包进去Spring Boot 返回前端页面接口走同域的/api路径生产环境一次部署就能用。注意前后端同域部署时接口地址不要写死成http://localhost:8080/api这种带 IP 的写法要用相对路径/api。否则换服务器部署时前端所有请求都会打到旧地址上这是新手最容易踩的坑。5. 社区团购系统源码的 5 个典型踩坑与排查方法源码能跑起来只是第一步真正让你花时间的是业务跑起来之后暴露的问题。我在做社区团购系统时遇到过高频问题里挑出 5 个最有代表性的每个都是“现象、原因、解决”三步说透希望你能跳过这些坑。5.1 下单后库存没扣减事务没生效还是扣减条件不对现象是用户下单成功但后台看商品库存一点没少。原因是大概率是你把deductStock写成了一个独立的查询加更新的方法这个方法的调用不在事务方法内或者扣减条件的stock #{quantity}判断丢了。我第一次写时就犯过这个错把库存检查和扣减拆成了两个方法事务一提交中间被其他请求插进来库存对不上。解决方法是把校验和扣减放在同一条 SQL 的事务里——也就是直接用带条件的UPDATE语句一个请求过来要么扣成功要么扣失败没有中间态。5.2 订单状态卡在“待支付”支付回调一直没触发现象是用户扫码支付后订单不更新团长那边也看不到新订单。排查时先去数据库看订单的status字段再去看第三方支付回调接口的日志。这个坑多半是回调地址配错了回调地址如果是http://localhost:8080/api/pay/notify在服务器上根本访问不到。另外要注意 Spring Boot 的 Controller 接收支付回调参数时签名校验失败后一定要返回fail给支付平台这样支付平台才会重试回调否则会漏单。我的习惯是在回调入口打一行日志先确认回调真的到来了再继续处理。5.3 团长佣金对不上账比例精度丢了还是流水被覆盖现象是团长说佣金少了你查数据库发现流量流水没问题但统计结果跟预期不符。最隐蔽的原因是佣金比例存成了整数 10计算时没有除以一百金额自然差了十倍。其次是把佣金往团长表里的字段直接累加退款单冲正时找不到是哪笔加进来的。这两件事本质上都是数据模型没设计好解决方法是按照我在 3.1 节给的表结构用佣金流水表算总佣金时用 SQL 的SUM(commission_amount)汇总不要维护一个“总佣金”字段。5.4 MyBatis-Plus 生成的 SQL 查不到数据驼峰映射和逻辑删除配置现象是代码看似没错selectById返回 null控制台打的 SQL 也正常但就是查不到数据。先排除一个最常见的可能表的逻辑删除字段值。MyBatis-Plus 配置了逻辑删除后SQL 会自动加上WHERE deleted 0如果初始化数据的deleted字段默认是 1很多人建表时给了默认值 1所有数据都被过滤掉了。解决方法是把表里所有数据的deleted字段更新为 0再把建表脚本里这个字段的默认值改成 0。另外检查字段名是否是驼峰命名的但表里是下划线字段确认map-underscore-to-camel-case打开。5.5 Redis 服务停了系统直接不能下单现象是 Redis 一挂整个下单链路都不能用了报连接超时错误。原因是下单时用 Redis 做购物车缓存和库存预热代码里直接调用了 Redis 操作缓存不可用就抛异常。解决方法是给 Redis 操作加降级逻辑比如缓存挂了就直查数据库或者至少保证查询类接口能正常工作下单先返回一个可重试的提示。Redis 做缓存可以加速但数据库才是数据一致性的最终保障不要把数据库的职责全交给 Redis。6. 进阶技巧用 Redis 分布式锁把秒杀场景的下单压住前面的代码解决了功能正确性但社区团购运营到一定规模后早高峰的爆品秒杀会带来瞬时并发。这一章我把下单流程再往前推一步在生成订单前用 Redis 分布式锁做库存保护避免多个用户同时买最后一件商品时的资源竞争。原理不复杂用户点下单时先用商品 SKU 的 ID 作为锁的 key 去 Redis 里占一个带过期时间的锁拿到锁的人才允许执行库存扣减和订单创建拿不到锁的直接提示“人多货少、稍后再试”。这一步把并发请求串行化了数据库不会同时收到大量扣库存的 UPDATE。public Order createOrderWithLock(CreateOrderRequest request) { String lockKey sku:lock: request.getSkuId(); String requestId UUID.randomUUID().toString(); // 尝试获取锁等待 3 秒锁自动释放时间 10 秒 boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, 10, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(当前购买人数较多请稍后再试); } try { return createOrder(request); } finally { // 释放锁时校验请求 ID防止误删其他请求的锁 String currentValue (String) redisTemplate.opsForValue().get(lockKey); if (requestId.equals(currentValue)) { redisTemplate.delete(lockKey); } } }锁的超时时间是很讲究的参数。10 秒是一个折中值正常的下单事务几十毫秒就完成了但遇到数据库慢查询或锁等待时可能需要几秒。如果设置的过期时间太短比如 2 秒事务还没执行完锁就自动释放了第二个请求就会进来重复扣库存。如果太长用户等待的时间也会拉长。我一般按“预估的最长事务时间再乘以 3”来设置过期时间下单这种操作 10 秒是合理的。第二个值得花的功夫是订单幂等性验证。支付回调、用户重复点击“提交订单”都可能产生重复订单。我的做法是在 t_order 表设置user_id sku_id 当天日期的联合约束或者在下单方法入口处先用 Redis 检查最近 5 秒内是否有相同请求。这个细节直接决定了财务对账时会不会多出莫名其妙的“幽灵订单”。这套进阶方案的落地顺序我建议是先把基础流程跑通让整个链路可用再考虑引入 Redis 锁、消息队列这些优化手段。社区团购系统源码给你的不是一套能应对百万并发的高性能系统而是一套能把业务跑通、能交付给客户去运营的成品。性能优化要基于真实运营数据的压力测试来做而不是为了炫技一上来就上各种中间件。我自己接手这类项目时的习惯是先看订单和佣金两条流水合不合得上再看团长端和管理端的数据能不能对上这两条通了系统就稳定了。希望这些经验能帮到你。本文还有配套的精品资源点击获取