校园跑腿代取系统这类题目我在不少课程设计和毕业设计的选题列表里都见过。表面看它就是“用户发单、跑腿员接单、完事给钱”的小平台可一旦把订单生命周期、实时定位、抢单并发、多端状态同步全部串起来项目立刻就不是一个简单 CRUD 能撑住的东西了。下面我就用 Spring Boot Vue3 管理后台 Android 客户端这个组合复盘一套能落地实现的校园跑腿代取系统包括我实际开发时踩过的坑、反复改过的设计以及一些可以直接抄走的代码思路。适合正在做类似课题的学生也适合想从零搭一个校园服务小产品的开发者参考。1. 明确定位这个系统不是“发单接单”四个字这么简单1.1 角色与核心用例校园跑腿代取的业务核心是让没有时间或不想出宿舍的同学把“代取快递”“食堂带饭”“代买小零食”“代送文件”这类任务外包给有空闲时间的同学。系统里至少有三类角色下单用户、跑腿员、管理员。下单用户的核心诉求是“快速发单知道谁接单东西什么时候到”。所以前端必须支持选择任务类型、填写取件地址和送达地址、设置跑腿费、查看订单状态变化。跑腿员的核心诉求是“附近有没有单、单值不值钱、怎么联系取件人”。所以客户端需要定位、抢单、查看订单详情、打电话联系对方。管理员的核心诉求则是“每天多少订单、有没有纠纷、价格设置是否合理”这部分我建议放到独立的管理后台而不是做成移动端页面否则手机屏幕上密密麻麻的表格根本没法用。很多第一次做这个项目的人上来就列用户表、订单表、任务表把“下单”和“接单”做出来就以为结束了。实际上还差一个关键角色链条谁创建订单、订单如何流转到跑腿员手里、跑腿员取件后状态如何通知到用户以及订单异常时管理员怎么介入。这几个环节只要有一个没想清楚后面做到 Android 端状态刷新时就会非常痛苦。1.2 被很多人忽略的“非功能需求”除了功能列表这类系统还需要提前考虑几件事。第一是定位。校园范围看起来不大但快递点、食堂、教学楼之间的步行距离通常有三五百米。跑腿费要按距离算不能是固定值。系统要拿到下单人的位置、取件点的位置和送达点的位置用坐标算距离再套一个计费规则。第二是订单超时。没人接的单不能一直挂着状态机里必须有“超时自动取消”或者“超时提醒”机制。实现方式可以用定时任务扫描也可以用延迟消息处理但至少先得有这个规则。第三是取消策略。用户下单后想取消跑腿员接单后能不能取消接单后用户单方面取消对跑腿员公不公平这些不是写代码能自己定义的需要提前定业务规则。我见过不少项目把取消按钮放在任何状态都可用结果状态流直接乱掉。第四是数据统计。管理员会想知道每天下单数量、完单率、平均跑腿费。假如数据库表结构一开始没有设计好冗余字段后面想统计还得回填数据很麻烦。把这些非功能需求先记下来再去设计模块后面的技术选型才有依据。2. 从三端选型说起框架组合为什么这么搭配2.1 后端选 Spring Boot 的原因Spring Boot 在这个项目里扮演的是唯一服务端既要给 Android 提供 HTTP API也要给 Vue3 管理后台提供管理接口。选它首先是因为生态成熟Starter 包几乎覆盖了校园项目会用到的所有基础能力鉴权、参数校验、数据库访问、定时任务、消息推送的辅助依赖。遇到问题时网上能查到的案例密度远超其他框架对项目周期短的同学来说这是实打实的优势。第二个原因是 Spring Boot 的工程结构对“单体应用”非常友好。校园跑腿系统初期用户量不会很大没必要一上来就拆微服务。把 Controller、Service、Mapper 分清楚按模块划包足够支撑几百上千人同时使用。如果直接上微服务反而会陷入服务发现、配置中心、分布式事务的泥潭。不是技术越复杂越厉害而是要在合适规模下解决问题。第三个原因是 Java 生态里做安全控制比较顺手。使用 Spring Security 或者轻量拦截器加 JWT都可以把登录态和角色权限管起来。移动端没有 Cookie 概念接口要采用 Token 方式认证Spring Boot 做这个事情非常自然。选型其实是最不需要纠结的地方。纠结的是项目里的包结构怎么划分、接口响应格式怎么统一、状态码怎么定义。我推荐把统一返回结构放在最基础的 commons 包里例如 Result 里面包含 code、message、data 三个字段所有接口不管成功失败都返回这个结构。这样 Android 端的 Retrofit 和 Vue3 管理后台的 Axios 都可以做同一套拦截逻辑。2.2 管理后台选 Vue3 的原因管理后台选择 Vue3很大程度上是因为它和 Spring Boot 的组合是目前资料最多、上手成本最低的方案之一。Vue3 的 Composition API 让页面状态管理比 Vue2 时代清晰很多一个订单列表页需要维护查询参数、分页信息、表格数据、加载状态如果用 Options API 写逻辑会散落在 data、methods、watch 里用 setup 写所有东西都在一个作用域里思路更接近“一个页面就是一个状态机”。另外 Vue3 配合 Element Plus后台表格、表单、弹窗、分页一套组件就能出来不需要自己手写样式。管理后台的核心是“效率”不是“炫酷”组件库成熟能省下大量时间。也要说明一下Vue3 只是前端框架它本身不能替你做权限控制。路由守卫、按钮权限这些都要自己写。管理员账号和普通用户账号不能访问同一个菜单这个逻辑必须前后端同时做前端控制入口后端控制接口两层都压住才算安全。2.3 Android 侧选型与后端接口契约Android 端我建议使用 Kotlin 加 Retrofit配合 ViewModel 和 LiveData 或 Flow 做状态管理。Kotlin 的协程可以用同步代码风格写异步请求对项目维护非常友好。Retrofit 负责把后端接口声明成函数配合 Gson 或 Moshi 做 JSON 序列化几乎是当前最稳的组合。三端项目的关键问题之一是前后端接口契约必须尽早固定。移动端发布后不能像 Web 页面那样即时热更新如果后端接口字段名字写错了、类型变了版本迭代就是事故。我习惯在项目初始化阶段先写一份接口文档或 YAML把订单创建、订单详情、接单、状态变更这些核心接口的请求响应定下来。能减少很多后面联调时的无线沟通成本。下表是我在这个项目里常用的技术栈组合供参考端技术组合承担职责服务端Spring Boot、MySQL、Redis可选、JWT业务接口、订单状态管理、鉴权、数据存储管理端Vue3、Element Plus、Axios、Vite订单监控、用户管理、数据统计Android 端Kotlin、Retrofit、Coroutines、ViewModel发单、抢单、订单状态查看、位置上报3. 后端核心实现订单状态机、抢单与超时处理3.1 订单表设计先把字段粒度定好订单表是整个系统的核心表设计时要把字段粒度一次定好后面改动成本很高。我这里给出一份简化过的表结构CREATE TABLE order_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, user_id BIGINT NOT NULL COMMENT 下单用户, taker_id BIGINT DEFAULT NULL COMMENT 接单跑腿员, type TINYINT NOT NULL COMMENT 1-代取快递 2-代买 3-代送, pickup_address VARCHAR(255) NOT NULL COMMENT 取件地址, delivery_address VARCHAR(255) NOT NULL COMMENT 送达地址, pickup_lat DECIMAL(10,6) DEFAULT NULL, pickup_lng DECIMAL(10,6) DEFAULT NULL, delivery_lat DECIMAL(10,6) DEFAULT NULL, delivery_lng DECIMAL(10,6) DEFAULT NULL, reward_fee DECIMAL(8,2) DEFAULT 0 COMMENT 跑腿费, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态, remark VARCHAR(500) DEFAULT NULL, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, KEY idx_status_create (status, create_time), KEY idx_user (user_id), KEY idx_taker (taker_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT跑腿订单表;注意几个容易被忽略的细节。订单号不要用自增 id 直接展示给用户因为那样会暴露订单量。可以用时间戳加随机数生成。经纬度字段要保留坐标不能只存文字地址否则跑腿员无法根据距离排序。type 字段用 TINYINT 存数字含义在代码枚举里定义不直接存中文避免改字面量时数据库迁移。status 字段同理。除了订单表还需要用户表、跑腿员认证资料表、订单评价表、系统配置表。系统配置表用来存跑腿费计算规则例如基础价、每公里加价、不同类型的加权系数不要把这些值硬编码在代码里。3.2 状态机状态变更的合法路径订单状态是这类系统最需要维护的东西。我整理了一套简化状态待接单(PENDING) - 已接单(ACCEPTED) - 已取件(PICKED) - 已完成(COMPLETED) 待接单(PENDING) - 已取消(CANCELLED) 已接单(ACCEPTED) - 已取消(CANCELLED)在代码里用枚举表达会清晰很多public enum OrderStatus { PENDING(0, 待接单), ACCEPTED(1, 已接单), PICKED(2, 已取件), COMPLETED(3, 已完成), CANCELLED(4, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态机最重要的不是枚举定义而是状态迁移的校验。我自己的做法是写一个状态流转校验工具类里面放一张“合法迁移表”每次更新状态前对比当前状态和目标状态。比如已取件状态不能直接跳回已接单已完成状态不能再取消。这样能防止并发请求把状态改乱也方便以后扩展新状态。这里也直接决定了 API 设计接口层面不应该提供一个“万能的状态更新接口”而应该拆成“用户取消订单”“跑腿员接单”“跑腿员标记取件”“跑腿员标记送达”这种语义明确的接口。每个接口内部只完成一个特定迁移可读性和安全性都会好很多。3.3 并发抢单与超时自动取消的实现细节校园跑腿系统里最容易“翻车”的场景是多人同时抢同一个单。如果把接单实现成先查询订单状态再看是否可接最后更新订单状态并发情况下很容易出现“多个人都看到待接单然后都被更新成功”的问题。这不是线程安全问题而是典型的并发更新问题。我采用的方案是用一条带条件的 UPDATE 语句直接把状态改掉UPDATE order_info SET status 1, taker_id #{takerId}, accept_time NOW() WHERE id #{orderId} AND status 0这条语句会返回受影响行数。如果返回值是 1说明当前用户抢单成功如果是 0说明订单已经被别人抢走或者状态已经变化。配合事务和唯一约束可以保证同一个订单只能被一个跑腿员接单。Transactional public boolean grabOrder(Long orderId, Long takerId) { int updated orderMapper.grabOrder(orderId, takerId); return updated 1; }超时取消则是另一个容易被忽略的点。比较简单的方案是定时任务每分钟扫描一次待接单且超过 15 分钟的订单把状态置为已取消。这个方案在订单量不大时完全够用。如果量大可以用延迟队列但校园项目通常不需要做到这个程度。需要注意的是超时取消不能影响正在操作的用户。比如用户已经在点击取消同时定时任务也在取消要用 update 条件限制状态避免重复取消导致的数据不一致。4. Android 客户端的定位获取与订单状态同步4.1 定位模块精度、省电、权限缺一不可Android 端第一个绕不开的问题是定位。校园场景下用户下单要获取当前定位作为送达地址附近的坐标跑腿员抢单列表要按距离排序所以定位精度和获取频率必须提前想好。定位方式上Android 系统一般建议采用 Google Play 服务里的 FusedLocationProvider但国内环境很多设备没有相关服务所以实际项目里我更常使用系统 LocationManager 或者接入高德、百度这类第三方定位 SDK。如果用第三方 SDK需要申请 Key并且要处理隐私政策说明这部分工作要留出时间。权限申请要一次性把定位权限和通知权限说清楚。定位权限分前台和后台校园跑腿场景建议只申请前台定位权限因为应用退到后台后继续定位既耗电又容易触碰隐私合规问题。通知权限用于订单状态变化提醒在 Android 8.0 以后必须显式创建通知渠道否则通知弹不出来。我第一次做的时候忘记创建 NotificationChannel测试机上怎么调都收不到推送消息后来查资料才想起来是这个原因。定位更新不用一直高频刷新。下单时取一次当前位置即可跑腿员在地图页看附近订单时可以 30 秒拉一次。全时高频率定位会让手机发烫续航明显下降用户会对应用印象很差。4.2 状态同步方案轮询、长连接与消息推送怎么选订单状态同步是移动端体验的核心。用户下单后想知道有没有被接单跑腿员接单后想看到用户坐标更新。一般来说有三种方案。第一种是轮询。Android 端定期调用订单详情接口比如每 5 秒或 10 秒请求一次然后更新界面。实现简单后端只需要提供普通查询接口。缺点是会有延迟而且订单量大了以后后端查询压力偏高但校园项目用户量不大完全可接受。第二种是长连接。用 WebSocket 保持服务端和客户端之间的双向通信服务端订单状态变化时主动推送。这个方案实时性好但客户端要自己处理断线重连、心跳保活后端还要维护连接会话和消息丢失补偿复杂度高不少。第三种是接入第三方推送。集成厂商推送服务服务端在状态变化时发送通知点击通知再进入应用拉取详情。实时性和成本均衡但会多一个 SDK 依赖。我的建议是项目初期用轮询把状态刷新做得稳一点把体验优化放在请求频率和界面刷新上。如果后面确实需要实时性再引入长连接。先把核心业务流程跑通比一开始就追求实时推送更实际。4.3 一个最小可跑的 Kotlin 请求链路Android 端和 Spring Boot 对接的核心是用 Retrofit 定义接口。假设后端有订单详情和抢单两个接口interface OrderApi { GET(order/{id}) suspend fun getOrder(Path(id) id: Long): ResultOrderDTO POST(order/{id}/grab) suspend fun grabOrder(Path(id) id: Long): ResultOrderDTO }这里 Result 是后端统一返回结构的映射。网络请求通过 Retrofit 调用ViewModel 里用一个 loadOrder 方法触发请求并更新 Stateclass OrderDetailViewModel(private val api: OrderApi) : ViewModel() { private val _orderState MutableStateFlowOrderUiState(OrderUiState.Loading) val orderState: StateFlowOrderUiState _orderState fun refresh(orderId: Long) { viewModelScope.launch { try { val response api.getOrder(orderId) _orderState.value OrderUiState.Success(response.data) } catch (e: HttpException) { _orderState.value OrderUiState.Error(e.code()) } catch (e: IOException) { _orderState.value OrderUiState.Error(-1) } } } }轮询可以用一个简单的 while 循环加 delay 来做在界面销毁时通过 viewModelScope 的取消机制停止。注意轮询请求要加异常捕获否则网络抖动一次就退出循环了。5. Vue3 管理后台从订单列表到权限路由的落地要点5.1 管理端页面结构与状态设计管理后台我划分为四个页面订单列表、用户管理、跑腿员审核、数据统计。订单列表是核心页面运营同学一天大部分时间都在盯着它看所以要把搜索状态和分页状态设计得足够顺手。Vue3 里我倾向于用 Composition API 把列表页的状态集中起来。一个典型的查询状态可能包含这些关键词、订单状态、时间范围、当前页码、每页大小。这些字段绑到搜索表单和分页组件上任何一个条件变化都触发重新加载。页面结构不要做太复杂。左侧是菜单顶部是管理员信息和退出登录中间内容区放表格和筛选条件。后台的布局最好保持稳定不要让用户到处找操作按钮。5.2 列表页的搜索、分页与防抖实现搜索功能不能只做前端过滤因为订单量大了以后前端拿全量数据不现实。正确做法是后端接口支持条件查询前端把筛选参数通过请求传给服务器服务器返回分页结果。前端只需要维护好参数对象。一个简化版的 Vue3 列表实现大概是这样的const query reactive({ keyword: , status: undefined as number | undefined, page: 1, size: 10 }) const tableData refOrderInfo[]([]) const total ref(0) const loading ref(false) async function loadOrders() { loading.value true try { const res await getOrders(query) tableData.value res.data.records total.value res.data.total } finally { loading.value false } } function handleSearch() { query.page 1 loadOrders() }关键词搜索最好加防抖避免用户每敲一个字符就触发一次接口请求。比较简单的方式是用 watch 加定时器输入停止 500 毫秒以后再触发搜索。如果你用 Element Plus也可以直接给搜索框加 clearable 属性方便用户一键清空条件。5.3 权限路由与按钮级控制的简化方案管理后台权限分成两个级别菜单路由级和操作按钮级。路由级权限用 Vue Router 的 beforeEach 守卫实现登录后根据角色过滤可访问的路由表。按钮级权限通常会封装一个自定义指令比如 v-permission元素不满足权限条件时直接移除。严格来说前端权限只是用户体验层面。后端接口必须做同样的角色校验否则用户绕过前端直接调接口一样能访问数据。这两个都要做但后端才是底线。登录后 Token 里带上用户角色后端拦截器在每次请求时解析出来再判断接口权限。权限设计不需要一开始就做得很重。用一个 role 字段区分普通用户和管理员骑手权限合并到普通用户里先保证“管理员才能看到后台、用户不能调用管理接口”就够。等系统跑起来了再细化角色权限也不迟。6. 上线前后绕不开的部署与安全问题6.1 用 Nginx 把前后端接到同一个域名的部署方式部署时最常见的问题是 Android 端和管理后台分别访问不同端口导致跨域和配置混乱。我的建议是用 Nginx 做反向代理把三个端统一到同一个域名下API 路径转发到 Spring Boot前端静态文件直接由 Nginx 托管。一个简化版的 Nginx 配置server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; } location /admin/ { alias /var/www/admin/dist/; try_files $uri $uri/ /admin/index.html; } }这样 Android 端只需要配置一个 baseUrl实际请求地址就是 https://your-domain.com/api/...不存在跨域问题。管理后台访问 https://your-domain.com/admin/ 加载静态资源API 也走同一个域名。部署简单后期维护也方便。打包流程中要注意前端项目的 API 环境变量。开发环境指向本地后端生产环境指向线上域名。很多同学项目本地能跑部署到服务器上白屏绝大多数情况就是 API 地址没有切换。Android 端同样不要把本地调试地址写死在代码里应该通过 BuildConfig 区分 Debug 和 Release 环境。6.2 安全自查清单这种校园系统最容易暴雷的其实是安全问题因为学生信息和位置数据都有隐私属性。我的自查清单固定包含以下几条后端参数校验必须做。所有接收前端参数的接口都要做非空、长度、类型校验防止恶意绕过前端直接构造请求。Spring Boot 里可以用 validation 注解简化例如 NotBlank、Size一行的注解比在 Service 里写一堆 if 更可靠。密码存储一律用 BCrypt不能存明文也不能自己发明加密算法。手机号在数据库可以正常保存但接口返回给前端时要做脱敏处理比如只显示前三位和后四位。用户定位坐标不能随便展示给所有客户端普通用户查订单详情时只能看到跑腿员的脱敏联系方式不能拿到完整手机号。管理接口需要严格的权限校验。如果后台没有任何鉴权保护等于把所有订单数据和用户手机号裸奔在公网上。我见过有人做课程设计后台接口没有任何拦截器任何人知道 URL 就能看全部数据。这样即便功能演示满分评审一看安全问题就打了低分。定时任务和大批量导出操作要注意执行频率和日志记录。管理员操作后台时保留操作日志能追溯谁在什么时候改了订单状态。这个日志表非常简单但关键时刻能救命。6.3 常见坑与我的处理经验最后分享几个我实际开发中遇到的坑未必在教科书里能看到。时区问题。后端 MySQL 连接串里如果不明确指定 serverTimezone并且系统里的时间字段直接存当前时间不同时区的服务器和本地环境显示会出现偏差。建议统一使用 Asia/Shanghai 时区并且在代码里所有时间字段都用 LocalDateTime。坐标距离计算不能直接用“经纬度相减再乘一个系数”那样误差会很大尤其在南北方言距离感比较明显的地方。要用 Haversine 公式把球面距离算出来。代码不复杂但结果是可信的public static double distance(double lat1, double lng1, double lat2, double lng2) { double rad Math.PI / 180.0; double dLat (lat2 - lat1) * rad; double dLng (lng2 - lng1) * rad; double a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(lat1 * rad) * Math.cos(lat2 * rad) * Math.sin(dLng / 2) * Math.sin(dLng / 2); return 6371000.0 * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); }通知渠道问题。Android 8.0 以上必须为通知创建渠道否则 NotificationManager 会静默丢弃通知。测试时如果发现通知不弹先检查有没有创建 NotificationChannel不要一上来就怀疑代码逻辑。接口字段规范。前后端协同开发时后端返回的字段名如果是驼峰Android 端通过 Gson 默认能直接映射同名属性但如果后端返回 json 里多了下划线命名就必须再写映射注解。最稳妥的方式是一切以接口文档为准团队内部在项目启动时就约定统一命名风格。我在实际开发中的最后一个建议是不要急着写代码先把订单状态机画对再把角色权限边界理清这两点决定了整个项目的骨架。骨架对了Spring Boot Vue3 Android 三端项目的后半段推进会顺利得多。后续如果要扩展支付、接入更完整的推送体系或者把抢单改成派单模式底层设计也都是可以平滑接上的。做校园跑腿代取系统真正的价值不是把单一接口跑通而是把一条完整的业务闭环想透、做稳。
校园跑腿代取系统这类题目我在不少课程设计和毕业设计的选题列表里都见过。表面看它就是“用户发单、跑腿员接单、完事给钱”的小平台可一旦把订单生命周期、实时定位、抢单并发、多端状态同步全部串起来项目立刻就不是一个简单 CRUD 能撑住的东西了。下面我就用 Spring Boot Vue3 管理后台 Android 客户端这个组合复盘一套能落地实现的校园跑腿代取系统包括我实际开发时踩过的坑、反复改过的设计以及一些可以直接抄走的代码思路。适合正在做类似课题的学生也适合想从零搭一个校园服务小产品的开发者参考。1. 明确定位这个系统不是“发单接单”四个字这么简单1.1 角色与核心用例校园跑腿代取的业务核心是让没有时间或不想出宿舍的同学把“代取快递”“食堂带饭”“代买小零食”“代送文件”这类任务外包给有空闲时间的同学。系统里至少有三类角色下单用户、跑腿员、管理员。下单用户的核心诉求是“快速发单知道谁接单东西什么时候到”。所以前端必须支持选择任务类型、填写取件地址和送达地址、设置跑腿费、查看订单状态变化。跑腿员的核心诉求是“附近有没有单、单值不值钱、怎么联系取件人”。所以客户端需要定位、抢单、查看订单详情、打电话联系对方。管理员的核心诉求则是“每天多少订单、有没有纠纷、价格设置是否合理”这部分我建议放到独立的管理后台而不是做成移动端页面否则手机屏幕上密密麻麻的表格根本没法用。很多第一次做这个项目的人上来就列用户表、订单表、任务表把“下单”和“接单”做出来就以为结束了。实际上还差一个关键角色链条谁创建订单、订单如何流转到跑腿员手里、跑腿员取件后状态如何通知到用户以及订单异常时管理员怎么介入。这几个环节只要有一个没想清楚后面做到 Android 端状态刷新时就会非常痛苦。1.2 被很多人忽略的“非功能需求”除了功能列表这类系统还需要提前考虑几件事。第一是定位。校园范围看起来不大但快递点、食堂、教学楼之间的步行距离通常有三五百米。跑腿费要按距离算不能是固定值。系统要拿到下单人的位置、取件点的位置和送达点的位置用坐标算距离再套一个计费规则。第二是订单超时。没人接的单不能一直挂着状态机里必须有“超时自动取消”或者“超时提醒”机制。实现方式可以用定时任务扫描也可以用延迟消息处理但至少先得有这个规则。第三是取消策略。用户下单后想取消跑腿员接单后能不能取消接单后用户单方面取消对跑腿员公不公平这些不是写代码能自己定义的需要提前定业务规则。我见过不少项目把取消按钮放在任何状态都可用结果状态流直接乱掉。第四是数据统计。管理员会想知道每天下单数量、完单率、平均跑腿费。假如数据库表结构一开始没有设计好冗余字段后面想统计还得回填数据很麻烦。把这些非功能需求先记下来再去设计模块后面的技术选型才有依据。2. 从三端选型说起框架组合为什么这么搭配2.1 后端选 Spring Boot 的原因Spring Boot 在这个项目里扮演的是唯一服务端既要给 Android 提供 HTTP API也要给 Vue3 管理后台提供管理接口。选它首先是因为生态成熟Starter 包几乎覆盖了校园项目会用到的所有基础能力鉴权、参数校验、数据库访问、定时任务、消息推送的辅助依赖。遇到问题时网上能查到的案例密度远超其他框架对项目周期短的同学来说这是实打实的优势。第二个原因是 Spring Boot 的工程结构对“单体应用”非常友好。校园跑腿系统初期用户量不会很大没必要一上来就拆微服务。把 Controller、Service、Mapper 分清楚按模块划包足够支撑几百上千人同时使用。如果直接上微服务反而会陷入服务发现、配置中心、分布式事务的泥潭。不是技术越复杂越厉害而是要在合适规模下解决问题。第三个原因是 Java 生态里做安全控制比较顺手。使用 Spring Security 或者轻量拦截器加 JWT都可以把登录态和角色权限管起来。移动端没有 Cookie 概念接口要采用 Token 方式认证Spring Boot 做这个事情非常自然。选型其实是最不需要纠结的地方。纠结的是项目里的包结构怎么划分、接口响应格式怎么统一、状态码怎么定义。我推荐把统一返回结构放在最基础的 commons 包里例如 Result 里面包含 code、message、data 三个字段所有接口不管成功失败都返回这个结构。这样 Android 端的 Retrofit 和 Vue3 管理后台的 Axios 都可以做同一套拦截逻辑。2.2 管理后台选 Vue3 的原因管理后台选择 Vue3很大程度上是因为它和 Spring Boot 的组合是目前资料最多、上手成本最低的方案之一。Vue3 的 Composition API 让页面状态管理比 Vue2 时代清晰很多一个订单列表页需要维护查询参数、分页信息、表格数据、加载状态如果用 Options API 写逻辑会散落在 data、methods、watch 里用 setup 写所有东西都在一个作用域里思路更接近“一个页面就是一个状态机”。另外 Vue3 配合 Element Plus后台表格、表单、弹窗、分页一套组件就能出来不需要自己手写样式。管理后台的核心是“效率”不是“炫酷”组件库成熟能省下大量时间。也要说明一下Vue3 只是前端框架它本身不能替你做权限控制。路由守卫、按钮权限这些都要自己写。管理员账号和普通用户账号不能访问同一个菜单这个逻辑必须前后端同时做前端控制入口后端控制接口两层都压住才算安全。2.3 Android 侧选型与后端接口契约Android 端我建议使用 Kotlin 加 Retrofit配合 ViewModel 和 LiveData 或 Flow 做状态管理。Kotlin 的协程可以用同步代码风格写异步请求对项目维护非常友好。Retrofit 负责把后端接口声明成函数配合 Gson 或 Moshi 做 JSON 序列化几乎是当前最稳的组合。三端项目的关键问题之一是前后端接口契约必须尽早固定。移动端发布后不能像 Web 页面那样即时热更新如果后端接口字段名字写错了、类型变了版本迭代就是事故。我习惯在项目初始化阶段先写一份接口文档或 YAML把订单创建、订单详情、接单、状态变更这些核心接口的请求响应定下来。能减少很多后面联调时的无线沟通成本。下表是我在这个项目里常用的技术栈组合供参考端技术组合承担职责服务端Spring Boot、MySQL、Redis可选、JWT业务接口、订单状态管理、鉴权、数据存储管理端Vue3、Element Plus、Axios、Vite订单监控、用户管理、数据统计Android 端Kotlin、Retrofit、Coroutines、ViewModel发单、抢单、订单状态查看、位置上报3. 后端核心实现订单状态机、抢单与超时处理3.1 订单表设计先把字段粒度定好订单表是整个系统的核心表设计时要把字段粒度一次定好后面改动成本很高。我这里给出一份简化过的表结构CREATE TABLE order_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, user_id BIGINT NOT NULL COMMENT 下单用户, taker_id BIGINT DEFAULT NULL COMMENT 接单跑腿员, type TINYINT NOT NULL COMMENT 1-代取快递 2-代买 3-代送, pickup_address VARCHAR(255) NOT NULL COMMENT 取件地址, delivery_address VARCHAR(255) NOT NULL COMMENT 送达地址, pickup_lat DECIMAL(10,6) DEFAULT NULL, pickup_lng DECIMAL(10,6) DEFAULT NULL, delivery_lat DECIMAL(10,6) DEFAULT NULL, delivery_lng DECIMAL(10,6) DEFAULT NULL, reward_fee DECIMAL(8,2) DEFAULT 0 COMMENT 跑腿费, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态, remark VARCHAR(500) DEFAULT NULL, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, KEY idx_status_create (status, create_time), KEY idx_user (user_id), KEY idx_taker (taker_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT跑腿订单表;注意几个容易被忽略的细节。订单号不要用自增 id 直接展示给用户因为那样会暴露订单量。可以用时间戳加随机数生成。经纬度字段要保留坐标不能只存文字地址否则跑腿员无法根据距离排序。type 字段用 TINYINT 存数字含义在代码枚举里定义不直接存中文避免改字面量时数据库迁移。status 字段同理。除了订单表还需要用户表、跑腿员认证资料表、订单评价表、系统配置表。系统配置表用来存跑腿费计算规则例如基础价、每公里加价、不同类型的加权系数不要把这些值硬编码在代码里。3.2 状态机状态变更的合法路径订单状态是这类系统最需要维护的东西。我整理了一套简化状态待接单(PENDING) - 已接单(ACCEPTED) - 已取件(PICKED) - 已完成(COMPLETED) 待接单(PENDING) - 已取消(CANCELLED) 已接单(ACCEPTED) - 已取消(CANCELLED)在代码里用枚举表达会清晰很多public enum OrderStatus { PENDING(0, 待接单), ACCEPTED(1, 已接单), PICKED(2, 已取件), COMPLETED(3, 已完成), CANCELLED(4, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }状态机最重要的不是枚举定义而是状态迁移的校验。我自己的做法是写一个状态流转校验工具类里面放一张“合法迁移表”每次更新状态前对比当前状态和目标状态。比如已取件状态不能直接跳回已接单已完成状态不能再取消。这样能防止并发请求把状态改乱也方便以后扩展新状态。这里也直接决定了 API 设计接口层面不应该提供一个“万能的状态更新接口”而应该拆成“用户取消订单”“跑腿员接单”“跑腿员标记取件”“跑腿员标记送达”这种语义明确的接口。每个接口内部只完成一个特定迁移可读性和安全性都会好很多。3.3 并发抢单与超时自动取消的实现细节校园跑腿系统里最容易“翻车”的场景是多人同时抢同一个单。如果把接单实现成先查询订单状态再看是否可接最后更新订单状态并发情况下很容易出现“多个人都看到待接单然后都被更新成功”的问题。这不是线程安全问题而是典型的并发更新问题。我采用的方案是用一条带条件的 UPDATE 语句直接把状态改掉UPDATE order_info SET status 1, taker_id #{takerId}, accept_time NOW() WHERE id #{orderId} AND status 0这条语句会返回受影响行数。如果返回值是 1说明当前用户抢单成功如果是 0说明订单已经被别人抢走或者状态已经变化。配合事务和唯一约束可以保证同一个订单只能被一个跑腿员接单。Transactional public boolean grabOrder(Long orderId, Long takerId) { int updated orderMapper.grabOrder(orderId, takerId); return updated 1; }超时取消则是另一个容易被忽略的点。比较简单的方案是定时任务每分钟扫描一次待接单且超过 15 分钟的订单把状态置为已取消。这个方案在订单量不大时完全够用。如果量大可以用延迟队列但校园项目通常不需要做到这个程度。需要注意的是超时取消不能影响正在操作的用户。比如用户已经在点击取消同时定时任务也在取消要用 update 条件限制状态避免重复取消导致的数据不一致。4. Android 客户端的定位获取与订单状态同步4.1 定位模块精度、省电、权限缺一不可Android 端第一个绕不开的问题是定位。校园场景下用户下单要获取当前定位作为送达地址附近的坐标跑腿员抢单列表要按距离排序所以定位精度和获取频率必须提前想好。定位方式上Android 系统一般建议采用 Google Play 服务里的 FusedLocationProvider但国内环境很多设备没有相关服务所以实际项目里我更常使用系统 LocationManager 或者接入高德、百度这类第三方定位 SDK。如果用第三方 SDK需要申请 Key并且要处理隐私政策说明这部分工作要留出时间。权限申请要一次性把定位权限和通知权限说清楚。定位权限分前台和后台校园跑腿场景建议只申请前台定位权限因为应用退到后台后继续定位既耗电又容易触碰隐私合规问题。通知权限用于订单状态变化提醒在 Android 8.0 以后必须显式创建通知渠道否则通知弹不出来。我第一次做的时候忘记创建 NotificationChannel测试机上怎么调都收不到推送消息后来查资料才想起来是这个原因。定位更新不用一直高频刷新。下单时取一次当前位置即可跑腿员在地图页看附近订单时可以 30 秒拉一次。全时高频率定位会让手机发烫续航明显下降用户会对应用印象很差。4.2 状态同步方案轮询、长连接与消息推送怎么选订单状态同步是移动端体验的核心。用户下单后想知道有没有被接单跑腿员接单后想看到用户坐标更新。一般来说有三种方案。第一种是轮询。Android 端定期调用订单详情接口比如每 5 秒或 10 秒请求一次然后更新界面。实现简单后端只需要提供普通查询接口。缺点是会有延迟而且订单量大了以后后端查询压力偏高但校园项目用户量不大完全可接受。第二种是长连接。用 WebSocket 保持服务端和客户端之间的双向通信服务端订单状态变化时主动推送。这个方案实时性好但客户端要自己处理断线重连、心跳保活后端还要维护连接会话和消息丢失补偿复杂度高不少。第三种是接入第三方推送。集成厂商推送服务服务端在状态变化时发送通知点击通知再进入应用拉取详情。实时性和成本均衡但会多一个 SDK 依赖。我的建议是项目初期用轮询把状态刷新做得稳一点把体验优化放在请求频率和界面刷新上。如果后面确实需要实时性再引入长连接。先把核心业务流程跑通比一开始就追求实时推送更实际。4.3 一个最小可跑的 Kotlin 请求链路Android 端和 Spring Boot 对接的核心是用 Retrofit 定义接口。假设后端有订单详情和抢单两个接口interface OrderApi { GET(order/{id}) suspend fun getOrder(Path(id) id: Long): ResultOrderDTO POST(order/{id}/grab) suspend fun grabOrder(Path(id) id: Long): ResultOrderDTO }这里 Result 是后端统一返回结构的映射。网络请求通过 Retrofit 调用ViewModel 里用一个 loadOrder 方法触发请求并更新 Stateclass OrderDetailViewModel(private val api: OrderApi) : ViewModel() { private val _orderState MutableStateFlowOrderUiState(OrderUiState.Loading) val orderState: StateFlowOrderUiState _orderState fun refresh(orderId: Long) { viewModelScope.launch { try { val response api.getOrder(orderId) _orderState.value OrderUiState.Success(response.data) } catch (e: HttpException) { _orderState.value OrderUiState.Error(e.code()) } catch (e: IOException) { _orderState.value OrderUiState.Error(-1) } } } }轮询可以用一个简单的 while 循环加 delay 来做在界面销毁时通过 viewModelScope 的取消机制停止。注意轮询请求要加异常捕获否则网络抖动一次就退出循环了。5. Vue3 管理后台从订单列表到权限路由的落地要点5.1 管理端页面结构与状态设计管理后台我划分为四个页面订单列表、用户管理、跑腿员审核、数据统计。订单列表是核心页面运营同学一天大部分时间都在盯着它看所以要把搜索状态和分页状态设计得足够顺手。Vue3 里我倾向于用 Composition API 把列表页的状态集中起来。一个典型的查询状态可能包含这些关键词、订单状态、时间范围、当前页码、每页大小。这些字段绑到搜索表单和分页组件上任何一个条件变化都触发重新加载。页面结构不要做太复杂。左侧是菜单顶部是管理员信息和退出登录中间内容区放表格和筛选条件。后台的布局最好保持稳定不要让用户到处找操作按钮。5.2 列表页的搜索、分页与防抖实现搜索功能不能只做前端过滤因为订单量大了以后前端拿全量数据不现实。正确做法是后端接口支持条件查询前端把筛选参数通过请求传给服务器服务器返回分页结果。前端只需要维护好参数对象。一个简化版的 Vue3 列表实现大概是这样的const query reactive({ keyword: , status: undefined as number | undefined, page: 1, size: 10 }) const tableData refOrderInfo[]([]) const total ref(0) const loading ref(false) async function loadOrders() { loading.value true try { const res await getOrders(query) tableData.value res.data.records total.value res.data.total } finally { loading.value false } } function handleSearch() { query.page 1 loadOrders() }关键词搜索最好加防抖避免用户每敲一个字符就触发一次接口请求。比较简单的方式是用 watch 加定时器输入停止 500 毫秒以后再触发搜索。如果你用 Element Plus也可以直接给搜索框加 clearable 属性方便用户一键清空条件。5.3 权限路由与按钮级控制的简化方案管理后台权限分成两个级别菜单路由级和操作按钮级。路由级权限用 Vue Router 的 beforeEach 守卫实现登录后根据角色过滤可访问的路由表。按钮级权限通常会封装一个自定义指令比如 v-permission元素不满足权限条件时直接移除。严格来说前端权限只是用户体验层面。后端接口必须做同样的角色校验否则用户绕过前端直接调接口一样能访问数据。这两个都要做但后端才是底线。登录后 Token 里带上用户角色后端拦截器在每次请求时解析出来再判断接口权限。权限设计不需要一开始就做得很重。用一个 role 字段区分普通用户和管理员骑手权限合并到普通用户里先保证“管理员才能看到后台、用户不能调用管理接口”就够。等系统跑起来了再细化角色权限也不迟。6. 上线前后绕不开的部署与安全问题6.1 用 Nginx 把前后端接到同一个域名的部署方式部署时最常见的问题是 Android 端和管理后台分别访问不同端口导致跨域和配置混乱。我的建议是用 Nginx 做反向代理把三个端统一到同一个域名下API 路径转发到 Spring Boot前端静态文件直接由 Nginx 托管。一个简化版的 Nginx 配置server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; } location /admin/ { alias /var/www/admin/dist/; try_files $uri $uri/ /admin/index.html; } }这样 Android 端只需要配置一个 baseUrl实际请求地址就是 https://your-domain.com/api/...不存在跨域问题。管理后台访问 https://your-domain.com/admin/ 加载静态资源API 也走同一个域名。部署简单后期维护也方便。打包流程中要注意前端项目的 API 环境变量。开发环境指向本地后端生产环境指向线上域名。很多同学项目本地能跑部署到服务器上白屏绝大多数情况就是 API 地址没有切换。Android 端同样不要把本地调试地址写死在代码里应该通过 BuildConfig 区分 Debug 和 Release 环境。6.2 安全自查清单这种校园系统最容易暴雷的其实是安全问题因为学生信息和位置数据都有隐私属性。我的自查清单固定包含以下几条后端参数校验必须做。所有接收前端参数的接口都要做非空、长度、类型校验防止恶意绕过前端直接构造请求。Spring Boot 里可以用 validation 注解简化例如 NotBlank、Size一行的注解比在 Service 里写一堆 if 更可靠。密码存储一律用 BCrypt不能存明文也不能自己发明加密算法。手机号在数据库可以正常保存但接口返回给前端时要做脱敏处理比如只显示前三位和后四位。用户定位坐标不能随便展示给所有客户端普通用户查订单详情时只能看到跑腿员的脱敏联系方式不能拿到完整手机号。管理接口需要严格的权限校验。如果后台没有任何鉴权保护等于把所有订单数据和用户手机号裸奔在公网上。我见过有人做课程设计后台接口没有任何拦截器任何人知道 URL 就能看全部数据。这样即便功能演示满分评审一看安全问题就打了低分。定时任务和大批量导出操作要注意执行频率和日志记录。管理员操作后台时保留操作日志能追溯谁在什么时候改了订单状态。这个日志表非常简单但关键时刻能救命。6.3 常见坑与我的处理经验最后分享几个我实际开发中遇到的坑未必在教科书里能看到。时区问题。后端 MySQL 连接串里如果不明确指定 serverTimezone并且系统里的时间字段直接存当前时间不同时区的服务器和本地环境显示会出现偏差。建议统一使用 Asia/Shanghai 时区并且在代码里所有时间字段都用 LocalDateTime。坐标距离计算不能直接用“经纬度相减再乘一个系数”那样误差会很大尤其在南北方言距离感比较明显的地方。要用 Haversine 公式把球面距离算出来。代码不复杂但结果是可信的public static double distance(double lat1, double lng1, double lat2, double lng2) { double rad Math.PI / 180.0; double dLat (lat2 - lat1) * rad; double dLng (lng2 - lng1) * rad; double a Math.sin(dLat / 2) * Math.sin(dLat / 2) Math.cos(lat1 * rad) * Math.cos(lat2 * rad) * Math.sin(dLng / 2) * Math.sin(dLng / 2); return 6371000.0 * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); }通知渠道问题。Android 8.0 以上必须为通知创建渠道否则 NotificationManager 会静默丢弃通知。测试时如果发现通知不弹先检查有没有创建 NotificationChannel不要一上来就怀疑代码逻辑。接口字段规范。前后端协同开发时后端返回的字段名如果是驼峰Android 端通过 Gson 默认能直接映射同名属性但如果后端返回 json 里多了下划线命名就必须再写映射注解。最稳妥的方式是一切以接口文档为准团队内部在项目启动时就约定统一命名风格。我在实际开发中的最后一个建议是不要急着写代码先把订单状态机画对再把角色权限边界理清这两点决定了整个项目的骨架。骨架对了Spring Boot Vue3 Android 三端项目的后半段推进会顺利得多。后续如果要扩展支付、接入更完整的推送体系或者把抢单改成派单模式底层设计也都是可以平滑接上的。做校园跑腿代取系统真正的价值不是把单一接口跑通而是把一条完整的业务闭环想透、做稳。
)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
