简介这是一份高校社区生鲜配送系统的完整项目资源定位为面向大学生及周边社区居民的在线生鲜购物平台覆盖用户、商品、订单、库存、配送、支付等核心业务模块适用于课程设计、毕业设计或Java Web项目实战。资源包共909个文件压缩后约1.61MB主要包含120个Java源码、152个class编译文件、184个html页面、134个css样式、122个js脚本以及121个png图片并附带SQL数据库文件便于搭建运行或按模块阅读源码。目前已有138人学习下载。通过该项目可以系统理解前后端分层架构、数据库表设计、订单与库存联动逻辑、配送调度流程以及支付接口集成方式配合页面与业务代码也能快速掌握从登录注册到后台管理的一整套电商系统实现思路适合正在做相关课题或想提升全栈开发能力的开发者。1. 高校社区生鲜配送系统一个能跑通“下单—接单—配送”闭环的完整源码包如果你在某高校社区里做过生鲜配送大概率经历过这类场面订单在微信群里刷屏、骑手靠截图对货、商家和用户都问“到底送到哪了”。这个名为“高校社区生鲜配送系统”的压缩包就是针对这种场景拆出来的一套可运行项目。它包含买家端、商家端、骑手端和管理后台四套界面核心流程覆盖商品浏览、购物车结算、商家接单、骑手取货、订单状态同步和异常取消。适合三类人拿它做毕业设计二次开发的在校生、想快速搭一个社区电商原型的产品经理以及刚接触前后端分离项目、需要一份完整工程作参考的开发者。下面按我的拆包顺序从架构到部署逐层往下讲。2. 系统架构与数据设计先看懂四端一后台怎么分工2.1 前后端分离与模块边界每个端解决什么问题解压之后工程按端分成四个子目录加一个后端服务目录。前端不是“一个大项目”而是彼此独立的三套应用买家端是 H5 页面主要跑在微信内嵌浏览器里商家端和骑手端是两套不同入口的管理界面前者处理接单出餐后者处理取货送达管理后台则是给运营方用的一个 Web 控制台。后端是一个 Spring Boot 单体服务同时为四个端提供 REST 接口和 WebSocket 推送。我第一次拆这个包时最先做的是画一张模块边界表否则很容易被前端目录数量吓到端技术形态核心职责关键页面买家端 H5Vue 单页应用浏览商品、加购、下单支付、查看订单状态首页商品流、购物车、订单详情商家端 WebVue 单页应用接单、出餐、上下架商品、查看店铺数据订单列表、商品管理骑手端 WebVue 单页应用抢单、取货、标记送达、查看配送记录可抢订单列表、我的配送管理后台 WebVue Element UI用户管理、商家审核、数据看板看板、用户列表、订单总览后端服务Spring Boot 单体统一鉴权、业务接口、推送、文件上传—这个拆分方式的优点是边界清楚买家端哪怕流量再大也只访问商品和订单相关接口骑手端只依赖配送相关接口。缺点也很明显后端是单体的所有请求都打到一个服务上。如果你的场景是几千人同时下单单体是做得到的关键在于把数据库和缓存设计好而不是一上来就拆微服务。对于课设、小型社区运营这个架构是性价比最高的方案。2.2 核心表结构订单金额为什么要用“分”存储数据库用的是 MySQL一共十二张表我重点讲最核心的五张用户表、商家表、商品表、订单主表和订单明细表。这五张表构成了下单主链路的数据基础。CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, role TINYINT NOT NULL DEFAULT 1 COMMENT 1-买家 2-商家 3-骑手 4-管理员, campus_id BIGINT NOT NULL, phone VARCHAR(20), status TINYINT NOT NULL DEFAULT 1, create_time DATETIME NOT NULL ) ENGINEInnoDB; CREATE TABLE merchant ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, address VARCHAR(255), longitude DECIMAL(10,6) NOT NULL, latitude DECIMAL(10,6) NOT NULL, campus_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-营业 0-打烊 ) ENGINEInnoDB; CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, merchant_id BIGINT NOT NULL, name VARCHAR(128) NOT NULL, price INT NOT NULL COMMENT 以分为单位, stock INT NOT NULL DEFAULT 0, category VARCHAR(64), image_url VARCHAR(255), status TINYINT NOT NULL DEFAULT 1 ) ENGINEInnoDB; CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL UNIQUE, user_id BIGINT NOT NULL, merchant_id BIGINT NOT NULL, rider_id BIGINT DEFAULT NULL, total_amount INT NOT NULL COMMENT 以分为单位, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-待支付 2-已支付 3-已接单 4-配送中 5-已完成 6-已取消, address_detail VARCHAR(255) NOT NULL, longitude DECIMAL(10,6), latitude DECIMAL(10,6), create_time DATETIME NOT NULL, pay_time DATETIME, accept_time DATETIME, finish_time DATETIME ) ENGINEInnoDB; CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_name VARCHAR(128) NOT NULL, price INT NOT NULL COMMENT 下单时快照价, quantity INT NOT NULL, subtotal INT NOT NULL ) ENGINEInnoDB;这个设计里有几个关键取舍。第一price和total_amount用 INT 存“分”而不是用 DECIMAL 存“元”。如果你用浮点数算金额累计到一定程度会出现精度漂移比如 0.1 加 0.2 得到 0.30000000000000004。存“分”是整数运算永远不会有浮点误差展示时再除以 100。第二order_item里冗余了product_name和price的“下单时快照”这是刻意的——商品可能后续改价或改名但订单历史必须保留用户下单那一刻的信息。第三坐标用DECIMAL(10,6)能精确到 0.000001 度大约 0.1 米的偏差对校园场景够用不要用FLOAT否则经纬度在计算配送距离时会越偏越远。2.3 环境初始化前后端联调时最容易被忽略的三个配置节项目后端用的是 Spring Boot 2.7 和 MyBatis-Plus前端是 Vue 2 和 Element UI数据库 MySQL 8.0。初始化时不建议直接改代码先确认三件事数据库版本、Redis 是否启动、前端代理是否指向正确端口。spring: datasource: url: jdbc:mysql://localhost:3306/fresh_delivery?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password redis: host: 127.0.0.1 port: 6379 database: 0 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezoneAsia/Shanghai和time-zone: GMT8这两个配置要同时存在。我之前遇到过只配了 JDBC 时区、没配 Jackson 时区的情况下单时间在数据库里是正确的但返回到前端页面时凭空多了 8 个小时。另外注意 Redis 在这个项目里承担两件事一是存储登录 token 的 session二是做抢单时的分布式锁。Redis 没启动系统不会在启动时报错但用户登录和骑手抢单都会静默失败很多新手在这上面浪费半天。启动后端的命令很简单mvn spring-boot:run三个前端项目各自是独立的 Vue 工程在各自目录下执行npm install npm run serve前端开发服务器默认跑在 8080 系端口后端 API 跑在 8081前端的 vue.config.js 里已经配好了代理。如果你改了后端端口记得同步修改vue.config.js里的target否则会出现页面能打开、接口全 404 的“前后端断连”现象。3. 下单与接单主链路从购物车到出餐的事务边界3.1 用户端下单接口事务、库存扣减和金额计算一次做完用户端下单是整套系统里事务边界最长的一个操作。它要做的事情包括读取购物车数据、检查商品是否在售、扣减库存、计算订单总金额、生成订单主记录、生成订单明细最后清空购物车。任何一个环节失败前面的操作都必须回滚否则会出现“订单没建上但库存扣了”的严重事故。Transactional(rollbackFor Exception.class) public OrderCreateResult createOrder(OrderCreateRequest request) { Long userId request.getUserId(); ListCartItem cartItems cartMapper.selectCartItems(userId); if (cartItems.isEmpty()) { throw new BusinessException(购物车为空); } long totalAmount 0; ListOrderItem orderItems new ArrayList(); for (CartItem item : cartItems) { Product product productMapper.selectById(item.getProductId()); if (product null || product.getStatus() ! 1) { throw new BusinessException(商品已下架: item.getProductId()); } if (product.getStock() item.getQuantity()) { throw new BusinessException(库存不足: product.getName()); } int subtotal product.getPrice() * item.getQuantity(); totalAmount subtotal; OrderItem orderItem new OrderItem(); orderItem.setProductId(product.getId()); orderItem.setProductName(product.getName()); orderItem.setPrice(product.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubtotal(subtotal); orderItems.add(orderItem); } Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setMerchantId(cartItems.get(0).getMerchantId()); order.setTotalAmount((int) totalAmount); order.setStatus(1); order.setAddressDetail(request.getAddressDetail()); order.setLongitude(request.getLongitude()); order.setLatitude(request.getLatitude()); order.setCreateTime(new Date()); ordersMapper.insert(order); for (OrderItem orderItem : orderItems) { orderItem.setOrderId(order.getId()); orderItemMapper.insert(orderItem); } for (CartItem item : cartItems) { productMapper.decreaseStock(item.getProductId(), item.getQuantity()); cartMapper.deleteById(item.getId()); } OrderCreateResult result new OrderCreateResult(); result.setOrderId(order.getId()); result.setOrderNo(order.getOrderNo()); result.setTotalAmount(order.getTotalAmount()); return result; }这个方法用Transactional包住全部写操作一旦抛出运行时异常Spring 会自动回滚事务。注意我标记了三行注释快照价格、减库存、清购物车。减库存用的是productMapper.decreaseStock对应的 SQL 是UPDATE product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这条 SQL 本身带库存条件天然防超卖。如果受影响行数为 0说明并发下单时库存已经被抢完这时会抛异常触发回滚。后端习惯上把下单接口设计成/api/order/create前端传购物车项列表和收货地址即可。购物车项列表优先传“购物车记录 ID 和数量”而不是直接传商品 ID。这样后端可以从购物车记录里反查商品信息避免前端伪造价格参数。价格永远以后端数据库为准前端传什么价格都不信。3.2 商家接单与出餐状态变更为什么用“比较后更新”商家端登录后能看到新订单列表。接单操作的代码不长但有一个关键细节值得展开讲。public void acceptOrder(String orderNo, Long merchantId) { Orders order ordersMapper.selectByOrderNo(orderNo); if (order null) { throw new BusinessException(订单不存在); } if (!order.getMerchantId().equals(merchantId)) { throw new BusinessException(无权操作该订单); } if (order.getStatus() ! 1 order.getStatus() ! 2) { throw new BusinessException(订单状态不允许接单); } int updated ordersMapper.compareAndUpdateStatus( orderNo, 2, // 期望当前状态已支付 3, // 目标状态已接单 new Date() ); if (updated ! 1) { throw new BusinessException(订单状态已变化请刷新后重试); } }这里的核心不是直接UPDATE orders SET status 3 WHERE order_no ?而是先查一次订单状态再用compareAndUpdateStatus做条件更新。compareAndUpdateStatus的 SQL 是UPDATE orders SET status #{targetStatus}, accept_time #{now} WHERE order_no #{orderNo} AND status #{expectStatus}。查和更新分两步但真正保证原子性的是第二步的 WHERE 条件。这样即使两个商家同时点接单数据库也只会允许一个更新成功另一个因为状态不再匹配而受影响行数为 0。为什么允许状态为 1 或 2 的订单都能接单因为实际业务里用户可能在下单后立刻通过线下转账支付还没等到支付回调更新状态商家这边就看到订单了。给一点状态容错能减少商家电话来问“这个订单怎么接不了”。但状态为 4配送中和 5已完成时一定不能接否则会出现骑手已经在送货、商家还在接单的逻辑混乱。3.3 超时未支付的边界状态机里最容易被遗忘的分支下单后会生成一个“待支付”订单。常见做法是用户主动取消或者在后端做一个超时任务自动关单。这个项目的做法是在订单创建时写入 Redis 过期键key 是order:timeout:{orderNo}过期时间 15 分钟。通过 Redis 的过期回调或者定时扫描 Redis 里的 pending 订单集合把超时订单关掉。public void timeoutCancel(String orderNo) { int updated ordersMapper.compareAndUpdateStatus( orderNo, 1, // 只允许“待支付”状态被超时关单 6, // 目标状态已取消 new Date() ); if (updated 1) { // 关闭支付单、释放库存 restoreStock(orderNo); } }这里有一个边界分支容易漏用户先点击支付但支付网关回调还没回来这时超时任务恰好把订单关掉了。等支付回调到达系统发现订单已经是“已取消”状态这时候绝对不能直接报错更不能把状态从 6 改回 2。正确做法是把回调消息标记为“支付成功但订单已关闭”然后走人工退款流程。我在项目里给支付回调单独加了一张payment_record表记录支付单号和回调内容状态异常时留痕方便对账。这个小改动在实际运营里救过我好几次。4. 骑手调度与状态同步订单状态机的设计与推拉结合4.1 状态机设计六种状态、五条合法变迁路径整个系统的业务复杂度集中在订单状态变更上。项目文档里有一张状态机图我建议你把它记下来因为后面所有推送、对账、统计都围绕这张图展开。当前状态触发事件目标状态执行人1 待支付支付成功回调2 已支付系统自动1 待支付用户取消 / 超时关单6 已取消用户 / 系统2 已支付商家接单3 已接单商家3 已接单骑手取货4 配送中骑手4 配送中骑手确认送达5 已完成骑手2 已支付商家拒单触发退款6 已取消商家这个表告诉我两件事第一状态的跳转不是任意两个状态之间都能走必须经过既定事件第二真正对状态做写操作的只有四种角色——系统支付回调、超时关单、用户取消、商家接单/拒单、骑手取货/送达。在实际编码时我把这张表直接翻译成一个校验类所有状态变更入口统一走这个校验而不是散落在各个 Service 里。如果你在二次开发时想新增一个状态比如“商家已出餐”需要同步改表、改校验类、改前端展示三者缺一不可这是最容易漏的地方。4.2 抢单逻辑数据库行锁比分布式锁更省事骑手端的抢单流程是骑手打开“可抢订单”列表看到待配送的订单点击抢单。可抢订单的来源有两类一是商家接单后自动进入骑手池二是管理后台手动派单后剩余的单子进入骑手池。抢单最大的技术难点是“多人同时抢一单”。我先说项目里的直接做法——数据库乐观锁。public GrabResult grabOrder(String orderNo, Long riderId) { int updated ordersMapper.grabOrder(orderNo, riderId); if (updated 1) { return GrabResult.success(); } return GrabResult.failed(手慢了订单已被抢走); }grabOrder的 SQL 是UPDATE orders SET rider_id #{riderId}, status 4 WHERE order_no #{orderNo} AND rider_id IS NULL AND status 3。这个写法把“校验 rider_id 是否为空”和“写入 rider_id”合并到一条 UPDATE 语句里由数据库的行锁保证同一时刻只有一个骑手能抢到单。相比预先查一遍再用分布式锁的方案这个方案更直接、不会引入 Redis 锁过期之类的新问题。骑手取货之后标记送达用的是类似的compareAndUpdateStatus。取货动作本身有一个隐含约束骑手必须在商家附近才能取货但项目里并没有做严格的 GPS 校验只是在取货接口里传了骑手当前坐标后台记录在delivery_track表里作为追溯依据。如果你的场景需要对“骑手是否真的到店”做硬性校验可以后续在接口里加一个距离判断逻辑。4.3 WebSocket 推送四个频道的订阅关系与消息格式订单状态变化后买家端、商家端、骑手端需要实时感知。项目用的是 WebSocket STOMP 协议后端推送前端订阅。核心配置如下Override public void registerStompEndpoints(StompEndpointRegistry registry) { registry.addEndpoint(/ws) .setAllowedOriginPatterns(*) .withSockJS(); } Override public void configureMessageBroker(MessageBrokerRegistry registry) { registry.enableSimpleBroker(/topic, /queue); registry.setApplicationDestinationPrefixes(/app); }订阅频道按照角色划分频道订阅人推送内容/topic/order/new/{merchantId}商家新订单到达提醒/topic/order/status/{orderNo}买家订单状态变化/topic/rider/task/{riderId}骑手新可抢订单提醒/topic/admin/order管理后台全量订单变化事件推送时机严格绑定状态机事件支付成功推给商家商家接单推给买家骑手取货推给买家送达再推给买家。推送的内容不只包含状态码还包含一个eventType字段比如ORDER_ACCEPTED、ORDER_DELIVERING前端根据eventType决定是弹 toast 还是更新按钮状态而不是每次都刷新整页。实际运营时我发现一个坑WebSocket 连接不是百分百可靠的校园网环境下很容易断线。所以前端在订阅频道的同时也保留了setInterval拉取订单详情的接口作为兜底每 30 秒拉一次。这个“推拉结合”的模式在定位断连问题时非常有帮助——先看 WebSocket 是否重连再看兜底轮询是否触发基本能定位到是哪一层出了问题。5. 避坑指南部署与数据一致性里的五个真实翻车点5.1 前端页面能打开但所有接口返回 404现象npm run serve正常启动页面样式、路由都正常但点击任何按钮都提示接口不存在。原因前端的vue.config.js里代理配置指向了localhost:8081但后端服务实际跑在别的端口或者后端启动时改了 context-path。另外还有一种可能是前端代码是从某个环境拷贝过来的代理目标还残留着旧 IP。解决先打开浏览器开发者工具的 Network 面板看请求实际发到哪个地址。如果地址不是localhost:8081修改vue.config.js里的target字段然后重启npm run serve。如果是后端改了 context-path需要统一修改前端的代理前缀和后端的server.servlet.context-path这两处必须一致。5.2 订单金额出现 0.30000000000000004 之类的怪异数值现象一个 0.1 元加 0.2 元的订单数据库里总金额显示 0.30000000000000004。原因数据库字段用了DECIMAL(10,2)或FLOAT前端传参用字符串后端用BigDecimal转换时精度有损耗或者更直接的情况是代码里用了double计算金额。解决我前面已经强调过项目表结构里金额字段全部是 INT 存“分”。如果你的代码是从别处改来的搜索一下所有double、float、BigDecimal的使用点统一改成整数运算。前端展示金额时用(cents / 100).toFixed(2)转换即可注意toFixed返回的是字符串传给后端前要先转数字。5.3 用户取消订单后库存数量对不上现象用户下单买了两件商品取消订单后商品库存没有加回来或者加回来的数量不对。原因取消订单的回滚逻辑只恢复了订单主表的状态没有遍历订单明细去恢复商品库存。更隐蔽的原因是在取消之前商家已经接单出餐库存已经被商家做了出库操作此时恢复库存就是错的——需要区分“取消时点”和“是否已出餐”。解决取消订单接口里先检查订单状态只有状态为 1待支付或 2已支付的订单才允许恢复库存。状态为 3已接单以上的订单库存已经进入出餐环节取消后应由商家在管理后台手动确认处理不能自动恢复。恢复库存的 SQL 用UPDATE product SET stock stock #{qty} WHERE id #{pid}不需要额外判断库存上限因为恢复的一定是之前扣掉的那部分。5.4 管理后台看到的订单时间比实际时间晚 8 小时现象用户下单是上午 10 点管理后台显示下午 6 点。原因MySQL 连接串缺少serverTimezoneAsia/Shanghai导致 JDBC 驱动用了默认时区UTC读写时间时发生了 8 小时偏移。如果只改了 JDBC 时区但 Spring Boot 的jackson.time-zone没有同步改会出现“数据库正确、接口返回给前端错误”的二次偏移。解决统一在三处配置时区——MySQL 连接串里的serverTimezoneAsia/Shanghai、application.yml里的jackson.time-zone: GMT8、MySQL 数据库本身的default-time-zone。改完之后重启后端服务重新生成一个新订单验证时间。5.5 批量导入商家数据时中文全部乱码现象用 SQL 脚本或者 CSV 文件批量导入商家地址管理后台显示“???”或乱码。原因CSV 文件保存时用的是 ANSI 编码而数据库连接串指定了characterEncodingutf8两边编码不一致。SQL 脚本则可能是文件本身是 GBK 编码但 MySQL 客户端按 UTF-8 解析执行。解决CSV 文件统一用“UTF-8 with BOM”格式保存Excel 另存时选择“CSV UTF-8逗号分隔”SQL 脚本在文件头部加上SET NAMES utf8mb4;再执行。另有一个细节数据库表本身的CHARSET必须是utf8mb4而不是utf8否则遇到生僻汉字或 emoji 表情会直接报错或变问号。6. 试运行验证与二次开发方向让系统真正可用起来拿到这个压缩包别急着改业务代码。我的习惯是先原封不动跑一遍完整链路确认没有环境问题之后再做二次开发。具体操作分三步第一步往后端数据库导入项目自带的init_data.sql里面包含了几个测试商家、测试商品和两个骑手账号第二步启动后端和买家端注册一个买家账号走一遍“搜索商品→加入购物车→下单→支付模拟→等商家接单”的流程第三步用骑手账号登录骑手端找到刚才的订单执行“抢单→取货→送达”然后在买家端确认状态是否变为“已完成”。跑通这三步就说明整个系统最核心的主链路没有断。接下来是二次开发方向。如果这是课程设计推荐优先改两个点一是把支付模拟接口替换成真实支付网关项目里预留了PaymentService接口目前只实现了“模拟支付成功”你可以补充一个真实沙箱环境的对接实现二是给管理后台增加一个“配送统计”页面用订单表里的finish_time - create_time计算平均配送时长按商家维度分组展示。这两个改动都不涉及底层表结构调整但能显著提升项目的完整度。如果这是要真实运营我会建议优先优化骑手派单逻辑。当前版本是“抢单制”高峰期会出现部分骑手抢到多单、部分骑手无单可抢的失衡。可以改成“得分排序派单”每个骑手维护一个current_load字段推送新订单时只推给当前负载最低且距离最近的骑手。这个改动涉及三处——数据库加字段、商家接单后触发的推送逻辑、骑手端列表的过滤条件工作量在两到三天左右。最后说一个我自己的教训。刚开始接触这类订单系统时我总觉得状态变更就是UPDATE ... SET status newStatus这么简单直到有一次调试线上问题发现一个订单从“配送中”直接变成了“已完成”但骑手根本没有点过送达按钮排查半天才发现是管理后台的“一键完成全部订单”脚本误触发了。从那以后我每次做这类系统都会强制走一遍状态机表格把每个状态能触发的动作全部列出来贴在代码注释里再写任何状态更新逻辑之前先对一遍表。希望帮到你。本文还有配套的精品资源点击获取
简介这是一份高校社区生鲜配送系统的完整项目资源定位为面向大学生及周边社区居民的在线生鲜购物平台覆盖用户、商品、订单、库存、配送、支付等核心业务模块适用于课程设计、毕业设计或Java Web项目实战。资源包共909个文件压缩后约1.61MB主要包含120个Java源码、152个class编译文件、184个html页面、134个css样式、122个js脚本以及121个png图片并附带SQL数据库文件便于搭建运行或按模块阅读源码。目前已有138人学习下载。通过该项目可以系统理解前后端分层架构、数据库表设计、订单与库存联动逻辑、配送调度流程以及支付接口集成方式配合页面与业务代码也能快速掌握从登录注册到后台管理的一整套电商系统实现思路适合正在做相关课题或想提升全栈开发能力的开发者。1. 高校社区生鲜配送系统一个能跑通“下单—接单—配送”闭环的完整源码包如果你在某高校社区里做过生鲜配送大概率经历过这类场面订单在微信群里刷屏、骑手靠截图对货、商家和用户都问“到底送到哪了”。这个名为“高校社区生鲜配送系统”的压缩包就是针对这种场景拆出来的一套可运行项目。它包含买家端、商家端、骑手端和管理后台四套界面核心流程覆盖商品浏览、购物车结算、商家接单、骑手取货、订单状态同步和异常取消。适合三类人拿它做毕业设计二次开发的在校生、想快速搭一个社区电商原型的产品经理以及刚接触前后端分离项目、需要一份完整工程作参考的开发者。下面按我的拆包顺序从架构到部署逐层往下讲。2. 系统架构与数据设计先看懂四端一后台怎么分工2.1 前后端分离与模块边界每个端解决什么问题解压之后工程按端分成四个子目录加一个后端服务目录。前端不是“一个大项目”而是彼此独立的三套应用买家端是 H5 页面主要跑在微信内嵌浏览器里商家端和骑手端是两套不同入口的管理界面前者处理接单出餐后者处理取货送达管理后台则是给运营方用的一个 Web 控制台。后端是一个 Spring Boot 单体服务同时为四个端提供 REST 接口和 WebSocket 推送。我第一次拆这个包时最先做的是画一张模块边界表否则很容易被前端目录数量吓到端技术形态核心职责关键页面买家端 H5Vue 单页应用浏览商品、加购、下单支付、查看订单状态首页商品流、购物车、订单详情商家端 WebVue 单页应用接单、出餐、上下架商品、查看店铺数据订单列表、商品管理骑手端 WebVue 单页应用抢单、取货、标记送达、查看配送记录可抢订单列表、我的配送管理后台 WebVue Element UI用户管理、商家审核、数据看板看板、用户列表、订单总览后端服务Spring Boot 单体统一鉴权、业务接口、推送、文件上传—这个拆分方式的优点是边界清楚买家端哪怕流量再大也只访问商品和订单相关接口骑手端只依赖配送相关接口。缺点也很明显后端是单体的所有请求都打到一个服务上。如果你的场景是几千人同时下单单体是做得到的关键在于把数据库和缓存设计好而不是一上来就拆微服务。对于课设、小型社区运营这个架构是性价比最高的方案。2.2 核心表结构订单金额为什么要用“分”存储数据库用的是 MySQL一共十二张表我重点讲最核心的五张用户表、商家表、商品表、订单主表和订单明细表。这五张表构成了下单主链路的数据基础。CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, role TINYINT NOT NULL DEFAULT 1 COMMENT 1-买家 2-商家 3-骑手 4-管理员, campus_id BIGINT NOT NULL, phone VARCHAR(20), status TINYINT NOT NULL DEFAULT 1, create_time DATETIME NOT NULL ) ENGINEInnoDB; CREATE TABLE merchant ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, address VARCHAR(255), longitude DECIMAL(10,6) NOT NULL, latitude DECIMAL(10,6) NOT NULL, campus_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-营业 0-打烊 ) ENGINEInnoDB; CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, merchant_id BIGINT NOT NULL, name VARCHAR(128) NOT NULL, price INT NOT NULL COMMENT 以分为单位, stock INT NOT NULL DEFAULT 0, category VARCHAR(64), image_url VARCHAR(255), status TINYINT NOT NULL DEFAULT 1 ) ENGINEInnoDB; CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL UNIQUE, user_id BIGINT NOT NULL, merchant_id BIGINT NOT NULL, rider_id BIGINT DEFAULT NULL, total_amount INT NOT NULL COMMENT 以分为单位, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-待支付 2-已支付 3-已接单 4-配送中 5-已完成 6-已取消, address_detail VARCHAR(255) NOT NULL, longitude DECIMAL(10,6), latitude DECIMAL(10,6), create_time DATETIME NOT NULL, pay_time DATETIME, accept_time DATETIME, finish_time DATETIME ) ENGINEInnoDB; CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_name VARCHAR(128) NOT NULL, price INT NOT NULL COMMENT 下单时快照价, quantity INT NOT NULL, subtotal INT NOT NULL ) ENGINEInnoDB;这个设计里有几个关键取舍。第一price和total_amount用 INT 存“分”而不是用 DECIMAL 存“元”。如果你用浮点数算金额累计到一定程度会出现精度漂移比如 0.1 加 0.2 得到 0.30000000000000004。存“分”是整数运算永远不会有浮点误差展示时再除以 100。第二order_item里冗余了product_name和price的“下单时快照”这是刻意的——商品可能后续改价或改名但订单历史必须保留用户下单那一刻的信息。第三坐标用DECIMAL(10,6)能精确到 0.000001 度大约 0.1 米的偏差对校园场景够用不要用FLOAT否则经纬度在计算配送距离时会越偏越远。2.3 环境初始化前后端联调时最容易被忽略的三个配置节项目后端用的是 Spring Boot 2.7 和 MyBatis-Plus前端是 Vue 2 和 Element UI数据库 MySQL 8.0。初始化时不建议直接改代码先确认三件事数据库版本、Redis 是否启动、前端代理是否指向正确端口。spring: datasource: url: jdbc:mysql://localhost:3306/fresh_delivery?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password redis: host: 127.0.0.1 port: 6379 database: 0 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezoneAsia/Shanghai和time-zone: GMT8这两个配置要同时存在。我之前遇到过只配了 JDBC 时区、没配 Jackson 时区的情况下单时间在数据库里是正确的但返回到前端页面时凭空多了 8 个小时。另外注意 Redis 在这个项目里承担两件事一是存储登录 token 的 session二是做抢单时的分布式锁。Redis 没启动系统不会在启动时报错但用户登录和骑手抢单都会静默失败很多新手在这上面浪费半天。启动后端的命令很简单mvn spring-boot:run三个前端项目各自是独立的 Vue 工程在各自目录下执行npm install npm run serve前端开发服务器默认跑在 8080 系端口后端 API 跑在 8081前端的 vue.config.js 里已经配好了代理。如果你改了后端端口记得同步修改vue.config.js里的target否则会出现页面能打开、接口全 404 的“前后端断连”现象。3. 下单与接单主链路从购物车到出餐的事务边界3.1 用户端下单接口事务、库存扣减和金额计算一次做完用户端下单是整套系统里事务边界最长的一个操作。它要做的事情包括读取购物车数据、检查商品是否在售、扣减库存、计算订单总金额、生成订单主记录、生成订单明细最后清空购物车。任何一个环节失败前面的操作都必须回滚否则会出现“订单没建上但库存扣了”的严重事故。Transactional(rollbackFor Exception.class) public OrderCreateResult createOrder(OrderCreateRequest request) { Long userId request.getUserId(); ListCartItem cartItems cartMapper.selectCartItems(userId); if (cartItems.isEmpty()) { throw new BusinessException(购物车为空); } long totalAmount 0; ListOrderItem orderItems new ArrayList(); for (CartItem item : cartItems) { Product product productMapper.selectById(item.getProductId()); if (product null || product.getStatus() ! 1) { throw new BusinessException(商品已下架: item.getProductId()); } if (product.getStock() item.getQuantity()) { throw new BusinessException(库存不足: product.getName()); } int subtotal product.getPrice() * item.getQuantity(); totalAmount subtotal; OrderItem orderItem new OrderItem(); orderItem.setProductId(product.getId()); orderItem.setProductName(product.getName()); orderItem.setPrice(product.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubtotal(subtotal); orderItems.add(orderItem); } Orders order new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setMerchantId(cartItems.get(0).getMerchantId()); order.setTotalAmount((int) totalAmount); order.setStatus(1); order.setAddressDetail(request.getAddressDetail()); order.setLongitude(request.getLongitude()); order.setLatitude(request.getLatitude()); order.setCreateTime(new Date()); ordersMapper.insert(order); for (OrderItem orderItem : orderItems) { orderItem.setOrderId(order.getId()); orderItemMapper.insert(orderItem); } for (CartItem item : cartItems) { productMapper.decreaseStock(item.getProductId(), item.getQuantity()); cartMapper.deleteById(item.getId()); } OrderCreateResult result new OrderCreateResult(); result.setOrderId(order.getId()); result.setOrderNo(order.getOrderNo()); result.setTotalAmount(order.getTotalAmount()); return result; }这个方法用Transactional包住全部写操作一旦抛出运行时异常Spring 会自动回滚事务。注意我标记了三行注释快照价格、减库存、清购物车。减库存用的是productMapper.decreaseStock对应的 SQL 是UPDATE product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这条 SQL 本身带库存条件天然防超卖。如果受影响行数为 0说明并发下单时库存已经被抢完这时会抛异常触发回滚。后端习惯上把下单接口设计成/api/order/create前端传购物车项列表和收货地址即可。购物车项列表优先传“购物车记录 ID 和数量”而不是直接传商品 ID。这样后端可以从购物车记录里反查商品信息避免前端伪造价格参数。价格永远以后端数据库为准前端传什么价格都不信。3.2 商家接单与出餐状态变更为什么用“比较后更新”商家端登录后能看到新订单列表。接单操作的代码不长但有一个关键细节值得展开讲。public void acceptOrder(String orderNo, Long merchantId) { Orders order ordersMapper.selectByOrderNo(orderNo); if (order null) { throw new BusinessException(订单不存在); } if (!order.getMerchantId().equals(merchantId)) { throw new BusinessException(无权操作该订单); } if (order.getStatus() ! 1 order.getStatus() ! 2) { throw new BusinessException(订单状态不允许接单); } int updated ordersMapper.compareAndUpdateStatus( orderNo, 2, // 期望当前状态已支付 3, // 目标状态已接单 new Date() ); if (updated ! 1) { throw new BusinessException(订单状态已变化请刷新后重试); } }这里的核心不是直接UPDATE orders SET status 3 WHERE order_no ?而是先查一次订单状态再用compareAndUpdateStatus做条件更新。compareAndUpdateStatus的 SQL 是UPDATE orders SET status #{targetStatus}, accept_time #{now} WHERE order_no #{orderNo} AND status #{expectStatus}。查和更新分两步但真正保证原子性的是第二步的 WHERE 条件。这样即使两个商家同时点接单数据库也只会允许一个更新成功另一个因为状态不再匹配而受影响行数为 0。为什么允许状态为 1 或 2 的订单都能接单因为实际业务里用户可能在下单后立刻通过线下转账支付还没等到支付回调更新状态商家这边就看到订单了。给一点状态容错能减少商家电话来问“这个订单怎么接不了”。但状态为 4配送中和 5已完成时一定不能接否则会出现骑手已经在送货、商家还在接单的逻辑混乱。3.3 超时未支付的边界状态机里最容易被遗忘的分支下单后会生成一个“待支付”订单。常见做法是用户主动取消或者在后端做一个超时任务自动关单。这个项目的做法是在订单创建时写入 Redis 过期键key 是order:timeout:{orderNo}过期时间 15 分钟。通过 Redis 的过期回调或者定时扫描 Redis 里的 pending 订单集合把超时订单关掉。public void timeoutCancel(String orderNo) { int updated ordersMapper.compareAndUpdateStatus( orderNo, 1, // 只允许“待支付”状态被超时关单 6, // 目标状态已取消 new Date() ); if (updated 1) { // 关闭支付单、释放库存 restoreStock(orderNo); } }这里有一个边界分支容易漏用户先点击支付但支付网关回调还没回来这时超时任务恰好把订单关掉了。等支付回调到达系统发现订单已经是“已取消”状态这时候绝对不能直接报错更不能把状态从 6 改回 2。正确做法是把回调消息标记为“支付成功但订单已关闭”然后走人工退款流程。我在项目里给支付回调单独加了一张payment_record表记录支付单号和回调内容状态异常时留痕方便对账。这个小改动在实际运营里救过我好几次。4. 骑手调度与状态同步订单状态机的设计与推拉结合4.1 状态机设计六种状态、五条合法变迁路径整个系统的业务复杂度集中在订单状态变更上。项目文档里有一张状态机图我建议你把它记下来因为后面所有推送、对账、统计都围绕这张图展开。当前状态触发事件目标状态执行人1 待支付支付成功回调2 已支付系统自动1 待支付用户取消 / 超时关单6 已取消用户 / 系统2 已支付商家接单3 已接单商家3 已接单骑手取货4 配送中骑手4 配送中骑手确认送达5 已完成骑手2 已支付商家拒单触发退款6 已取消商家这个表告诉我两件事第一状态的跳转不是任意两个状态之间都能走必须经过既定事件第二真正对状态做写操作的只有四种角色——系统支付回调、超时关单、用户取消、商家接单/拒单、骑手取货/送达。在实际编码时我把这张表直接翻译成一个校验类所有状态变更入口统一走这个校验而不是散落在各个 Service 里。如果你在二次开发时想新增一个状态比如“商家已出餐”需要同步改表、改校验类、改前端展示三者缺一不可这是最容易漏的地方。4.2 抢单逻辑数据库行锁比分布式锁更省事骑手端的抢单流程是骑手打开“可抢订单”列表看到待配送的订单点击抢单。可抢订单的来源有两类一是商家接单后自动进入骑手池二是管理后台手动派单后剩余的单子进入骑手池。抢单最大的技术难点是“多人同时抢一单”。我先说项目里的直接做法——数据库乐观锁。public GrabResult grabOrder(String orderNo, Long riderId) { int updated ordersMapper.grabOrder(orderNo, riderId); if (updated 1) { return GrabResult.success(); } return GrabResult.failed(手慢了订单已被抢走); }grabOrder的 SQL 是UPDATE orders SET rider_id #{riderId}, status 4 WHERE order_no #{orderNo} AND rider_id IS NULL AND status 3。这个写法把“校验 rider_id 是否为空”和“写入 rider_id”合并到一条 UPDATE 语句里由数据库的行锁保证同一时刻只有一个骑手能抢到单。相比预先查一遍再用分布式锁的方案这个方案更直接、不会引入 Redis 锁过期之类的新问题。骑手取货之后标记送达用的是类似的compareAndUpdateStatus。取货动作本身有一个隐含约束骑手必须在商家附近才能取货但项目里并没有做严格的 GPS 校验只是在取货接口里传了骑手当前坐标后台记录在delivery_track表里作为追溯依据。如果你的场景需要对“骑手是否真的到店”做硬性校验可以后续在接口里加一个距离判断逻辑。4.3 WebSocket 推送四个频道的订阅关系与消息格式订单状态变化后买家端、商家端、骑手端需要实时感知。项目用的是 WebSocket STOMP 协议后端推送前端订阅。核心配置如下Override public void registerStompEndpoints(StompEndpointRegistry registry) { registry.addEndpoint(/ws) .setAllowedOriginPatterns(*) .withSockJS(); } Override public void configureMessageBroker(MessageBrokerRegistry registry) { registry.enableSimpleBroker(/topic, /queue); registry.setApplicationDestinationPrefixes(/app); }订阅频道按照角色划分频道订阅人推送内容/topic/order/new/{merchantId}商家新订单到达提醒/topic/order/status/{orderNo}买家订单状态变化/topic/rider/task/{riderId}骑手新可抢订单提醒/topic/admin/order管理后台全量订单变化事件推送时机严格绑定状态机事件支付成功推给商家商家接单推给买家骑手取货推给买家送达再推给买家。推送的内容不只包含状态码还包含一个eventType字段比如ORDER_ACCEPTED、ORDER_DELIVERING前端根据eventType决定是弹 toast 还是更新按钮状态而不是每次都刷新整页。实际运营时我发现一个坑WebSocket 连接不是百分百可靠的校园网环境下很容易断线。所以前端在订阅频道的同时也保留了setInterval拉取订单详情的接口作为兜底每 30 秒拉一次。这个“推拉结合”的模式在定位断连问题时非常有帮助——先看 WebSocket 是否重连再看兜底轮询是否触发基本能定位到是哪一层出了问题。5. 避坑指南部署与数据一致性里的五个真实翻车点5.1 前端页面能打开但所有接口返回 404现象npm run serve正常启动页面样式、路由都正常但点击任何按钮都提示接口不存在。原因前端的vue.config.js里代理配置指向了localhost:8081但后端服务实际跑在别的端口或者后端启动时改了 context-path。另外还有一种可能是前端代码是从某个环境拷贝过来的代理目标还残留着旧 IP。解决先打开浏览器开发者工具的 Network 面板看请求实际发到哪个地址。如果地址不是localhost:8081修改vue.config.js里的target字段然后重启npm run serve。如果是后端改了 context-path需要统一修改前端的代理前缀和后端的server.servlet.context-path这两处必须一致。5.2 订单金额出现 0.30000000000000004 之类的怪异数值现象一个 0.1 元加 0.2 元的订单数据库里总金额显示 0.30000000000000004。原因数据库字段用了DECIMAL(10,2)或FLOAT前端传参用字符串后端用BigDecimal转换时精度有损耗或者更直接的情况是代码里用了double计算金额。解决我前面已经强调过项目表结构里金额字段全部是 INT 存“分”。如果你的代码是从别处改来的搜索一下所有double、float、BigDecimal的使用点统一改成整数运算。前端展示金额时用(cents / 100).toFixed(2)转换即可注意toFixed返回的是字符串传给后端前要先转数字。5.3 用户取消订单后库存数量对不上现象用户下单买了两件商品取消订单后商品库存没有加回来或者加回来的数量不对。原因取消订单的回滚逻辑只恢复了订单主表的状态没有遍历订单明细去恢复商品库存。更隐蔽的原因是在取消之前商家已经接单出餐库存已经被商家做了出库操作此时恢复库存就是错的——需要区分“取消时点”和“是否已出餐”。解决取消订单接口里先检查订单状态只有状态为 1待支付或 2已支付的订单才允许恢复库存。状态为 3已接单以上的订单库存已经进入出餐环节取消后应由商家在管理后台手动确认处理不能自动恢复。恢复库存的 SQL 用UPDATE product SET stock stock #{qty} WHERE id #{pid}不需要额外判断库存上限因为恢复的一定是之前扣掉的那部分。5.4 管理后台看到的订单时间比实际时间晚 8 小时现象用户下单是上午 10 点管理后台显示下午 6 点。原因MySQL 连接串缺少serverTimezoneAsia/Shanghai导致 JDBC 驱动用了默认时区UTC读写时间时发生了 8 小时偏移。如果只改了 JDBC 时区但 Spring Boot 的jackson.time-zone没有同步改会出现“数据库正确、接口返回给前端错误”的二次偏移。解决统一在三处配置时区——MySQL 连接串里的serverTimezoneAsia/Shanghai、application.yml里的jackson.time-zone: GMT8、MySQL 数据库本身的default-time-zone。改完之后重启后端服务重新生成一个新订单验证时间。5.5 批量导入商家数据时中文全部乱码现象用 SQL 脚本或者 CSV 文件批量导入商家地址管理后台显示“???”或乱码。原因CSV 文件保存时用的是 ANSI 编码而数据库连接串指定了characterEncodingutf8两边编码不一致。SQL 脚本则可能是文件本身是 GBK 编码但 MySQL 客户端按 UTF-8 解析执行。解决CSV 文件统一用“UTF-8 with BOM”格式保存Excel 另存时选择“CSV UTF-8逗号分隔”SQL 脚本在文件头部加上SET NAMES utf8mb4;再执行。另有一个细节数据库表本身的CHARSET必须是utf8mb4而不是utf8否则遇到生僻汉字或 emoji 表情会直接报错或变问号。6. 试运行验证与二次开发方向让系统真正可用起来拿到这个压缩包别急着改业务代码。我的习惯是先原封不动跑一遍完整链路确认没有环境问题之后再做二次开发。具体操作分三步第一步往后端数据库导入项目自带的init_data.sql里面包含了几个测试商家、测试商品和两个骑手账号第二步启动后端和买家端注册一个买家账号走一遍“搜索商品→加入购物车→下单→支付模拟→等商家接单”的流程第三步用骑手账号登录骑手端找到刚才的订单执行“抢单→取货→送达”然后在买家端确认状态是否变为“已完成”。跑通这三步就说明整个系统最核心的主链路没有断。接下来是二次开发方向。如果这是课程设计推荐优先改两个点一是把支付模拟接口替换成真实支付网关项目里预留了PaymentService接口目前只实现了“模拟支付成功”你可以补充一个真实沙箱环境的对接实现二是给管理后台增加一个“配送统计”页面用订单表里的finish_time - create_time计算平均配送时长按商家维度分组展示。这两个改动都不涉及底层表结构调整但能显著提升项目的完整度。如果这是要真实运营我会建议优先优化骑手派单逻辑。当前版本是“抢单制”高峰期会出现部分骑手抢到多单、部分骑手无单可抢的失衡。可以改成“得分排序派单”每个骑手维护一个current_load字段推送新订单时只推给当前负载最低且距离最近的骑手。这个改动涉及三处——数据库加字段、商家接单后触发的推送逻辑、骑手端列表的过滤条件工作量在两到三天左右。最后说一个我自己的教训。刚开始接触这类订单系统时我总觉得状态变更就是UPDATE ... SET status newStatus这么简单直到有一次调试线上问题发现一个订单从“配送中”直接变成了“已完成”但骑手根本没有点过送达按钮排查半天才发现是管理后台的“一键完成全部订单”脚本误触发了。从那以后我每次做这类系统都会强制走一遍状态机表格把每个状态能触发的动作全部列出来贴在代码注释里再写任何状态更新逻辑之前先对一遍表。希望帮到你。本文还有配套的精品资源点击获取
