简介高校社区生鲜配送系统是一套面向大学生及周边社区居民的在线生鲜购物平台源码适合计算机专业学生做课程设计、毕业设计或Java Web入门实战练习。系统围绕用户管理、商品管理、订单处理、库存控制、配送调度、支付接口、数据分析、客户服务与移动端适配等模块展开完整呈现从下单、扣减库存到配送签收的业务闭环可帮助读者理解电商类项目的分层结构与模块协作方式。压缩包共909个文件以html页面、css样式、js脚本、png与gif图片等前端资源以及120个java源文件、152个class编译文件为主另含sql建表脚本、json与yml配置等整体约1.61MB目录结构清晰便于按模块查阅。已有139人学习关注适合需要一套可直接运行、便于二次开发的生鲜配送项目参考的读者。1. 从一份能跑起来的社区生鲜配送源码说起去年帮一个做校园创业的朋友看后台他手里攒了七八份“生鲜配送系统”的源码包大部分解压出来只有半截前端页面后端接口全是 mock 数据连订单状态流转都跑不通。直到翻到这份高校社区生鲜配送系统结构完整、前后端能对上、数据库脚本齐全才算真正能落地改的那种。它解决的是社区团购场景里最典型的一摊事用户下单买菜、按自提点或楼栋分组、后台管商品和库存、配送员按批次拣货送达。适合两类人——想拿一套完整业务链路练手的学生开发者以及要给小型社区、校园跑腿团队快速搭一套下单系统的独立开发者。下面按“能干什么、怎么跑、怎么改”的顺序拆开讲中间会落到具体目录和核心代码照着抄能少走不少弯路。2. 技术栈与目录结构一套前后端分离的电商骨架2.1 技术选型判断为什么是这套组合从源码包的组织方式看这是一个典型的前后端分离项目。后端大概率是 Spring Boot MyBatis-Plus MySQL 的组合前端是 Vue 2 或 Vue 3 加 Element UI / Vant 的移动端页面管理后台单独一套。这个判断不是拍脑袋——生鲜配送这类业务有商品、订单、用户、自提点、配送批次五六个核心实体关系型数据库最顺手MySQL 几乎是标配后端用 Spring Boot 是因为它能把权限、定时任务、文件上传这些周边能力一次性带齐不用自己拼装。我一般看一个电商类源码包先看三处pom.xml或package.json里的依赖、application.yml里的数据源配置、sql目录下的建表脚本。这三处对得上项目基本能跑对不上后面全是坑。这份源码包在这三点上是齐的说明作者至少自己完整跑通过一遍。技术栈大致如下具体版本以包内pom.xml和package.json为准层次技术作用后端框架Spring Boot提供 REST 接口、依赖注入、自动配置持久层MyBatis-Plus单表 CRUD 免写 SQL分页插件开箱即用数据库MySQL 5.7 / 8.0存商品、订单、用户、自提点数据缓存Redis可选存登录 token、商品分类缓存前端用户端Vue Vant移动端下单、查看订单前端管理端Vue Element UI商品管理、订单管理、配送调度构建工具Maven / npm后端打包、前端构建提示如果包内没有 Redis 配置说明缓存是可选项直接注释掉相关依赖也能跑别一上来就被 Redis 卡住。2.2 目录结构拆解每个文件夹负责什么解压后一般能看到这样的分层不同作者命名略有差异但职责划分基本一致community-fresh-delivery/ ├── backend/ # 后端 Spring Boot 工程 │ ├── src/main/java/ │ │ └── com/xxx/delivery/ │ │ ├── controller/ # 接口层对外暴露 REST │ │ ├── service/ # 业务逻辑订单流转在这 │ │ ├── mapper/ # MyBatis 映射接口 │ │ ├── entity/ # 数据库实体类 │ │ ├── config/ # 跨域、拦截器、MyBatis 配置 │ │ └── common/ # 统一返回体、异常处理 │ ├── src/main/resources/ │ │ ├── application.yml # 数据源、端口、上传路径 │ │ └── mapper/ # XML 映射文件复杂查询用 │ └── pom.xml ├── frontend-user/ # 用户端 Vue 工程 ├── frontend-admin/ # 管理端 Vue 工程 └── sql/ └── delivery.sql # 建库建表 初始数据这个结构的关键在于controller → service → mapper三层分明。改业务基本只动service加接口只动controller查数据出问题先看mapper对应的 XML。新手最容易犯的错是直接在 controller 里写业务逻辑改两行就乱套这份源码的分层是干净的值得照着维护。2.3 数据库设计五张核心表撑起整条链路生鲜配送的业务闭环全压在表关系上。打开sql/delivery.sql重点看这几张表user用户表含手机号、楼栋/自提点归属、角色字段普通用户 / 配送员 / 管理员product商品表含分类、单价、库存、上下架状态orders订单主表含订单号、用户 ID、自提点 ID、总金额、订单状态order_item订单明细表一个订单多条商品记录delivery_batch配送批次表把同一自提点的订单聚成一批配送员按批次拣货订单状态字段是整个系统的“黑匣子”常见取值是0 待支付 / 1 已支付待配送 / 2 配送中 / 3 已完成 / 4 已取消。改业务前先把这张状态流转图画在纸上不然改到后面自己都记不清哪个状态该触发什么动作。-- 订单主表核心字段示意以包内脚本为准 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号, user_id BIGINT NOT NULL COMMENT 下单用户, pickup_id BIGINT NOT NULL COMMENT 自提点ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总额, status TINYINT DEFAULT 0 COMMENT 0待支付 1待配送 2配送中 3已完成 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no) ) COMMENT 订单主表;order_no加了唯一索引这是防止重复下单的第一道防线pickup_id是配送分组的依据后面按自提点聚合订单就靠它。建表脚本里如果带了初始管理员账号登录后台时直接用别自己瞎猜密码。3. 本地跑通从建库到前后端联调的完整步骤3.1 环境准备与数据库导入先把环境对齐版本差太多会出玄学问题。我一般固定这套JDK 8 或 11、Maven 3.6、MySQL 5.7、Node.js 14/16。Node 版本别上太高老 Vue 项目在 Node 18 以上经常报 OpenSSL 相关的构建错误这是血泪经验。建库导入分三步# 1. 登录 MySQL 并建库 mysql -u root -p -e CREATE DATABASE delivery_db DEFAULT CHARSET utf8mb4; # 2. 导入建表脚本和初始数据 mysql -u root -p delivery_db sql/delivery.sql # 3. 验证表是否建全 mysql -u root -p -e USE delivery_db; SHOW TABLES;导入后确认五张核心表都在并且user表里有初始管理员记录。如果脚本报错多半是字符集或 MySQL 版本语法差异把utf8mb4和ENGINEInnoDB检查一遍。3.2 后端配置修改与启动打开backend/src/main/resources/application.yml改三处数据库连接、服务端口、文件上传路径。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/delivery_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB # 商品图片上传上限 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: trueserverTimezone必须显式指定不然插入订单时间会差 8 小时排查半天以为是代码问题。map-underscore-to-camel-case打开后数据库的create_time能自动映射到实体类的createTime省掉一堆手动映射。改完在backend目录下执行mvn clean package -DskipTests java -jar target/*.jar # 或者开发模式直接 mvn spring-boot:run看到Started Application in xxx seconds就说明后端起来了。先用浏览器或 curl 访问一个不需要登录的接口验证比如商品列表GET /api/product/list返回 JSON 就通了。3.3 前端两个工程的启动与接口代理用户端和管理端是两个独立工程分别进目录装依赖启动# 用户端 cd frontend-user npm install npm run serve # 管理端另开终端 cd frontend-admin npm install npm run serve启动后默认跑在 8081、8082 之类的端口。关键在接口代理配置打开vue.config.js或vite.config.js确认proxy指向后端 8080// vue.config.js 片段 module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, // 后端地址 changeOrigin: true, // 如果后端接口本身不带 /api 前缀这里要 pathRewrite // pathRewrite: { ^/api: } } } } }changeOrigin: true解决跨域pathRewrite要不要开取决于后端 controller 的RequestMapping有没有/api前缀这两处必须对齐否则前端全是 404。联调顺序建议是先跑通登录接口拿到 token 存进 localStorage再逐个页面验证别一上来就点下单。4. 核心模块拆解订单创建与配送批次是怎么串起来的4.1 订单创建库存扣减和订单号生成订单创建是整个系统最容易翻车的地方涉及库存、金额、事务三件事。看OrderService里的创建方法逻辑大致是这样Service public class OrderServiceImpl implements OrderService { Autowired private ProductMapper productMapper; Autowired private OrderMapper orderMapper; Autowired private OrderItemMapper orderItemMapper; Override Transactional(rollbackFor Exception.class) // 任何异常都回滚 public String createOrder(Long userId, Long pickupId, ListOrderItemDTO items) { BigDecimal total BigDecimal.ZERO; // 1. 逐条校验库存并扣减 for (OrderItemDTO item : items) { Product p productMapper.selectById(item.getProductId()); if (p null || p.getStatus() 0) { throw new BizException(商品已下架); } if (p.getStock() item.getQuantity()) { throw new BizException(库存不足 p.getName()); } // 乐观锁式扣减防止超卖 int rows productMapper.deductStock(p.getId(), item.getQuantity()); if (rows 0) { throw new BizException(库存扣减失败请重试); } total total.add(p.getPrice().multiply(new BigDecimal(item.getQuantity()))); } // 2. 生成订单主记录 Orders order new Orders(); order.setOrderNo(generateOrderNo()); // 时间戳随机数 order.setUserId(userId); order.setPickupId(pickupId); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 3. 写入订单明细 for (OrderItemDTO item : items) { OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setProductId(item.getProductId()); oi.setQuantity(item.getQuantity()); orderItemMapper.insert(oi); } return order.getOrderNo(); } }几个关键点Transactional保证扣库存和写订单要么全成要么全败库存扣减用UPDATE product SET stock stock - #{qty} WHERE id #{id} AND stock #{qty}这种带条件的更新靠数据库行锁防超卖比先查再改安全得多订单号用时间戳加随机数别用自增 ID 直接暴露。金额用BigDecimal而不是double这是电商铁律浮点误差在结算时会被放大。4.2 配送批次聚合按自提点把订单打包配送环节的核心是把同一自提点的待配送订单聚成一批配送员一次拣完。DeliveryService里通常有个按自提点分组的方法public ListDeliveryBatchVO buildBatch(Long pickupId) { // 1. 查出该自提点所有待配送订单 ListOrders orders orderMapper.selectByPickupAndStatus(pickupId, 1); if (orders.isEmpty()) { return Collections.emptyList(); } // 2. 按商品汇总算出每个商品要拣多少件 MapLong, Integer productSum new HashMap(); for (Orders o : orders) { ListOrderItem items orderItemMapper.selectByOrderId(o.getId()); for (OrderItem it : items) { productSum.merge(it.getProductId(), it.getQuantity(), Integer::sum); } } // 3. 组装批次视图供配送员拣货 DeliveryBatchVO vo new DeliveryBatchVO(); vo.setPickupId(pickupId); vo.setOrderCount(orders.size()); vo.setItems(productSum); return Collections.singletonList(vo); }这段逻辑的价值在于把“按订单拣货”变成“按商品汇总拣货”配送员不用一单一单翻直接看汇总清单一次拿齐。merge那行是汇总的关键相同商品数量累加。实际改造时可以把批次落库到delivery_batch表加上批次状态和配送员 ID就能做配送进度追踪。4.3 统一返回体与全局异常接口层的兜底设计前后端联调顺不顺很大程度看返回体是否统一。common包里一般有Result和GlobalExceptionHandlerData public class ResultT { private Integer code; // 200 成功500 业务异常 private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.setCode(200); r.setMsg(success); r.setData(data); return r; } public static T ResultT fail(String msg) { ResultT r new Result(); r.setCode(500); r.setMsg(msg); return r; } }配合RestControllerAdvice捕获BizException前端只需要判断code 200不用每个接口写一套错误处理。这套设计看着简单但很多半成品源码没有导致前端拿到 500 还得猜是哪个字段错了改起来极其痛苦。5. 避坑与排查跑不起来时先看这几处5.1 数据库连不上或表不存在现象是启动报Communications link failure或查询报Table delivery_db.orders doesnt exist。原因通常是application.yml里的库名和实际建库名不一致或者 SQL 脚本只导了结构没导数据。解决方式是先用命令行SHOW TABLES确认表在再核对 yml 里的url库名注意别把delivery_db写成delivery。5.2 前端请求全部 404现象是页面能打开但所有接口报 404。原因多半是代理的pathRewrite和后端接口前缀没对齐——后端接口是/product/list前端请求写的是/api/product/list代理没重写就打到后端 404。解决方式是打开浏览器 Network 看实际请求路径再对照vue.config.js的proxy配置要么加pathRewrite要么统一后端加/api前缀。5.3 登录后刷新页面掉登录态现象是登录成功一刷新就退回登录页。原因是 token 只存在了 Vuex/Pinia 内存里没持久化到 localStorage。解决方式是在登录成功后localStorage.setItem(token, token)并在路由守卫或请求拦截器里从 localStorage 读取别只依赖内存状态。5.4 图片上传后访问 404现象是商品图上传成功但页面显示裂图。原因是上传路径存的是服务器绝对路径而静态资源映射没配。解决方式是在WebMvcConfigurer里加addResourceHandlers把上传目录映射成/upload/**数据库里只存相对路径前端拼上域名访问。5.5 Node 版本过高导致前端构建失败现象是npm run serve报error:0308010C:digital envelope routines::unsupported。原因是 Node 17 以上改了 OpenSSL 默认行为老 Vue CLI 不兼容。解决方式是降到 Node 16或者临时设置NODE_OPTIONS--openssl-legacy-provider再启动。这个坑几乎每个老 Vue 项目都会遇到一次。6. 二次开发从能跑到能用的改造思路拿到这套源码直接上线肯定不够得按实际场景补几块。第一块是支付源码里订单状态从待支付到已支付大概率是手动改的接入真实支付时在OrderService的支付回调里改状态务必做幂等——同一个订单回调多次只能成功一次用订单号加状态条件更新就能防住。第二块是库存并发如果社区单量上来deductStock的乐观锁要配合重试失败时给用户明确提示而不是直接抛异常。第三块是配送追踪把delivery_batch表用起来加配送员 ID 和批次状态用户端就能看到“拣货中 / 配送中 / 已送达”。改造时我习惯先写一个最小验证脚本比如用 curl 跑一遍“登录 → 加购 → 下单 → 查订单”的完整链路改完任何一块都重跑一遍确认没把主流程改断。下面这个脚本可以直接抄# 1. 登录拿 token TOKEN$(curl -s -X POST http://localhost:8080/api/user/login \ -H Content-Type: application/json \ -d {phone:13800000000,password:123456} | jq -r .data.token) # 2. 下单 curl -s -X POST http://localhost:8080/api/order/create \ -H Content-Type: application/json \ -H Authorization: $TOKEN \ -d {pickupId:1,items:[{productId:1,quantity:2}]} # 3. 查订单列表确认状态 curl -s http://localhost:8080/api/order/list -H Authorization: $TOKEN | jq用jq解析返回能快速看出哪一步的code不是 200。这套脚本我一般存成smoke-test.sh每次改完核心逻辑跑一遍比手点页面靠谱得多。还有一个容易被忽略的点源码里的权限控制可能只做了登录校验没做角色隔离。管理端接口如果普通用户 token 也能调就是安全隐患。改造时在拦截器里加角色判断user.role不是管理员直接返回 403这一步花不了多少时间但能挡掉大部分越权问题。从那以后我每次接手这类电商源码都强制先跑一遍冒烟脚本再动代码确认基线是通的改坏了也能快速定位是哪次改动引入的。希望这套拆解能帮到你少在环境配置上耗时间把精力留给业务改造。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 4:31:02 · 阅读 1.2k 高校社区生鲜配送系统源码解析：从跑通到二次开发
简介高校社区生鲜配送系统是一套面向大学生及周边社区居民的在线生鲜购物平台源码适合计算机专业学生做课程设计、毕业设计或Java Web入门实战练习。系统围绕用户管理、商品管理、订单处理、库存控制、配送调度、支付接口、数据分析、客户服务与移动端适配等模块展开完整呈现从下单、扣减库存到配送签收的业务闭环可帮助读者理解电商类项目的分层结构与模块协作方式。压缩包共909个文件以html页面、css样式、js脚本、png与gif图片等前端资源以及120个java源文件、152个class编译文件为主另含sql建表脚本、json与yml配置等整体约1.61MB目录结构清晰便于按模块查阅。已有139人学习关注适合需要一套可直接运行、便于二次开发的生鲜配送项目参考的读者。1. 从一份能跑起来的社区生鲜配送源码说起去年帮一个做校园创业的朋友看后台他手里攒了七八份“生鲜配送系统”的源码包大部分解压出来只有半截前端页面后端接口全是 mock 数据连订单状态流转都跑不通。直到翻到这份高校社区生鲜配送系统结构完整、前后端能对上、数据库脚本齐全才算真正能落地改的那种。它解决的是社区团购场景里最典型的一摊事用户下单买菜、按自提点或楼栋分组、后台管商品和库存、配送员按批次拣货送达。适合两类人——想拿一套完整业务链路练手的学生开发者以及要给小型社区、校园跑腿团队快速搭一套下单系统的独立开发者。下面按“能干什么、怎么跑、怎么改”的顺序拆开讲中间会落到具体目录和核心代码照着抄能少走不少弯路。2. 技术栈与目录结构一套前后端分离的电商骨架2.1 技术选型判断为什么是这套组合从源码包的组织方式看这是一个典型的前后端分离项目。后端大概率是 Spring Boot MyBatis-Plus MySQL 的组合前端是 Vue 2 或 Vue 3 加 Element UI / Vant 的移动端页面管理后台单独一套。这个判断不是拍脑袋——生鲜配送这类业务有商品、订单、用户、自提点、配送批次五六个核心实体关系型数据库最顺手MySQL 几乎是标配后端用 Spring Boot 是因为它能把权限、定时任务、文件上传这些周边能力一次性带齐不用自己拼装。我一般看一个电商类源码包先看三处pom.xml或package.json里的依赖、application.yml里的数据源配置、sql目录下的建表脚本。这三处对得上项目基本能跑对不上后面全是坑。这份源码包在这三点上是齐的说明作者至少自己完整跑通过一遍。技术栈大致如下具体版本以包内pom.xml和package.json为准层次技术作用后端框架Spring Boot提供 REST 接口、依赖注入、自动配置持久层MyBatis-Plus单表 CRUD 免写 SQL分页插件开箱即用数据库MySQL 5.7 / 8.0存商品、订单、用户、自提点数据缓存Redis可选存登录 token、商品分类缓存前端用户端Vue Vant移动端下单、查看订单前端管理端Vue Element UI商品管理、订单管理、配送调度构建工具Maven / npm后端打包、前端构建提示如果包内没有 Redis 配置说明缓存是可选项直接注释掉相关依赖也能跑别一上来就被 Redis 卡住。2.2 目录结构拆解每个文件夹负责什么解压后一般能看到这样的分层不同作者命名略有差异但职责划分基本一致community-fresh-delivery/ ├── backend/ # 后端 Spring Boot 工程 │ ├── src/main/java/ │ │ └── com/xxx/delivery/ │ │ ├── controller/ # 接口层对外暴露 REST │ │ ├── service/ # 业务逻辑订单流转在这 │ │ ├── mapper/ # MyBatis 映射接口 │ │ ├── entity/ # 数据库实体类 │ │ ├── config/ # 跨域、拦截器、MyBatis 配置 │ │ └── common/ # 统一返回体、异常处理 │ ├── src/main/resources/ │ │ ├── application.yml # 数据源、端口、上传路径 │ │ └── mapper/ # XML 映射文件复杂查询用 │ └── pom.xml ├── frontend-user/ # 用户端 Vue 工程 ├── frontend-admin/ # 管理端 Vue 工程 └── sql/ └── delivery.sql # 建库建表 初始数据这个结构的关键在于controller → service → mapper三层分明。改业务基本只动service加接口只动controller查数据出问题先看mapper对应的 XML。新手最容易犯的错是直接在 controller 里写业务逻辑改两行就乱套这份源码的分层是干净的值得照着维护。2.3 数据库设计五张核心表撑起整条链路生鲜配送的业务闭环全压在表关系上。打开sql/delivery.sql重点看这几张表user用户表含手机号、楼栋/自提点归属、角色字段普通用户 / 配送员 / 管理员product商品表含分类、单价、库存、上下架状态orders订单主表含订单号、用户 ID、自提点 ID、总金额、订单状态order_item订单明细表一个订单多条商品记录delivery_batch配送批次表把同一自提点的订单聚成一批配送员按批次拣货订单状态字段是整个系统的“黑匣子”常见取值是0 待支付 / 1 已支付待配送 / 2 配送中 / 3 已完成 / 4 已取消。改业务前先把这张状态流转图画在纸上不然改到后面自己都记不清哪个状态该触发什么动作。-- 订单主表核心字段示意以包内脚本为准 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 订单号, user_id BIGINT NOT NULL COMMENT 下单用户, pickup_id BIGINT NOT NULL COMMENT 自提点ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总额, status TINYINT DEFAULT 0 COMMENT 0待支付 1待配送 2配送中 3已完成 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no) ) COMMENT 订单主表;order_no加了唯一索引这是防止重复下单的第一道防线pickup_id是配送分组的依据后面按自提点聚合订单就靠它。建表脚本里如果带了初始管理员账号登录后台时直接用别自己瞎猜密码。3. 本地跑通从建库到前后端联调的完整步骤3.1 环境准备与数据库导入先把环境对齐版本差太多会出玄学问题。我一般固定这套JDK 8 或 11、Maven 3.6、MySQL 5.7、Node.js 14/16。Node 版本别上太高老 Vue 项目在 Node 18 以上经常报 OpenSSL 相关的构建错误这是血泪经验。建库导入分三步# 1. 登录 MySQL 并建库 mysql -u root -p -e CREATE DATABASE delivery_db DEFAULT CHARSET utf8mb4; # 2. 导入建表脚本和初始数据 mysql -u root -p delivery_db sql/delivery.sql # 3. 验证表是否建全 mysql -u root -p -e USE delivery_db; SHOW TABLES;导入后确认五张核心表都在并且user表里有初始管理员记录。如果脚本报错多半是字符集或 MySQL 版本语法差异把utf8mb4和ENGINEInnoDB检查一遍。3.2 后端配置修改与启动打开backend/src/main/resources/application.yml改三处数据库连接、服务端口、文件上传路径。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/delivery_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB # 商品图片上传上限 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: trueserverTimezone必须显式指定不然插入订单时间会差 8 小时排查半天以为是代码问题。map-underscore-to-camel-case打开后数据库的create_time能自动映射到实体类的createTime省掉一堆手动映射。改完在backend目录下执行mvn clean package -DskipTests java -jar target/*.jar # 或者开发模式直接 mvn spring-boot:run看到Started Application in xxx seconds就说明后端起来了。先用浏览器或 curl 访问一个不需要登录的接口验证比如商品列表GET /api/product/list返回 JSON 就通了。3.3 前端两个工程的启动与接口代理用户端和管理端是两个独立工程分别进目录装依赖启动# 用户端 cd frontend-user npm install npm run serve # 管理端另开终端 cd frontend-admin npm install npm run serve启动后默认跑在 8081、8082 之类的端口。关键在接口代理配置打开vue.config.js或vite.config.js确认proxy指向后端 8080// vue.config.js 片段 module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, // 后端地址 changeOrigin: true, // 如果后端接口本身不带 /api 前缀这里要 pathRewrite // pathRewrite: { ^/api: } } } } }changeOrigin: true解决跨域pathRewrite要不要开取决于后端 controller 的RequestMapping有没有/api前缀这两处必须对齐否则前端全是 404。联调顺序建议是先跑通登录接口拿到 token 存进 localStorage再逐个页面验证别一上来就点下单。4. 核心模块拆解订单创建与配送批次是怎么串起来的4.1 订单创建库存扣减和订单号生成订单创建是整个系统最容易翻车的地方涉及库存、金额、事务三件事。看OrderService里的创建方法逻辑大致是这样Service public class OrderServiceImpl implements OrderService { Autowired private ProductMapper productMapper; Autowired private OrderMapper orderMapper; Autowired private OrderItemMapper orderItemMapper; Override Transactional(rollbackFor Exception.class) // 任何异常都回滚 public String createOrder(Long userId, Long pickupId, ListOrderItemDTO items) { BigDecimal total BigDecimal.ZERO; // 1. 逐条校验库存并扣减 for (OrderItemDTO item : items) { Product p productMapper.selectById(item.getProductId()); if (p null || p.getStatus() 0) { throw new BizException(商品已下架); } if (p.getStock() item.getQuantity()) { throw new BizException(库存不足 p.getName()); } // 乐观锁式扣减防止超卖 int rows productMapper.deductStock(p.getId(), item.getQuantity()); if (rows 0) { throw new BizException(库存扣减失败请重试); } total total.add(p.getPrice().multiply(new BigDecimal(item.getQuantity()))); } // 2. 生成订单主记录 Orders order new Orders(); order.setOrderNo(generateOrderNo()); // 时间戳随机数 order.setUserId(userId); order.setPickupId(pickupId); order.setTotalAmount(total); order.setStatus(0); orderMapper.insert(order); // 3. 写入订单明细 for (OrderItemDTO item : items) { OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setProductId(item.getProductId()); oi.setQuantity(item.getQuantity()); orderItemMapper.insert(oi); } return order.getOrderNo(); } }几个关键点Transactional保证扣库存和写订单要么全成要么全败库存扣减用UPDATE product SET stock stock - #{qty} WHERE id #{id} AND stock #{qty}这种带条件的更新靠数据库行锁防超卖比先查再改安全得多订单号用时间戳加随机数别用自增 ID 直接暴露。金额用BigDecimal而不是double这是电商铁律浮点误差在结算时会被放大。4.2 配送批次聚合按自提点把订单打包配送环节的核心是把同一自提点的待配送订单聚成一批配送员一次拣完。DeliveryService里通常有个按自提点分组的方法public ListDeliveryBatchVO buildBatch(Long pickupId) { // 1. 查出该自提点所有待配送订单 ListOrders orders orderMapper.selectByPickupAndStatus(pickupId, 1); if (orders.isEmpty()) { return Collections.emptyList(); } // 2. 按商品汇总算出每个商品要拣多少件 MapLong, Integer productSum new HashMap(); for (Orders o : orders) { ListOrderItem items orderItemMapper.selectByOrderId(o.getId()); for (OrderItem it : items) { productSum.merge(it.getProductId(), it.getQuantity(), Integer::sum); } } // 3. 组装批次视图供配送员拣货 DeliveryBatchVO vo new DeliveryBatchVO(); vo.setPickupId(pickupId); vo.setOrderCount(orders.size()); vo.setItems(productSum); return Collections.singletonList(vo); }这段逻辑的价值在于把“按订单拣货”变成“按商品汇总拣货”配送员不用一单一单翻直接看汇总清单一次拿齐。merge那行是汇总的关键相同商品数量累加。实际改造时可以把批次落库到delivery_batch表加上批次状态和配送员 ID就能做配送进度追踪。4.3 统一返回体与全局异常接口层的兜底设计前后端联调顺不顺很大程度看返回体是否统一。common包里一般有Result和GlobalExceptionHandlerData public class ResultT { private Integer code; // 200 成功500 业务异常 private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.setCode(200); r.setMsg(success); r.setData(data); return r; } public static T ResultT fail(String msg) { ResultT r new Result(); r.setCode(500); r.setMsg(msg); return r; } }配合RestControllerAdvice捕获BizException前端只需要判断code 200不用每个接口写一套错误处理。这套设计看着简单但很多半成品源码没有导致前端拿到 500 还得猜是哪个字段错了改起来极其痛苦。5. 避坑与排查跑不起来时先看这几处5.1 数据库连不上或表不存在现象是启动报Communications link failure或查询报Table delivery_db.orders doesnt exist。原因通常是application.yml里的库名和实际建库名不一致或者 SQL 脚本只导了结构没导数据。解决方式是先用命令行SHOW TABLES确认表在再核对 yml 里的url库名注意别把delivery_db写成delivery。5.2 前端请求全部 404现象是页面能打开但所有接口报 404。原因多半是代理的pathRewrite和后端接口前缀没对齐——后端接口是/product/list前端请求写的是/api/product/list代理没重写就打到后端 404。解决方式是打开浏览器 Network 看实际请求路径再对照vue.config.js的proxy配置要么加pathRewrite要么统一后端加/api前缀。5.3 登录后刷新页面掉登录态现象是登录成功一刷新就退回登录页。原因是 token 只存在了 Vuex/Pinia 内存里没持久化到 localStorage。解决方式是在登录成功后localStorage.setItem(token, token)并在路由守卫或请求拦截器里从 localStorage 读取别只依赖内存状态。5.4 图片上传后访问 404现象是商品图上传成功但页面显示裂图。原因是上传路径存的是服务器绝对路径而静态资源映射没配。解决方式是在WebMvcConfigurer里加addResourceHandlers把上传目录映射成/upload/**数据库里只存相对路径前端拼上域名访问。5.5 Node 版本过高导致前端构建失败现象是npm run serve报error:0308010C:digital envelope routines::unsupported。原因是 Node 17 以上改了 OpenSSL 默认行为老 Vue CLI 不兼容。解决方式是降到 Node 16或者临时设置NODE_OPTIONS--openssl-legacy-provider再启动。这个坑几乎每个老 Vue 项目都会遇到一次。6. 二次开发从能跑到能用的改造思路拿到这套源码直接上线肯定不够得按实际场景补几块。第一块是支付源码里订单状态从待支付到已支付大概率是手动改的接入真实支付时在OrderService的支付回调里改状态务必做幂等——同一个订单回调多次只能成功一次用订单号加状态条件更新就能防住。第二块是库存并发如果社区单量上来deductStock的乐观锁要配合重试失败时给用户明确提示而不是直接抛异常。第三块是配送追踪把delivery_batch表用起来加配送员 ID 和批次状态用户端就能看到“拣货中 / 配送中 / 已送达”。改造时我习惯先写一个最小验证脚本比如用 curl 跑一遍“登录 → 加购 → 下单 → 查订单”的完整链路改完任何一块都重跑一遍确认没把主流程改断。下面这个脚本可以直接抄# 1. 登录拿 token TOKEN$(curl -s -X POST http://localhost:8080/api/user/login \ -H Content-Type: application/json \ -d {phone:13800000000,password:123456} | jq -r .data.token) # 2. 下单 curl -s -X POST http://localhost:8080/api/order/create \ -H Content-Type: application/json \ -H Authorization: $TOKEN \ -d {pickupId:1,items:[{productId:1,quantity:2}]} # 3. 查订单列表确认状态 curl -s http://localhost:8080/api/order/list -H Authorization: $TOKEN | jq用jq解析返回能快速看出哪一步的code不是 200。这套脚本我一般存成smoke-test.sh每次改完核心逻辑跑一遍比手点页面靠谱得多。还有一个容易被忽略的点源码里的权限控制可能只做了登录校验没做角色隔离。管理端接口如果普通用户 token 也能调就是安全隐患。改造时在拦截器里加角色判断user.role不是管理员直接返回 403这一步花不了多少时间但能挡掉大部分越权问题。从那以后我每次接手这类电商源码都强制先跑一遍冒烟脚本再动代码确认基线是通的改坏了也能快速定位是哪次改动引入的。希望这套拆解能帮到你少在环境配置上耗时间把精力留给业务改造。本文还有配套的精品资源点击获取