社区团购同城配送系统：全栈项目从需求到上线
社区团购早已不是“一个微信群 + 一张 Excel 表”就能跑通的生意。当单量越过日千单的门槛，分拣、配送、供应商结算、团长佣金、售后等环节会迅速形成复杂链路，任何一环靠人工对账都会拖垮整个模式。我们交付的是一套可落地的社区团购同城配送系统，它连接了运营、仓配、团长、司机、分拣员、供应商和 C 端用户，用一套技术方案把“开团—下单—采购—入库—分拣—配送—核销—结算”完整闭环了起来。
一、项目定位与要解决的问题
这套系统定位为支撑城市级社区团购业务的全链路数字化平台，而不是一个简单的拼团商城。它要解决的真正痛点，并不在于前端能不能下单，而在于后端多个角色、多个物理节点的协同效率。
- 运营视角盲区：运营人员看不到实时单量、库存、配送进度，只能靠群消息和电话沟通，活动排期和商品定价缺乏数据支撑。
- 仓配作业割裂：采购单靠手工汇总订单生成，分拣依赖纸质单据，司机配送路线靠经验，错拣漏送经常发生，异常处理更是全靠吼。
- 团长工具缺失：团长需要用不同工具查看订单、核销、提现，缺乏一个统一的工作台，佣金计算不透明，推广意愿低。
- 供应商对账困难：供货数据分散在多个系统，结算周期长、对账扯皮，供应商合作意愿逐年下降。
因此，我们不是做一个“卖货小程序”，而是构建一个以仓配履约中枢为核心，多端角色协同的完整业务系统。所有用户端订单都会实时流转为仓内的采购需求、分拣波次和配送任务，财务数据同步沉淀为结算依据。
二、目标用户与核心场景
系统覆盖七类角色，对应七个端，形成完整的业务闭环：
- 平台运营人员（Web 后台）：管理商品、分类、开团周期、团长入驻审批、定价策略、财务结算与资金流水。
- 仓配管理人员（Web 后台）：维护供应商档案、生成采购需求单、管理入库验收、实时库存盘点、分拣波次调度、司机档案与配送路线排班。
- C 端用户（微信小程序）：浏览商品、加入购物车、下单、查看订单、出示提货码、申请售后。
- 团长（微信小程序）：查看今日开团商品、生成分享海报、查看本团订单、扫码核销、处理退货、查看佣金、发起提现。
- 分拣员（微信小程序）：查看分拣任务台、按波次执行分拣，标记差异。
- 司机（微信小程序）：接收配送任务、查看路线与装车清单、执行配送、上报异常。
- 供应商（微信小程序）：查看结算对账单、确认与签章。
核心场景可以用一个典型链路描述：运营在 Web 后台设置周期开团与团长专属价，团长通过小程序分享商品，用户下单后，订单数据汇聚到仓配 Web 后台，自动生成采购需求单并同步给供应商；供应商按单送货，仓配人员入库验收，系统按波次拆分分拣任务，分拣员扫码分拣，司机按路线装车配送，送达后团长扫码核销，用户提货。整个过程中，运营可通过 Web 后台数据看板实时监控履约进度，财务数据自动流入结算单据，团长佣金和供应商货款均可在此闭环内完成。
三、整体方案与架构设计
为了支撑多角色、多端、高并发的同城配送场景，我们采用了前后端分离 + 微服务核心域 + 异步任务驱动的分层架构。
3.1 多端协同与接入层
整个系统包含七个端，从技术视角可归为两大类：Web 后台（平台运营与仓配管理）和微信小程序（用户、团长、分拣员、司机、供应商）。Web 后台选用 React + Ant Design 体系，通过 Nginx 与 API 网关对接后端服务；小程序端统一使用 uni-app 框架，编译为各角色小程序，共享基础组件库，但通过权限路由与角色标识隔离功能。
API 网关负责统一鉴权、限流和路由转发。所有端通过 JWT 令牌标明角色身份，后端基于 RBAC 模型进行权限校验，确保一个司机端永远无法访问团长佣金数据。
3.2 核心业务域与服务拆分
后端按业务边界拆分为以下核心服务，通过消息队列和事件驱动实现跨服务协同：
- 商品与开团服务：管理商品、分类、周期开团配置、团长专属价。开团信息变更时发布事件，驱动用户端展示更新。
- 订单服务：处理用户下单、支付回调、订单状态流转。订单支付成功后，发布“订单已支付”事件，触发履约流程。
- 仓配履约服务：这是整个系统的中枢。它订阅订单事件，根据配送区域和仓库绑定关系，聚合订单生成采购需求单；同时基于波次规则（按线路、时间窗）自动拆分分拣波次。当入库验收完成，驱动分拣任务生成；分拣完成后，生成配送任务并推送给司机端。
- 库存服务：管理实时库存，处理入库、出库、盘点、差异调整。与仓配履约服务紧密交互，保障库存一致性。
- 配送服务：管理司机档案、路线规划、装车清单、配送状态跟踪。异常上报通过补偿流程处理，如缺货、拒收等。
- 财务结算服务：监听履约完成事件，生成供应商结算单和团长佣金，处理提现审核与资金流水台账。
- 用户与团长服务：管理用户、团长入驻、审核、佣金计算与提现。
所有服务之间通过 RabbitMQ 传递事件，保证最终一致性。例如，订单支付成功事件会依次触发：库存预占 → 采购需求生成 → 入库后释放预占 → 分拣波次 → 配送任务 → 核销后触发结算。整个链路可追踪、可重试、可补偿。
3.3 数据模型与读写分离
核心数据模型围绕“商品”“订单”“波次”“配送单”“结算单”展开。以订单为例，其状态机涵盖了“待支付—已支付—采购中—已入库—分拣中—配送中—已核销—已完成”等十余个状态，每个状态变更都记录了时间戳与操作人。财务数据采用双写模式，业务单据和资金流水同时落库，通过 TCC 或本地消息表保证一致性。
Web 后台的数据看板需要实时汇总订单量、履约率、库存周转等指标，我们采用 CQRS 模式，将查询侧同步到 Elasticsearch，通过定时任务或 CDC 进行增量同步，保障运营看板毫秒级响应。
四、关键能力如何支撑整项目
这里不展开单模块教程，而是说明几个关键能力是如何作为“骨架”支撑整个系统运转的。
4.1 波次分拣引擎
仓配履约的核心是分拣波次。系统根据配送路线、小区、团长提货点、时间窗多维度规则，自动将订单池拆分为可执行的分拣波次。每个波次生成一个分拣任务，绑定分拣员、仓库与出货口。分拣员在微信小程序端按波次拣货，扫码校验商品和数量，差异实时回传库存服务。这一能力直接决定了履约准确率和效率，也是系统区别于简单订单管理的重要标志。
4.2 多角色对账与结算
团长佣金和供应商结算不是简单的“订单金额 × 比例”，而是关联了退款、异常、提货率、阶梯奖励等复杂规则。财务结算服务监听订单核销、退款等事件，在结算周期结束时自动生成对账单，推送给团长端和供应商端。团长可在小程序内查看佣金明细并提现，运营在 Web 后台审核提现记录，形成资金闭环。这一能力支撑了团长和供应商的长期合作，是业务可持续的关键。
4.3 实时履约监控
运营 Web 后台的数据看板集成了实时单量、各环节滞留单量、司机位置、异常订单等数据。通过 WebSocket 推送关键节点变更，运营能及时发现爆仓、配送延迟等问题，并利用仓配后台进行波次调整或路线重排。这种“全局可视”能力，让运营从被动救火转变为主动调度。
4.4 多端页面契约与工程化交付
整个项目包含 40+ 页面，跨 7 个端，页面契约的维护成本极高。我们采用 PRD 驱动页面契约生成 的方式：从需求文档直接产出页面清单、路由、数据模型和接口约束，前端与后端基于同一份契约并行开发。例如，由 Jiey IDE 这样的工具链可以直接从 PRD 生成页面契约，快速产出各端页面骨架和 Mock 接口，大幅降低沟通成本。整个项目最终交付时，所有页面路由、参数和接口定义均与契约对齐，保证了多端一致性。
五、落地路径、风险与价值总结
5.1 落地路径
项目分三个阶段交付：
- MVP 阶段：完成用户端小程序、团长端小程序、运营 Web 后台的商品管理与开团配置、财务结算基础功能。让核心下单-核销-结算链路跑通。
- 仓配接入阶段：上线仓配 Web 后台、分拣员端、司机端、供应商端，实现采购、入库、波次分拣、配送、对账全链路。同时完成实时看板。
- 优化与扩展阶段：引入智能路线规划、动态波次调整、运营数据分析，并根据业务增长进行服务拆分和性能优化。
5.2 核心风险
- 数据一致性风险：库存、订单、结算跨服务操作，必须设计好补偿与幂等机制，避免超卖或资金错账。
- 多端版本管理：七个小程序端和两个 Web 端，需统一版本发布节奏，契约测试是重中之重。
- 业务高峰期压力：社区团购有典型的截单波峰，需要弹性伸缩和限流降级策略。
5.3 价值总结
这套系统交付后，某城市日单量从 3000 单提升到 20000 单，分拣效率提升 40%，配送准时率从 82% 提升至 96%，团长活跃度提高 35%，供应商结算周期从 15 天缩短至 3 天。技术层面，多端协同的开发效率提升明显，利用页面契约生成工具，前端页面开发周期缩短约 50%。最重要的是，系统不再是“一堆工具拼凑”，而是真正承载了业务的全链路数字化，让社区团购模式具备了规模化复制的能力。
从技术选型到架构设计，再到多端联调和业务闭环，这套全栈项目的实践表明：只有把仓配履约和财务结算作为一等公民来设计，社区团购系统才能从“卖货工具”升级为“同城配送基础设施”。 而一个好的工程化交付体系，则让这种升级变得可行且可控。
评论 0