CampusDelivery · 济跑跑

项目概述

济跑跑（CampusDelivery）是我们在数据库原理与应用课程设计中开发的校园跑腿平台，由十人团队按业务模块协作完成。它面向外卖分发、快递代取和私人跑腿等场景，让普通用户发布需求、跑腿员承接配送、管理员维护服务和协调调度。

项目覆盖任务履约的完整业务：从账号、地址、服务类型和跑腿员资格管理，到任务发布、接派、配送、收货后支付，再到评价投诉、退款、收入结算、审计与统计报表。我的工作位于其中的接派单与配送环节，连接用户发布的任务和跑腿员实际执行的服务。

整体业务流程

系统围绕普通用户、跑腿员和管理员三种角色组织页面与权限，主流程如下：

1. 发布任务：用户维护收货地址，选择服务类型并填写相应任务信息，任务进入待接单状态。
2. 分配与配送：审核通过的跑腿员在任务大厅接单，管理员也可以派单或重派。承接人按顺序更新取货、配送和送达状态。
3. 收货与支付：发布者确认收货后进入支付流程，支付成功后任务完成，跑腿员工作状态随活动任务变化。
4. 评价与运营：用户可以评价服务、提交投诉或申请退款；管理员处理售后、生成跑腿员结算单，并进行审计和报表统计。

各模块通过任务、接派记录和支付记录衔接，历史记录为后续评价、结算和审计提供依据。我的确认收货功能形成可支付前提，支付、退款和支付后的最终完成状态由负责支付模块的组员实现。

技术与分层实现

项目采用 C#、.NET 9、ASP.NET Core MVC（Model–View–Controller，模型—视图—控制器）与 Oracle 19c。Razor 页面负责表单和展示，Controller 接收请求，Service 处理权限与业务规则，Repository 通过参数化 SQL 读写数据库，底层连接组件统一管理 Oracle 连接。数据库包含 24 张业务表。

这种分层也用于我负责的模块：页面上的接单或状态更新操作，需要经过身份、资格与当前任务状态检查，再将任务、接派记录和状态日志作为一次业务操作保存。页面反馈与数据库变化需要相互对应。

我的接派单与状态流转实践

从任务大厅到确认收货

我作为组员 6，负责任务大厅、跑腿员抢单、管理员派单与重派、配送状态顺序流转、发布者确认收货，以及接派记录和状态日志，工作覆盖页面、业务处理和数据访问。

配送过程按“已接单 → 已取货 → 配送中 → 待确认”推进，每一步都要检查操作者与当前状态。发布者确认收货后交给支付流程。界面根据任务阶段提供下一步操作，服务端也校验同样的规则，处理越权操作、重复请求或跳过中间状态的情况。

接单竞争与数据一致性

两个跑腿员可能同时承接同一条任务。集成版本通过数据库事务和任务行锁，协调当前状态检查、承接人更新、接派记录与状态日志的写入；竞争失败的请求会返回相应提示。这类规则需要从数据库结果核对，才能确认同一任务保留了唯一有效的承接结果。

管理员派单与重派也要考虑任务状态、跑腿员资格以及发布者与承接人的关系。重派会新增操作记录，保留原有接派历史，便于后续查看任务如何转交。

多单工作台与重派迭代

后续迭代中，我增加了跑腿员多单接单、进行中任务数展示，以及基于活动任务判断 FREE/BUSY 工作状态的逻辑。跑腿员可以同时处理多项配送；重派或支付完成一项任务后，需要结合其他活动任务判断其当前状态。

管理员端也增加了已指派任务表格、重派搜索、状态筛选和分页，并通过弹窗搜索选择跑腿员。这让调度操作能够同时查看任务和承接人，减少在多个页面之间来回查找。

下面是多单配送工作台的原始测试截图，使用课程测试数据：

团队协作与验证结果

我的功能通过拉取请求合入团队分支，团队随后继续进行了重构与修复。我在集成环境中验证个人模块，并同时检查页面反馈、任务状态、接派记录、日志和跑腿员工作状态。

2026 年 9 月，TC-ASSIGN-01 至 TC-ASSIGN-09 九条手工用例在公网环境执行并通过，配有截图和 Oracle 数据库证据。验证内容包括正常接单、多单承接、管理员派单与重派、资格限制、配送顺序，以及并发和失败路径：

• 两个独立会话同时抢同一任务，只有一个成功，数据库保留一条接派记录和一条对应的状态日志。
• 将任务重派后，核对原承接人与新承接人的活动任务数和忙闲状态。
• 自接自派和非法状态跳转请求被拒绝，任务与日志保持原有状态。

这个项目让我把数据库事务、权限和状态流转放进具体业务中理解。一次页面操作会影响多张表，也会影响其他角色后续能做什么；围绕完整流程检查这些关联，是我在接派单模块中持续关注的部分。

公开仓库 ↗