1. 项目概述与技术选型思路1.1 社区团购这个场景到底在解决什么问题先说结论社区团购系统本质上是在做一个“预购集采自提”的生意闭环。用户在小程序里选好商品下单平台汇总同一社区的订单统一采购第二天货品送到团长通常是小区门口便利店或宝妈那里用户自己去提货。这跟传统电商最大的区别在于物流成本低、损耗低、获客靠邻里关系链。所以这个项目标题里的“社区团购”四个字决定了系统必须包含角色普通用户下单的人、团长自提点管理者也是分销节点、平台运营上架商品、处理售后。如果你做过电商类项目会发现它比一般商城多出一个“自提点”和“团长佣金”的概念这就是它的业务核心差异点。我为什么会用一个springbootuniapp的组合来做这类系统因为社区团购的典型使用场景是用户端需要覆盖微信小程序毕竟微信生态的传播能力最强运营端可能需要同时出App或者H5这个时候uniapp一套代码多端复用的优势就非常明显。而后端用springboot主要看中它的生态成熟从基本的增删改查到支付、消息推送、定时任务所有中间件都有非常成熟的整合方案招人也容易Java后端工程师上手成本低。这个项目适合谁来参考如果你是有Java基础和前端基础、想完整跑通一个商业级全栈项目的开发者或者你在规划一个带分销、团购、自提点业务的小程序这篇内容能帮你避开不少坑。1.2 技术栈“三件套”为什么这么搭配先从后端说起。SpringBoot是目前Java领域做接口服务最主流的选择没有之一。它的自动配置机制让你不需要写一大堆XML配置一个main方法就能启动一个Web服务。配合MyBatis-Plus操作数据库配合Redis做缓存和分布式锁配合Spring Security或拦截器做权限控制整套方案非常成熟社区资料也多出了问题一搜基本都有答案。前端用uniapp这是DCloud推出的跨端框架写一套Vue语法的代码可以编译到微信小程序、支付宝小程序、H5、App等多个平台。社区团购系统最典型的场景就是“微信小程序为主后续可能要出App”用uniapp可以避免以后推倒重来。而且uniapp的语法对Vue开发者来说几乎没有学习成本它的生命周期、组件系统和Vue基本一致唯一的差异点在于平台差异化处理时要用到条件编译这个后面我会详细说。至于微信小程序本身它是这个项目的呈现终端也是业务流量的入口。选择微信小程序而不做独立App最核心的原因就是微信生态的社交裂变能力——一个用户把小程序分享到微信群别人点开就能用这个获客成本比投放广告低太多了。社区团购早期扩张阶段靠的就是这种“群小程序”的组合打法。这里要特别说一个选型考量为什么不直接用原生小程序开发原因很现实——如果你以后想做一个社区团购平台的品牌App原生小程序代码无法复用得完全重写。而uniapp至少能把页面和业务逻辑复用到App端省一半工作量。当然原生小程序的性能和调试体验确实比编译后的代码好一些但综合算下来多端复用带来的收益远大于这点性能损失。我的建议是如果你的业务明确“只做小程序永远不出App”原生开发没问题只要有一丁点多端想法直接上uniapp。2. 后端SpringBoot核心设计2.1 数据库设计——先把实体关系想清楚社区团购系统到底要建多少张表我梳理一下这个项目的核心实体你按照这个思路去设计基本不会乱用户表user包含微信openid、昵称、头像、手机号、余额、积分、邀请码等字段。这里最核心的是openid它是微信生态里识别用户的唯一凭证后面做登录和消息推送都要靠它。团长表leader实际上可以和用户表做关联用role字段区分身份也可以单独建表存团长专属信息比如自提点名称、地址、营业执照图片、审核状态。一个用户可以申请成为团长平台审核通过后才有团长权限。商品表product普通电商的商品字段都差不多但社区团购有个特殊性——商品通常分“今日团”和“常规商品”今日团的商品每天0点更新过期下架。所以商品表要加一个activity_date字段或者关联到某一期活动中。订单表order核心字段包含订单号、用户ID、团长ID自提点、商品快照、实付金额、状态、自提码。订单状态至少要有待支付、已支付待提货、已完成、已取消、售后中。自提点表pickup_point对应团长的物理门店信息包括位置坐标、营业时间、联系电话。用户下单时要选自提点提货时凭订单里的自提码到自提点核销。佣金表commission记录每笔订单产生的团长佣金包括金额、状态待结算/已结算、关联订单号。社区团购的团长佣金一般是订单金额的8%到15%系统每天或每周定时结算。设计表结构的时候有两点经验值得记一下。第一商品信息一定要做快照比如用户在用户端看到的商品名称、价格、图片下单时要原样存一份到订单里。否则后台改了商品价格历史订单的数据就全对不上了财务对账能把你逼疯。第二订单号千万不要用数据库自增ID一是容易被同行估算你的单量二是多表关联时容易暴露业务量。用时间戳随机数生成订单号比如前缀“T”年月日时分秒4位随机数这样既唯一又好看。2.2 接口设计与权限认证SpringBoot后端接口设计我一般按照“统一返回结构统一异常处理JWT鉴权”这个套路来写代码复用度高后期维护也省事。统一返回结构是第一步。定义一个Result类里面至少包含三个字段code状态码、message提示信息、data业务数据。成功时code200业务异常时code等于其他值比如400参数错误、401未登录、403无权限、500系统错误。前端axios或者uniapp的request封装里拦截这个code统一做提示就不用每个接口都写一遍失败处理逻辑。这个设计思路很简单但很多刚入行的开发会忽略导致前端每个请求都要单独判断各种异常情况代码冗余且容易漏判。JWT鉴权是第二步。流程是这样的用户在小程序端调用wx.login拿到的code传给后端后端拿着code去微信服务器换openid查到或创建用户后用用户ID生成一个JWT令牌返回给前端。前端每次请求在header里带上这个token后端用拦截器解析token得到用户ID存入ThreadLocal业务代码里随时可以取到当前登录用户。这套流程是标准的微信小程序登录方案实现起来不复杂但要记住几个细节token有效期要合理设置一般7天比较合适过期后用户需要重新静默登录ThreadLocal用完一定要remove否则Tomcat线程池复用时会出现用户A的数据被用户B看到的严重事故。权限这块这个项目至少要有三种角色普通用户、团长、管理员。我的建议是用拦截器注解的方式控制接口权限。定义一个RequireRole注解标注在Controller方法上比如RequireRole(admin)或RequireRole(leader)拦截器里判断当前用户的角色是否符合要求。这样权限逻辑集中在一个地方不散落在各个业务方法里。2.3 核心业务逻辑——拼团、库存与佣金社区团购的核心业务逻辑有三个每日开团、库存扣减、佣金结算这三个任何一个出bug都很麻烦。每日开团的实现思路后台每天创建一期“今日团”关联一批商品设置每个商品的团购价和库存。用户端首页只展示今日团商品下单时生成的是这一期的订单。后端可以用一个定时任务比如Quartz或Spring自带的Scheduled每天凌晨生成新一期团购把昨天的过期商品状态批量改掉。这里有个细节需要注意生成新一期团购时商品库存是基于实际可用库存重新设置而不是简单的复制昨天的数据因为会有前一天未提货的订单占用实际库存需要做未提货订单的自动取消和库存回补。库存扣减是电商系统的经典难题。用数据库行锁直接扣减在高并发下性能很差用Redis预扣减又有超卖风险。我这边常用的方案是Redis预扣减 定时任务同步数据库。用户下单时先操作Redis的库存key用decrement操作原子扣减如果扣减后值小于0则说明没库存了回滚并提示“已抢光”如果扣减成功生成订单写入数据库同时在Redis里记录一个待同步订单。后台定时任务每隔一段时间把Redis里的未同步订单同步到数据库同步完成后更新数据库字段。这套方案在社区团购这种秒杀场景比较少、日常单量不夸张的项目里完全够用而且能扛住开团瞬间的流量尖峰。佣金结算的逻辑也不难但容易出歧义一笔订单的佣金什么时候可以结算给团长我的规则是用户确认提货或者系统自动确认提货比如发货后7天自动确认后这笔订单才算“有效订单”佣金进入“待结算”状态平台每周一对上周的待结算佣金统一打款打款完成后状态变为“已结算”。如果订单发生退款佣金要同步回滚否则团长白赚了平台的钱。3. 前端uniapp微信小程序实现要点3.1 跨端开发的关键配置如果你用HBuilderX创建uniapp项目第一件事就是打开manifest.json配置应用信息。这里我踩过一个坑小程序的AppID一定要填对。在微信公众平台注册小程序后AppID是wx开头的字符串如果你用的是uniapp内置的测试号很多功能比如登录、支付在真机上是跑不通的。另外manifest.json里有几个配置直接影响小程序能否正常运行基础库版本建议设置高一点能用新API、权限声明获取位置、相机权限要在小程序后台和manifest.json两边都配置、微信支付相关参数appid、mch_id等。还有一个比较容易忽视的配置——顶部导航栏适配。微信小程序的导航栏和H5、App的导航栏高度不一样不同机型也不一样有没有刘海屏差异很大。我封装了一个工具方法通过uni.getSystemInfoSync()获取状态栏高度如果是小程序端用uni.getMenuButtonBoundingClientRect()获取胶囊按钮位置动态计算导航栏高度。千万不要写死一个固定值否则在iPhone 14 Pro Max和普通安卓机型上显示效果天差地别。uniapp开发微信小程序还有一个常见问题条件编译。因为你要适配小程序和H5有些API在小程序端能用、在H5端不存在比如uni.login就只在微信小程序有。用条件编译语法// #ifdef MP-WEIXIN和// #endif包裹特定平台的代码这样编译到对应平台时才会包含这段逻辑。比如用户登录这段代码微信小程序端用uni.login获取codeH5端就直接走账号密码登录。3.2 核心页面与交互实现首页是一个团购小程序的门面它的核心逻辑是展示今日团商品列表。我用的方案是scroll-view做下拉刷新和触底加载商品卡片组件里展示图片、名称、团购价、原价划线、已售数量。已售数量是一个很有效的运营工具它能制造“大家都在买”的从众效应提升转化率。商品详情页要注意“购物车”和“立即购买”的交互闭环。社区团购的特点是拼团购买用户选完数量后要选择自提点这两个操作要放在同一个确认订单页面里减少用户的跳转次数。确认订单页面的设计逻辑从商品详情页带过来的商品ID和数量页面初始化时先请求后端接口获取商品当前的价格和库存同时加载用户最近使用的自提点列表用户选择自提点后计算配送费社区团购一般满XX元免配送费最后显示实付金额。这里要做一个防重复提交的处理——用户点击“提交订单”按钮后按钮置灰loading防止连点生成多个订单。关于热搜里提到的“商品展示视频”这个确实是提升转化率的好功能。uniapp里展示视频用video组件设置src属性为视频地址即可。但要注意两点第一视频地址必须是HTTPS的微信小程序对资源协议有限制第二视频封面图poster属性一定要设置否则小程序端会出现黑屏加载。我建议把视频上传到云存储或者CDN不要在代码包里放视频文件因为小程序包大小限制是2M一个视频就超了。用户个人中心页面要包含订单列表按状态分tab待支付、待提货、已完成、售后、我的优惠券、我的积分、邀请好友生成海报、申请成为团长入口。这一页开发难度不大但页面数量多建议用分包机制来组织——主包只放tabBar页面订单列表、商品详情等页面全部放分包这样可以有效降低主包体积避免超过2M限制。3.3 微信小程序平台能力接入微信登录是第一步。uniapp里调用uni.login获取code传给后端接口/api/auth/login后端返回token和用户信息。要注意的是微信官方推荐用wx.getUserProfile获取用户昵称头像但这个接口以后会逐步收紧政策现在很多小程序直接用默认头像用户可以在个人中心自行修改。我的做法是新手用户先分配一个默认昵称“微信用户”和默认头像用户下单前不需要强制完善资料减少流失。微信支付是第二步。后端先生成预支付订单调用微信支付API获取paySign等参数前端拿到后调用uni.requestPayment发起支付。这一步后端要处理好签名逻辑前端只要把参数透传给支付接口就行。最容易踩坑的是统一下单的金额单位微信支付API接收的单位是“分”而你数据库里存的是“元”转换的时候注意小数位精度建议用整数分存储所有金额字段显示的时候再除以100。扫码核销是第三个核心能力。团长端小程序需要扫用户的提货码来完成核销。uniapp里调用uni.scanCode扫码获取到的是订单的自提码比如一个16位数字或字符串把这个码传给后端/api/fulfillment/complete接口后端校验自提码有效、订单状态是已支付然后把订单状态改成已完成同时触发佣金结算流程。这个功能开发门槛不高但流程测试一定要仔细因为核销是钱和货交接的关键一环出错就是资损事故。4. 部署上线与问题排查4.1 从HBuilderX到微信开发者工具uniapp开发完项目后发行小程序的具体操作是HBuilderX菜单栏选择“发行”—“小程序-微信”输入小程序AppID后点击发行项目会自动编译并在dist目录下生成微信小程序代码。然后打开微信开发者工具导入这个dist目录就能看到完整的小程序了。这里有个关键点微信开发者工具的“不校验合法域名”选项只能在开发调试时打开上线前必须关闭并且要在小程序后台配置合法域名。域名和HTTPS配置是上线前最折腾的一步。小程序要求所有请求的接口域名必须HTTPS而且域名必须备案。如果你用的是云服务器配置HTTPS的一般流程买域名→域名备案大概2-3周→解析到服务器IP→装Nginx→申请SSL证书可以让云厂商免费一年的DV证书→Nginx配置证书和反向代理。反向代理的配置很简单把/api开头的请求转发到后端服务端口就行。后端服务部署我用的是Docker Nginx SpringBoot的架构。Docker里跑MySQL、Redis和后端服务镜像Nginx做反代同时托管前端静态资源。如果你对Docker不熟直接Java -jar命令启动也能跑就是运维不如容器化方便。生产环境建议配一下Systemd服务把启动命令注册成系统服务开机自启动日志输出到文件方便排查。4.2 上线审核避坑指南微信小程序审核是很多新手头疼的事我总结几条实测经验第一涉及虚拟支付的一定要谨慎。微信官方对“虚拟支付”有严格管控比如卖会员、卖课程、卖充值币这些虚拟商品在小程序里是受限的。社区团购卖的是实物商品不涉及这个问题但如果你的商城里混入了话费充值、电子卡券这类商品审核大概率会被打回来。第二类目选择要准确。社区团购小程序一般选择“电商平台”或“商家自营”类目需要提供对应的资质文件比如营业执照。如果经营范围里没有“食品销售”或“增值电信业务”等字样审核可能要求你补充资质。提前准备好营业执照、食品经营许可证等材料能省不少审核来回的时间。第三用户隐私保护协议必须写清楚。从2023年起微信对隐私协议审核变严了很多在小程序后台配置好“用户隐私保护指引”明确说明你收集了哪些信息手机号、位置、相机等、用在哪里、怎么保护。前端在调用涉及隐私的接口前要有弹窗询问否则会被强制下架。第四拒绝诱导分享。社区团购天然依赖分享但小程序里不能出现“分享得红包”、“不转不是朋友”这类诱导文案。分享得积分这类玩法有风险分享功能本身可以用uni.share实现自定义分享卡片但文案和奖励机制要过一下审核规范。4.3 实际开发中踩过的坑列举几个我觉得值得写下来的问题都是实际项目中遇到过的问题和解决方案速查表问题一uniapp打包后视频无法播放。当时排查了很久最后发现是video组件路径问题。开发时用的是相对路径本地资源能正常播放打包后路径解析变了视频资源找不到。解决方案是用网络地址CDN代替本地路径或者用/static/开头的绝对路径。问题二分享功能在安卓正常iOS却打开是空白页。这是典型的分享路径问题。uni.share里的path参数以/开头是绝对路径指向小程序根目录不以/开头是相对路径。iOS对相对路径的解析更严格建议统一用绝对路径。问题三微信支付出现“签名错误请检查后重试”。大概率是paySign参数的生成问题和前端传参不一致。微信小程序的paySign用的键值对必须按ASCII码排序后拼接不能用字典顺序之外的其他顺序另外前端要把后端返回的paySign、timeStamp、nonceStr、package这几个参数原封不动传给uni.requestPayment任何格式化处理都可能导致签名校验失败。问题四小程序启动加载太慢。优化方向主包压缩用分包图片资源全部转WebP格式或适度压缩首屏请求接口合并比如首页把轮播图、今日团列表、公告合并成一个聚合接口用Redis缓存热门商品数据减少数据库查询。问题五订单支付后回调更新状态偶尔丢失。微信支付回调是异步的而且可能会重复推送。后端的回调接口要做好幂等处理——根据订单号加分布式锁重复回调直接返回成功结果避免重复处理导致的数据错乱。5. 个人经验分享与进阶建议这个项目整体做下来我的最大感受是社区团购系统的技术难点不在于某个具体功能有多难而在于要把下单、支付、提货、佣金结算这些环节串成一个可信赖的闭环。用户在你这里下单付了钱第二天提不到货或者团长拿不到佣金任何一个环节掉链子都会让业务崩盘。所以开发阶段每个核心链路的测试用例一定要覆盖到位特别是异常场景支付成功但回调没到、用户下单后改了自提点、退款后库存怎么回补等等。我给你的建议是把这个项目当成一个打磨简历的完整项目时可以额外加上这几个点一是把核心业务逻辑比如订单状态机、佣金计算规则用单元测试覆盖起来面试时很有说服力二是加一个简易的运营后台用SpringBoot Vue做Web管理端能看出你有完整的架构思维三是在高并发设计上多一些思考比如如何用MQ削峰、如何用Redis结合数据库做库存一致性这些是社区团购这类业务场景最常被追问的技术点。最后分享一个让我印象深刻的细节第一次测试扫码核销时我用自己的手机扫了十几次自提码输入一次错一次后来发现是scanCode返回的字符串带空格和换行符。一个trim()就能解决的问题排查了整整半天。做项目多了你会发现很多线上事故排查到最后都是这种小细节但恰恰是这些小细节决定了你是“能跑就行”的业余选手还是“稳如泰山”的专业开发者。