做校园跑腿这种项目最容易被低估的地方恰恰不是代码本身而是“业务流程到底怎么闭环”。很多人一上来就建表写接口做到一半才发现跑腿订单的取消、转单、超时、纠纷这些状态根本没人管最后只能硬编码一堆if else。这篇文章我会把这些年做类似项目的经验围绕SpringBoot和Vue这套全栈组合从需求拆解、技术选型、后端状态机、前端权限控制、真实踩坑到部署上线完整地讲一遍希望能给正在做毕设或者接私活的朋友省点试错成本。1. 先看业务再谈技术校园跑腿到底在做什么1.1 从代取快递到代买饭需求边界的确认校园跑腿网站的典型场景就是学生没时间或者懒得动找人帮忙代取快递、代买饭、代排队。听起来很简单但如果你真的把它当电商项目做很容易做出一个“四不像”。我复盘过手上的校园服务项目真正核心的链路只有一条用户下单 → 跑腿员接单 → 跑腿员送达 → 用户确认 → 支付结算 → 互相评价。围绕这条链路剩下的全部是支撑模块。这里头最容易被想复杂的是“配送费怎么算”。很多同学一开始就想着接入地图API计算距离来定价但实际上校园内配送范围窄用固定基础价楼层加价的方式更靠谱。我见过一个项目因为做实时距离计价结果订单金额频繁波动用户投诉一堆。建议初期把定价公式做成可配置项起步价3元每栋宿舍楼不同加价超过2公里走附加规则。这样既满足需求又不需要每单都调一次地图API。另外还有一个隐蔽需求——帮带物品的类别限制。跑腿不是快递有些东西不能代买比如烟酒、管制物品。系统里下单页的“物品类型”字段看起来只是下拉选项实际上后端要做校验否则出了纠纷非常麻烦。这里属于典型的安全合规问题哪怕是个课程设计我也建议把限制字段做进数据库字典。1.2 角色、状态与交易闭环的底层设计整个系统一共三类角色普通用户下单方、跑腿员接单方、管理员平台方。但在数据库层面我建议你不要把用户表拆三张而是用一张user表加role字段再分别维护user_profile表扩展不同类型的信息。订单状态是另一个重点。我强烈建议你在设计阶段就画出状态机而不是等写代码的时候临场想。跑腿订单的完整状态流转是这样的待接单 → 已接单 → 配送中 → 已送达 → 已完成确认付款 ↘ 已取消 已接单 → 申请取消 → 平台介入/自动取消 配送中 → 申诉争议 → 平台介入每个状态是否允许被“谁”触发也要提前明确。比如普通用户只能在“待接单”状态取消订单跑腿员接单后就不能随意取消否则会影响接单率指标。把这些校验写进Service层而不是塞在Controller里这样业务逻辑才能做好复用。资金结算这块如果要做线上支付就要考虑一个关键点钱是先到平台还是直接给跑腿员。我的建议是平台做担保。用户下单时支付全额订单完成后平台再把跑腿费结算给接单人平台留一部分信息费。这个模式在法律合规上清晰后续如果要抽成也有依据。如果只是课程设计模拟支付流程即可但状态字段建议预留实际支付场景的扩展空间。2. 选型复盘为什么是SpringBootVue而不是别的2.1 后端框架选择的现实权衡很多人问我校园跑腿用SpringBoot是不是太重了我的看法很直接Java后端在校园和中小企业项目里仍然是最稳妥的选择不是因为性能有多极致而是因为人才梯队完整、资料多、出问题容易排查。SpringBoot整合MyBatis-Plus这套组合我用了很多年核心优势是CRUD处理效率高。跑腿系统里大量的列表查询、订单管理、用户管理页面全是常规增删改查用MyBatis-Plus的LambdaQueryWrapper可以少写很多重复的Mapper XML。比如订单列表按状态、时间、用户ID多条件筛选MyBatis-Plus都能直接用条件构造器搞定不需要像原生MyBatis那样写一长串动态SQL。版本选择上如果你的JDK环境是1.8SpringBoot不要追新稳定用2.7.18最省心。SpringBoot 2.7系列兼容性和生态最成熟不论是整合Redis、RabbitMQ还是WebSocket网上都能找到对应的方案。3.0之后强制JDK17很多学校的老电脑和教学环境都带不动没必要给自己找麻烦。依赖管理的思路是这样认证授权Spring Security JWT或者更轻量的Sa-Token二选一持久层MyBatis-Plus MySQL 8.0缓存Redis用于验证码、热数据、订单防重复提交实时通知WebSocket用于订单状态推送接口文档Knife4j增强版Swagger方便前后端联调2.2 前端Vue生态的工程化价值前端方面Vue 3 Vite Pinia Element Plus是我现在的标准组合。选Vue而不选React核心原因是上手门槛低。校园项目里总是有同学前端基础一般Vue的模板语法和响应式数据设计更直观改一个订单状态、渲染一个列表比React Hooks那套心智负担小得多。而且Element Plus的表格、表单、弹窗组件开箱即用做后台管理页面速度飞快。Vue 3的Composition API用来做跑腿系统非常合适。比如订单详情页涉及基础信息、配送轨迹、费用明细、用户信息四个模块如果用Options API会写一堆data、methods、computed混在一起。组合式API把每个业务模块封装成独立的composable函数订单相关的逻辑全放在useOrder.ts里组件只是拼装代码清爽很多。我最近做项目还会把Vue Router和登录态绑定前置路由守卫里校验用户是否登录。这个机制对跑腿系统尤其重要用户未登录只能浏览首页和公告点击下单、接单按钮时必须检查token否则直接重定向到登录页。这块属于前端权限控制的基本盘后面我会展开讲。3. 后端落地的三条主线用户、订单、支付3.1 数据表设计与订单字段的关键选择后端开发的第一个硬骨头是表设计。我把核心表列出来你对照自己的项目检查一下表名主要字段说明userid, openid/手机号, nickname, avatar, role, balance, status用户基本信息role区分用户类型user_profileid, user_id, school, dormitory, building, floor, credit_score扩展信息校区宿舍用于配送orderid, order_no, user_id, runner_id, item_type, item_desc, pickup_address, delivery_address, tip_fee, total_amount, status, pay_status, create_time, accept_time, finish_time订单主表核心业务表order_status_logid, order_id, from_status, to_status, operator_id, remark状态流转日志审计必备walletid, user_id, balance, frozen_amount钱包用于担保交易transactionid, trade_no, order_id, payer_id, payee_id, amount, type, status资金流水表reviewid, order_id, reviewer_id, rated_user_id, rating, content评价表订单表里面有个字段我重点讲一下order_no。一定不要用数据库自增ID做对外展示的单号订单号要自己生成包含时间戳和随机数。自增ID一旦被人遍历业务数据全暴露了很容易被爬虫或者恶意请求拖库。状态的枚举值我建议用数字。订单表的status字段存0、1、2、3…… 具体含义放在代码枚举类里前端也不要直接写死数字含义而是通过Knife4j生成的文档对照。这样数据库层面索引查询效率更高后续状态扩展也更方便。3.2 状态机的实现与流转校验前面我画了订单状态流转代码里怎么落地这里用到模式是状态校验集中在OrderService里每种状态变更写对应的处理方法不允许跨状态跳跃。我举个例子。用户点击“确认送达”按钮前端调用的接口是POST /api/order/confirm后端处理逻辑是这样的Transactional public void confirmOrder(Long orderId, Long userId) { Order order orderMapper.selectById(orderId); // 1. 校验订单归属 if (!order.getUserId().equals(userId)) { throw new BusinessException(无权操作该订单); } // 2. 校验状态是否合法 if (order.getStatus() ! OrderStatusEnum.DELIVERED.getCode()) { throw new BusinessException(当前订单状态无法确认完成); } // 3. 状态更新 order.setStatus(OrderStatusEnum.COMPLETED.getCode()); order.setFinishTime(LocalDateTime.now()); order.setPayStatus(PayStatusEnum.PAID.getCode()); orderMapper.updateById(order); // 4. 资金结算跑腿员钱包入账平台收取平台费 walletService.settleOrder(order); // 5. 记录状态日志 orderStatusLogService.record(order, OrderStatusEnum.OUT_FOR_DELIVERY, OrderStatusEnum.COMPLETED); }这种写法的好处是每个状态变更都有唯一的入口后续要加“订单申诉”或者“平台强制退款”的逻辑只需要在OrderService里新增对应的处理方法不会影响现有调用链。状态流转日志我特别提一下因为这步很多人会漏。order_status_log表记录每一次状态变更包括操作人、变更前后状态、备注。一旦出现用户投诉说“我没收到货但订单完成了”直接查这个表就知道是谁在什么时间改的状态责任清清楚楚。3.3 抢单并发与超时自动取消校园跑腿业务有个高并发场景用户发布一个高额订单多个跑腿员同时点击“抢单”。如果不做控制最后可能好几个跑腿员都看到自己“抢到了”实际订单却只有一个归属人。这里我用了Redis 分布式锁的方案。抢单接口的处理流程是这样public void grabOrder(Long orderId, Long runnerId) { // 用Redis的setnx命令实现分布式锁防止并发抢同一单 String lockKey order:grab: orderId; boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, runnerId, 5, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(手慢了订单已被抢走); } try { // 二次校验订单状态 Order order orderMapper.selectById(orderId); if (order.getStatus() ! OrderStatusEnum.PENDING.getCode()) { throw new BusinessException(订单已被接取); } order.setRunnerId(runnerId); order.setStatus(OrderStatusEnum.ACCEPTED.getCode()); order.setAcceptTime(LocalDateTime.now()); orderMapper.updateById(order); } finally { redisTemplate.delete(lockKey); } }这段代码的关键是Redis锁配合订单状态二次校验双保险。第一道锁挡住并发第二道状态校验防止锁过期导致的超卖。订单超时自动取消我推荐用延迟任务的思路。下单时往Redis存入一个带过期时间的key比如6小时到期后监听key过期事件回调里判断订单是否仍处于待接单状态是则自动取消并退还费用。这个方案比定时任务扫描全表效率高很多也比引入消息队列简单太多。4. 前端Vue实现要点结构、权限、实时消息4.1 页面结构设计与路由划分订单业务的前端页面虽然不算复杂但结构不梳理好后续非常容易乱。我的Vue项目目录组织是这样的src/ ├── api/ # 接口请求封装 │ ├── order.ts │ ├── user.ts │ └── wallet.ts ├── router/ │ └── index.ts # 路由配置 ├── stores/ │ ├── user.ts # 用户状态 │ └── order.ts # 订单状态 ├── views/ │ ├── home/ # 首页与接单大厅 │ ├── order/ # 下单、订单详情、订单列表 │ ├── wallet/ # 钱包与账单 │ ├── profile/ # 个人中心 │ └── admin/ # 后台管理 ├── components/ │ ├── OrderCard.vue # 订单卡片组件 │ ├── UserAvatar.vue │ └── ... └── utils/ ├── request.ts # Axios封装 └── auth.ts # Token工具路由设计上有一个坑要提醒你跑腿员接单大厅和用户下单大厅虽然都是订单列表但接口和展示逻辑完全不同路由必须分开。接单大厅的订单卡片要突出“跑腿费”和“取件距离”用户侧的订单列表要突出“订单状态”和“预计送达”。把这两个页面放到同一个组件里用v-if去切换代码会越来越臃肿。我建议的路由结构/user/orders 用户下单记录 /runner/tasks 跑腿员接单任务 /order/create 发布跑腿订单 /order/detail/:id 订单详情用户/跑腿员共用 /admin/orders 后台订单管理 /admin/users 后台用户管理订单详情页做成公共路由页面内根据当前用户的角色渲染不同的操作按钮这是比较务实的选择。4.2 登录态管理与角色权限控制前端权限控制做法核心是“路由守卫 接口拦截 按钮级判断”三层。路由守卫最基础在router/index.ts里配置全局前置守卫router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }) return } // 角色权限校验 if (to.meta.roles) { const userRole localStorage.getItem(userRole) if (!to.meta.roles.includes(userRole)) { next({ path: /403 }) return } } next() })登录之后把token和用户角色信息存到localStorage和Pinia里。Pinia是现在Vue 3官方推荐的状态管理库比Vuex更轻量TypeScript类型推导也更好。我用Pinia管理用户状态登出时直接调用userStore.logout()内部清空token和用户信息再跳转登录页。接口拦截层用Axios请求拦截器。每次请求前从localStorage取token放到Authorization请求头里。响应拦截器里如果后端返回401状态码说明token过期强制跳转登录页。按钮级判断主要用于页面内比如订单详情页里只有跑腿员抢到订单后“开始配送”按钮才可见用户侧只有在订单处于“已送达”状态时才显示“确认完成”按钮。这些虽然是前端控制但后端接口一定也要做同样的状态校验——前端防的是用户体验问题后端防的是安全问题。4.3 订单实时通知与地图接入跑腿业务最核心的体验点是实时性。用户下单后跑腿员能立刻看到跑腿员接单后用户能立即收到通知。这个功能我用WebSocket实现。SpringBoot集成WebSocket的流程不复杂核心是一个配置类和处理器Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(orderWebSocketHandler(), /ws/order) .setAllowedOrigins(*); } Bean public WebSocketHandler orderWebSocketHandler() { return new OrderWebSocketHandler(); } }前端在订单详情页和接单大厅建立连接监听order_status_change事件。推送给每个用户的消息频道不能共用我会在每个用户的session里保存userId和session的映射关系这样后端推送时可以精确到人。前端用Vue的onUnmounted生命周期钩子在离开页面时主动关闭WebSocket连接避免页面堆积垃圾连接。这个细节很多初学者会忽略导致页面越切越卡。地图接入方面校园跑腿和外卖本质类似但不需要实时跟踪轨迹只需要在用户下单时选择取件地址和送达地址跑腿员能看到一个静态位置即可。这里用腾讯地图或者高德地图的JavaScript API都行定位到校园内的楼栋后直接用楼栋编码替代经纬度坐标反而更精准。要不要接入定位取决于你的项目是否需要按距离排序显示订单不需要的话可以完全不用地图少一个外部依赖就少一个不稳定变量。5. 联调过程中的真实踩坑记录5.1 跨域问题与Axios请求拦截前后端分离项目必踩的坑就是跨域。前端的Vite开发服务器跑在localhost:5173后端SpringBoot跑在localhost:8080两个端口不同浏览器默认拦截跨域请求。解决方案有几个最省事的是后端加CORS配置。SpringBoot里写一个CorsFilter配置类放行所有来源Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意一个细节如果使用allowCredentials(true)前端的Axios也要设置withCredentials为true否则携带cookie的请求会被拒绝。我一度被这个坑卡了两个小时F12看请求头全都对了就是报CORS错误最后发现是Axios默认不带credentials。另外跨域配置在生产环境一定要收紧不能一直放行所有来源。部署上线后用Nginx反向代理把/api路径转发到后端服务这样前端访问同源地址从根上规避跨域Nginx层的配置也加上双保险更稳。5.2 LocalDateTime序列化与时区陷阱订单系统里时间字段非常多创建时间、接单时间、送达时间、完成时间。Java 8的LocalDateTime在后端使用非常方便但跟前端联调时踩了好几次坑。默认情况下SpringBoot返回的LocalDateTime序列化成JSON后是一串数组比如[2025, 1, 15, 14, 30, 0]前端根本没法直接用。解决方式是在application.yml里配置统一格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样返回给前端的字段就是“2025-01-15 14:30:00”这样的格式直接用就行也不用前后端再约定什么。时区问题也隐蔽。服务器如果部署在Docker容器里默认时区可能是UTC用户下单时间比北京时间慢8小时订单列表时间全错位。解决方式是在启动容器时指定时区docker run -e TZAsia/Shanghai ...或者在后端启动类里显式设置TimeZone.setDefault(TimeZone.getTimeZone(Asia/Shanghai));5.3 支付回调的幂等处理如果你的项目接入微信支付或者支付宝沙箱环境有一个非常容易出问题的地方支付回调通知可能被支付平台多次发送接口必须具备幂等性。如果回调逻辑没有做幂等控制用户付一次款钱包却入账两次金额对不上。我处理支付回调的逻辑是这样Transactional public void handlePayCallback(String tradeNo, String orderNo, BigDecimal amount) { // 1. 查流水如果已处理过直接返回成功 Transaction transaction transactionMapper.selectByTradeNo(tradeNo); if (transaction ! null transaction.getStatus() 1) { return; } // 2. 根据订单号查出订单校验金额是否一致 Order order orderMapper.selectByOrderNo(orderNo); if (order.getTotalAmount().compareTo(amount) ! 0) { throw new BusinessException(支付金额不一致); } // 3. 更新订单支付状态 order.setPayStatus(1); orderMapper.updateById(order); // 4. 写入支付流水 Transaction tx new Transaction(); tx.setTradeNo(tradeNo); tx.setOrderNo(orderNo); tx.setStatus(1); transactionMapper.insert(tx); }金额比较一定用BigDecimal的compareTo不能用equals因为0.01和0.010在BigDecimal里equals返回false但实际金额相等。数据库流水用trade_no建唯一索引从数据库层面再兜底防一次重复入账。5.4 文件上传过滤器的XSS风险跑腿订单里可能涉及物品凭证截图上传比如代取快递的单号照片。如果上传接口没有防XSS的全局过滤器恶意用户可以构造带JS脚本的SVG或者PDF文件名存储后在其他用户端执行脚本形成存储型XSS攻击。我给项目加了一个全局过滤器拦截上传请求对文件名和内容做清洗。过滤器的实现思路是继承OncePerRequestFilter对请求参数做一层包装将特殊字符转义后再传给Controller。特别注意PDF文件本身是二进制格式不能按文本去转义需要放行二进制请求体只处理FormData里的文本字段。这个细节很多人容易踩最后要么全过滤导致PDF打不开要么完全不过滤导致安全问题。6. 打包部署与后续可以继续深化的方向6.1 Docker Compose一键编排开发完成后部署我建议直接用Docker Compose把后端、前端Nginx、MySQL、Redis四个服务编排起来。项目根目录写一个docker-compose.ymlversion: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: campus_runner ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql redis: image: redis:7 ports: - 6379:6379 backend: build: ./backend depends_on: - mysql - redis ports: - 8080:8080 environment: TZ: Asia/Shanghai frontend: build: ./frontend depends_on: - backend ports: - 80:80前端镜像用Nginx承载打包好的dist目录Nginx配置里把/api开头的请求反向代理到backend:8080websocket的/ws路径也要加一个代理配置否则前端WebSocket连不上location /ws/ { proxy_pass http://backend:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; }这几个服务在云服务器上跑起来之后整个系统就能通过80端口对外访问了。CORS问题在这种部署方式下彻底消失因为前端的域名和API路径是同源的。6.2 接单大厅的性能优化思路订单列表页如果用户量大了会卡尤其接单大厅要实时刷新频繁查数据库会拖垮MySQL。我的经验是接单大厅的“待接单订单”列表直接走Redis缓存订单发布时写入Redis的ZSET按创建时间排序跑腿员查询列表时优先从Redis取取不到再去数据库查。Redis里的数据结构可以定义成key: runner:order:pending score: 订单创建时间戳 value: 订单ID跑腿员查询时用ZRANGEBYSCORE取时间范围内的订单ID再用pipeline批量去数据库查订单详情或者干脆把订单核心信息序列化成JSON存Redis。这样数据库的压力小很多订单实时性也更好。订单状态变更时Redis里的缓存对应删除或者更新。这里有个一致性细节缓存更新用延迟双删策略先删缓存再更新数据库休眠几百毫秒再删一次避免脏数据。6.3 我的后续扩展清单如果这个项目要继续做下去我脑子里已经列好了几个优先级比较高的方向智能派单基于跑腿员当前位置、接单率、历史信用分做订单分配推荐而不是全靠手动抢单消息会话跑腿员和用户之间增加即时聊天功能沟通取货细节WebSocket的基础已经有了扩展聊天逻辑并不难信用评价体系用户和跑腿员互相评分低于阈值的用户限制下单低于阈值的跑腿员限制接单多校区部署把数据表里增加school_id字段一套代码支持多个校区独立运营每个校区有独立的订单池和跑腿员池我在实际做这类项目的时候最深的体会是跑腿业务的技术难点不在单个功能有多难而在把一条完整链路上所有异常情况都想清楚。订单超时怎么办、跑腿员接单后不干了怎么办、用户不确认收货怎么办、支付平台重复回调怎么办这些才是真正考验系统设计的细节。如果你正在做或者准备做校园跑腿相关的项目建议先花一天时间梳理业务流程和状态机再开始写代码。顺序做对了后面的开发速度快一倍都不止。