校园跑腿管理信息系统：订单状态机与并发抢单设计-育师

1. 为什么我要动手做一套校园跑腿管理信息系统

先说说我做这套系统的起点。几年前帮一个学生团队做技术顾问，他们想在校内做一个"代取快递、代买饭、代排队"的小平台，最初的方案是拉个群、群里喊单、微信转账，做了两周就崩了：订单没人接、接了没人管、钱对不上、出了纠纷谁都不认。那个时候我就意识到，跑腿这件事看起来简单，本质上是一个多方参与、状态多、时效强、涉及资金流的轻量级业务系统，靠聊天群是撑不住的。

这套校园跑腿管理信息系统要解决的核心问题，说到底就三件事：第一，把零散的"帮我带个饭"变成可追踪的结构化订单；第二，让接单的人和时间可控、可评价，形成正向循环；第三，让钱和责任有迹可循，减少扯皮。它适合三类人参考：正在准备毕业设计或课程设计的学生，需要一套完整可交差的源码与文档；想在校内或园区做轻量跑腿服务的小团队，需要一套能跑起来的最小可用系统；以及刚接触 Web 全栈、想找一个业务闭环完整的项目练手的朋友。

我见过太多"开题报告写得很宏大、代码交付只有一个登录页"的情况。所以这套系统的设计思路是反过来的：先保证业务闭环能完整走通，再谈扩展。订单从发布到完成，中间每一个状态流转都要有明确的触发者、时间戳和校验规则；用户、跑腿员、管理员三种角色各自的权限边界要在接口层就切干净，而不是靠前端藏按钮。这套系统没有多么高深的技术，但它把"一个真实业务该怎么拆"这件事讲清楚了，这才是它能作为开题与毕设选题的价值所在。

下面我会从整体设计、核心数据与状态机、关键流程实现、踩坑排查四个方向完整拆一遍，中间会给出可直接复用的表结构、状态码约定、参数取值计算和避坑清单。数据库用 MySQL，后端可以是 Java 的 Spring Boot 或者 Node.js 的 Express，前端用 Vue 或原生小程序都可以，我在关键处会说明两种技术栈的差异，方便你按自己熟悉的那套去落地。

2. 系统整体设计与角色职责拆解

2.1 三种角色与权限边界的划分逻辑

做这类系统，第一个要定死的不是技术栈，而是角色模型。校园跑腿里天然存在三种人：发单的用户、接单的跑腿员、管全局的管理员。这里有个常见误区：很多人把"跑腿员"当成用户表里的一个字段，is_runner = 1就完事了。我实测下来这样会很快出问题，因为跑腿员需要审核、需要信誉分、需要接单上限、可能需要绑定学号或身份信息，这些字段堆在用户表里会让表越来越脏。

我的做法是用户表与跑腿员档案表分离：user表只管身份认证和基础信息，runner_profile表单独存跑腿员的审核状态、信誉分、累计完成单数、当前在途单数。两者是一对零或一的关系，一个用户可以申请成为跑腿员，但档案独立。好处是查询"可接单的跑腿员"时只需扫档案表，且管理员审核跑腿员不会污染用户主表。

权限边界的划分我用一张表说清楚，这张表在写接口鉴权中间件时可以直接对照：

角色	可访问模块	关键限制	越权风险点
普通用户	发单、查自己的订单、评价、充值/查看余额	只能操作`owner_id = 自己`的订单	通过改 URL 里的订单 ID 查看他人订单
跑腿员	抢单大厅、接单、更新配送状态、查看自己的接单记录	同一时间在途单数量有上限，需审核通过	绕过状态机直接把订单置为完成
管理员	用户管理、跑腿员审核、订单仲裁、异常单处理、数据统计	不能直接修改订单金额（需走退款流水）	删除订单导致对账断链

我在接口层的做法很朴素：每个需要鉴权的接口先解析 token 拿到userId和role，然后在业务层做资源归属校验，而不是只在路由层判断角色。举个具体例子，PUT /orders/{id}/status这个接口，路由层会判断你是不是跑腿员，但业务层必须再查一次这个订单的runner_id是不是你，否则任何跑腿员都能改任何订单的状态。这一步我见过太多项目漏掉，答辩时被老师一问就露馅。

注意：资源归属校验一定要在服务端做，前端隐藏按钮只是体验优化，不构成任何安全边界。

2.2 技术选型的取舍与理由

技术栈这块我不给唯一答案，但给判断依据。如果你目标是顺利交付、少踩环境坑，Java + Spring Boot + MyBatis-Plus + MySQL + Vue 是最稳的组合，生态成熟、报错信息好搜、答辩老师也熟悉；如果你想要开发速度快、前后端一套语言，Node.js + Express/Koa + MySQL + 原生小程序前端更合适，尤其适合要做成小程序形态的场景。

关键取舍点在实时性上。跑腿业务有一个强需求：新订单发布后，跑腿员要尽快看到。方案有三档，我按复杂度递增列出来：

方案	实现方式	实时性	适用场景	我的评价
轮询	前端每 10 到 15 秒请求一次订单列表	一般，最多延迟一个周期	毕设、小规模内测	最简单，稳定，推荐起步
长轮询	请求挂起 30 秒，有单立即返回	较好	中等规模	实现中等，注意超时兜底
WebSocket	服务端主动推送	好	订单量大、多端在线	增加连接管理成本，非必需

我的建议是第一版老老实实做轮询，把订单状态机、并发抢单、资金流水这些真正容易出错的地方做扎实。抢单的并发问题不是靠 WebSocket 解决的，是靠数据库层面的条件更新解决的，这一点后面会详细讲。

数据库方面必须用 InnoDB 引擎，因为要用到行锁和事务。字符集统一utf8mb4，别用utf8，否则用户昵称里带个特殊字符就存不进去，这种问题排查起来非常费时间。时间字段统一用datetime而不是timestamp，避免时区转换带来的诡异偏差，尤其在服务器和本地环境不一致的时候。

2.3 目录结构与分层约定

后端我习惯按模块 + 分层组织，不用纯粹的 controller/service/mapper 大平铺。以 Spring Boot 为例，com.demo.errand下面分order、user、runner、wallet、admin、common六个模块，每个模块内部再分 controller、service、mapper、dto。这样改订单相关逻辑时不用在几十个文件里翻找。

前端按页面拆：登录注册、发单页、订单大厅、我的订单、订单详情、跑腿员工作台、个人中心、管理后台。订单详情页是复用率最高的，用户视角、跑腿员视角、管理员视角共用同一个组件，靠角色渲染不同操作按钮，这样能省掉大量重复代码。

errand-system/ ├── backend/ │ ├── src/main/java/com/demo/errand/ │ │ ├── order/ # 订单：发布、抢单、状态流转、评价 │ │ ├── user/ # 用户：注册、登录、资料 │ │ ├── runner/ # 跑腿员：申请、审核、信誉分 │ │ ├── wallet/ # 钱包：余额、流水、提现 │ │ ├── admin/ # 后台：审核、仲裁、统计 │ │ └── common/ # 统一响应、异常、鉴权、工具 │ └── src/main/resources/ │ ├── application.yml │ └── mapper/ # MyBatis XML（用了 Plus 可省） ├── frontend/ # Vue 或小程序 │ ├── pages/ │ └── api/ # 接口封装，统一错误处理 └── sql/ ├── schema.sql # 建表 └── init-data.sql # 初始化数据

提示：把建表 SQL 和初始化数据单独放sql目录并在 README 里写清楚执行顺序，交付时能省掉对方一半的环境问题沟通成本。

3. 数据模型与订单状态机的核心细节

3.1 核心表结构设计与字段取舍

表设计是这套系统的地基，我先给出最核心的四张表，字段都是经过实际使用验证的，删掉任何一个都会在后面某个场景里难受。

用户表只放认证相关和最基础的展示信息：

CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `open_id` VARCHAR(64) DEFAULT NULL COMMENT '第三方登录标识，可空', `phone` VARCHAR(20) NOT NULL COMMENT '登录手机号', `password` VARCHAR(100) NOT NULL COMMENT '加盐哈希后的密码', `nickname` VARCHAR(50) NOT NULL, `avatar` VARCHAR(255) DEFAULT NULL, `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0用户 1跑腿员 2管理员', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0正常 1封禁', `balance` DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '余额，单位元', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

余额用DECIMAL(10,2)，绝对不能用float或double，浮点数做金额运算会出现 0.1 + 0.2 不等于 0.3 的问题，对账时会被折磨到怀疑人生。这一点在很多学生的源码里都踩过。

订单表是核心中的核心：

CREATE TABLE `errand_order` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL COMMENT '业务单号，对外展示', `owner_id` BIGINT NOT NULL COMMENT '发单人', `runner_id` BIGINT DEFAULT NULL COMMENT '接单人，未接单为空', `type` TINYINT NOT NULL COMMENT '1取快递 2代买 3代排队 4其他', `title` VARCHAR(100) NOT NULL, `content` VARCHAR(500) DEFAULT NULL, `from_addr` VARCHAR(200) DEFAULT NULL COMMENT '取货/起点', `to_addr` VARCHAR(200) NOT NULL COMMENT '送达终点', `expect_time` DATETIME DEFAULT NULL COMMENT '期望送达时间', `price` DECIMAL(10,2) NOT NULL COMMENT '订单金额', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '见状态机定义', `pay_status` TINYINT NOT NULL DEFAULT 0 COMMENT '0未支付 1已支付 2已退款', `accept_time` DATETIME DEFAULT NULL COMMENT '接单时间', `finish_time` DATETIME DEFAULT NULL COMMENT '完成时间', `cancel_reason` VARCHAR(200) DEFAULT NULL, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_status_created` (`status`, `created_at`), KEY `idx_owner` (`owner_id`), KEY `idx_runner` (`runner_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

索引这三个是有讲究的。idx_status_created服务于抢单大厅的"按状态查、按时间倒序"这个最高频查询；idx_owner和idx_runner分别服务于"我的发单"和"我的接单"。没有这三个索引，数据量上到几万单时列表页会明显卡顿。

跑腿员档案表独立出来：

CREATE TABLE `runner_profile` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL, `real_name` VARCHAR(50) NOT NULL, `student_no` VARCHAR(30) DEFAULT NULL, `verify_status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待审 1通过 2驳回', `credit_score` INT NOT NULL DEFAULT 100 COMMENT '信誉分，初始100', `doing_count` INT NOT NULL DEFAULT 0 COMMENT '当前在途单数', `total_count` INT NOT NULL DEFAULT 0 COMMENT '累计完成单数', `max_doing` INT NOT NULL DEFAULT 3 COMMENT '同时在途上限', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_user` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

doing_count和max_doing这两个字段是接单上限的实现基础，没有它们，一个跑腿员能同时接几十单，结果一单都送不到，平台口碑直接崩掉。

3.2 订单状态机的完整定义与流转规则

状态机是这套系统最值得反复讲清楚的部分。我把订单状态定义成六个值，够用且不冗余：

状态码	名称	含义	谁可以进入这个状态
0	待接单	已发布、已支付，等跑腿员抢	发单人发布后自动进入
1	已接单	跑腿员已接，正在执行	跑腿员抢单成功
2	已送达	跑腿员标记送达，等待确认	接单跑腿员
3	已完成	发单人确认收货，货款结算	发单人确认，或超时自动确认
4	已取消	未接单前取消，全额退款	发单人取消，或超时无人接单
5	仲裁中	双方有争议，等管理员处理	发单人或跑腿员发起申诉

流转关系必须写成白名单，也就是只允许表里明确列出的跳转，其他一律拒绝。我把它写成代码里的一个常量映射：

// 状态流转白名单：key 当前状态，value 允许进入的下一状态集合 private static final Map<Integer, Set<Integer>> FLOW = Map.of( 0, Set.of(1, 4), // 待接单 -> 已接单 / 已取消 1, Set.of(2, 5), // 已接单 -> 已送达 / 仲裁中 2, Set.of(3, 5), // 已送达 -> 已完成 / 仲裁中 3, Set.of(), // 已完成是终态 4, Set.of(), // 已取消是终态 5, Set.of(3, 4) // 仲裁中 -> 已完成 / 已取消（退款） );

为什么坚持白名单而不是黑名单？因为黑名单的思维是"禁止几种情况"，而业务会不断加新状态，你永远想不全该禁哪些。白名单反过来：没被明确允许的跳转全部拒绝，新增状态时只需要考虑它和谁可以互通，出错概率低一个量级。

这套白名单还解决了一个很隐蔽的问题：重复提交。用户手抖连点两次"确认收货"，如果不做幂等，订单会被结算两次、跑腿员被加两次钱。处理方式是在状态更新时加前置条件，即UPDATE ... SET status=3 WHERE id=? AND status=2，影响行数为 0 就说明状态已经不对了，直接返回"订单状态已变更，请刷新"。这行 SQL 是整个系统里最简陋也最有效的幂等方案。

3.3 业务单号与时间字段的设计考量

主键用自增 ID，但对外所有接口都只暴露order_no，不暴露主键。原因很实际：自增 ID 会泄露业务量（新单号减旧单号就知道平台一共多少单），也方便被人按顺序遍历。order_no的生成规则我用的是"时间戳 + 用户 ID 后三位 + 随机两位"，例如2024051814301200703，纯数字、无歧义、便于口头报单号。

时间字段有一处细节要特别注意：updated_at用了ON UPDATE CURRENT_TIMESTAMP，这在调试时很方便，但在做"超时未接单自动取消"这类定时任务时不要依赖它判断业务时间，一定要用created_at加明确的时间窗口去算，否则任何一次无关更新都会把定时逻辑带偏。我早期就因为这个把一批正常订单误取消了。

4. 从发单到结算的关键流程实现

4.1 抢单并发的正确解法与参数计算

抢单是这个系统里唯一真正存在并发竞争的地方。场景很简单：一个订单挂在大厅，两个跑腿员同时点击"接单"。如果代码写成"先查订单状态是不是 0，是就更新成 1 并把 runner_id 设为自己"，那必然出现两人都抢到的情况，因为查询和更新之间有时间窗口。

正确的做法是把判断条件塞进 UPDATE 语句本身，依靠数据库行锁保证原子性：

UPDATE errand_order SET runner_id = #{runnerId}, status = 1, accept_time = NOW() WHERE id = #{orderId} AND status = 0 AND runner_id IS NULL;

执行后检查影响行数，1代表抢单成功，0代表被人抢先了，直接给前端返回"手慢了，订单已被接走"。这一条 SQL 天然带幂等性，重复点击也不会重复写入。

但这还没完，还有两步必须放在同一个事务里：

第一步，扣减跑腿员的可接单额度，也就是把doing_count加 1，同时用条件更新防止超限：

UPDATE runner_profile SET doing_count = doing_count + 1 WHERE user_id = #{runnerId} AND doing_count < max_doing;

第二步，如果这个更新影响行数为 0（说明已达上限），整个事务回滚，订单回到待接单状态。顺序上我习惯先更新档案再更新订单，因为档案更新的条件更容易失败，让它先失败可以少做无效的订单更新；反过来也能跑通，但要保证两步在同一事务内。

关于max_doing取多少合适，我给一个基于经验的计算思路：假设单均配送时长 25 分钟（含取货等待、路上、上楼），跑腿员一次连续工作 2 小时，那么理论上限是 4.8 单；考虑到取货点排队、电梯等待这些不可控因素，实际稳定值取3 单比较合理。交付版本默认给 3，管理员可以对信誉分高于 120 的跑腿员放宽到 5 单。这个数字不要拍脑袋定成 10，否则用户等待体验会明显变差，差评率上升。

注意：事务里不要做远程调用或发消息这类耗时操作，把通知做成事务提交后再触发，否则事务持有锁的时间被拉长，抢单接口在并发稍高时就会排队。

4.2 资金流水的记账方式与余额一致性

涉及钱的逻辑我不建议"直接改余额"这一种操作。跑腿业务至少有四个资金动作：发单冻结、完成结算、取消退款、提现。如果每个动作都直接UPDATE user SET balance = balance ± x，出了问题你根本查不出钱是怎么错的。

我的做法是双表记账：一张wallet_flow流水表记录每一笔变动，user.balance只作为快照。每次余额变动必须先插流水再更新快照，两步在同一事务内，并且流水表插入时记录变动后的余额值，这样任何时候都能通过流水重算校验余额对不对。

CREATE TABLE `wallet_flow` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL, `order_id` BIGINT DEFAULT NULL, `direction` TINYINT NOT NULL COMMENT '1收入 -1支出', `amount` DECIMAL(10,2) NOT NULL, `balance_after` DECIMAL(10,2) NOT NULL COMMENT '变动后余额快照', `biz_type` TINYINT NOT NULL COMMENT '1发单支出 2接单收入 3退款 4提现 5充值', `remark` VARCHAR(200) DEFAULT NULL, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY `idx_user_time` (`user_id`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

发单时的逻辑是：用户余额减去订单金额，插一条biz_type=1的支出流水，钱进入"平台待结算"状态（可以先放在订单上，pay_status=1表示已支付）。订单完成后，跑腿员收入 = 订单金额 × (1 - 平台抽成比例)。假如订单 5 元，抽成 10%，跑腿员实收 4.5 元，这个乘法必须在服务端算，且用BigDecimal的multiply加setScale(2, RoundingMode.HALF_UP)，不要用 double。

顺带说一个对账技巧：写个定时任务每天凌晨跑一次核对，把所有pay_status=1但status=3的订单按跑腿员分组求和，和流水表当天的收入总额比对，不一致就打日志告警。这个任务我强烈建议加上，它是发现隐藏 bug 最有效的手段，很多结算相关的错误都是在两天后才被发现，有了对账能当天定位。

4.3 超时自动处理与定时任务的落地

跑腿业务有两个必须自动处理的超时场景：一是发单后长时间无人接单，要让用户能取消并退款，不能一直挂着；二是已送达后用户不确认，货款不能永远卡住。

第一个场景我用 30 分钟窗口：发布超过 30 分钟仍为状态 0 的订单，系统自动取消并退款，同时给用户推一条通知。为什么是 30 分钟？校园场景里代取快递的高峰集中在中午和傍晚，超过半小时还没人接，基本说明这个时间点运力不足，继续挂着只会让用户反复刷新页面。

第二个场景用 24 小时窗口：状态 2（已送达）超过 24 小时未确认，自动置为 3 并结算。跑腿员已经把东西送到了，不能让用户的"不确认"变成拒付手段。

定时任务的实现方式，Spring Boot 里用@Scheduled(cron = "0 */5 * * * ?")每 5 分钟扫一次即可，Node.js 里用node-cron。注意一次不要处理太多，按每批 100 条循环处理，避免单个事务过大锁表。核心 SQL 同样要把状态作为条件：

UPDATE errand_order SET status = 4, cancel_reason = '超时无人接单', updated_at = NOW() WHERE status = 0 AND created_at < DATE_SUB(NOW(), INTERVAL 30 MINUTE) LIMIT 100;

用LIMIT分批是经验之谈。某次我把LIMIT去掉，凌晨批量处理了几千条历史数据，整个更新事务锁了大批行，白天接口直接超时，排查了半天才定位到是这条 SQL。

4.4 评价与信誉分的联动机制

跑腿员信誉分不能只是个摆设，它要真的影响派单机会，否则跑腿员没有动力维护服务质量。

我设定的规则是：初始 100 分，用户完成订单后可打 1 到 5 星，跑腿员每单获得的分数变动为(星级 - 3) × 2。也就是 5 星加 4 分、4 星加 2 分、3 星不变、2 星减 2 分、1 星减 4 分。信誉分低于 80 的跑腿员，max_doing自动降为 1 单；低于 60 分的，系统自动暂停接单资格，需要重新提交审核。

这个公式的价值在于正负对称、变化可感知：一单 5 星的加分不够抵消一单 1 星的扣分，跑腿员就必须认真对待每一单，而不是靠大量接单摊薄差评。分数变动的同时要写一条信誉流水，和钱包流水同理，便于申诉时查证。

评价表本身要限制一单一评，用UNIQUE KEY (order_id)实现，避免用户刷好评。评价内容允许为空（用户可能只想打星不想写字），但星级必须和订单关联校验：只有status=3的订单才能被评价。

5. 实操中踩过的坑与问题排查实录

5.1 订单状态被非法跳转的排查过程

我在压测时发现过一个诡异现象：有些订单的status是 2（已送达），但runner_id是空的，也就是没人接单却显示送达。查日志才发现，测试同学用接口工具直接调了状态更新接口，传入了status=2，而当时的代码只校验了"当前用户是不是跑腿员角色"，没校验订单归属和状态流转合法性。

修复方案就是前面提到的两层校验：第一层，状态跳转必须在白名单内，0 -> 2这种跳转直接被拒绝；第二层，非管理员操作必须校验订单归属。修复后我加了一个测试用例专门跑所有非法跳转组合，把6 × 6 = 36种跳转逐一验证，只有白名单里的能通过。这个测试用例现在成了我所有类似项目的模板。

5.2 金额显示与计算不一致的典型原因

有用户反馈"我余额显示 95.5 元，但算下来应该是 95.50 元，提现时提示余额不足"。这类问题的根源通常是三处：一是前端用了 JS 的浮点运算做展示合并，0.1 + 0.2这类问题；二是后端某个字段用了float；三是流水表里存了不同精度的值，求和后出现95.4999999。

排查顺序我总结成一个固定套路：先查数据库里该用户所有流水的amount求和（用 SQL 的SUM而不是代码算），再和user.balance比对，然后检查information_schema里所有金额字段的类型。定位最快的方式其实是对账任务，它会当天就把异常报出来。

现象	最可能原因	排查命令 / 方法	修复方式
余额差几分钱	金额字段用了 float/double	查`information_schema.columns`的`data_type`	全部改成`DECIMAL(10,2)`
列表金额和详情不一致	前端本地做加减聚合	看前端是否有`+`运算合并金额	聚合计算放服务端
提现提示余额不足但看着够	提现时有未结算冻结金额	检查是否有`status=1`的在途订单	页面明确展示"可用余额"与"冻结金额"
结算后跑腿员没收到钱	事务未提交或结算任务未覆盖该单	查流水表是否有`biz_type=2`记录	补跑结算任务并加告警

提示：给用户展示时把"余额"拆成"可用余额"和"冻结中金额"两个数字，能提前消掉一大半客诉。

5.3 抢单接口在并发下的表现与压测方法

不压测就上线，是这类项目最常见的隐患。我用的办法很土但有效：写个简单的脚本并发 50 个请求抢同一个订单，看成功数。正确实现下成功数必然是 1，订单的runner_id只能是最后那个成功的人。

压测脚本用 Python 的concurrent.futures十几行就够了：

import concurrent.futures, requests ORDER_ID = 1001 TOKEN = "填入跑腿员token" def grab(i): r = requests.post( f"http://localhost:8080/api/orders/{ORDER_ID}/accept", headers={"Authorization": TOKEN}, timeout=5 ) return r.json().get("code") with concurrent.futures.ThreadPoolExecutor(max_workers=50) as ex: results = list(ex.map(grab, range(50))) print("成功次数:", results.count(0), "失败次数:", len(results) - results.count(0))

如果成功次数大于 1，说明你的实现里存在查询后再更新的间隙；如果出现数据库死锁异常，说明两个事务的加锁顺序不一致，需要统一成"先档案后订单"。

5.4 常见问题速查表

下面这张表是我把实际遇到的问题压缩后的版本，基本覆盖了新手最容易卡的十几个点，可以直接当自查清单用：

问题	排查思路	解决方式
抢单出现两人同时成功	检查 UPDATE 是否带`status=0`条件	条件更新 + 检查影响行数
跑腿员超额接单	检查是否只在应用层判断数量	`doing_count < max_doing`写进 UPDATE
确认收货导致重复结算	无幂等保护	`WHERE status=2`条件更新，影响行数判断
定时任务误取消正常订单	用了`updated_at`判断	改用`created_at`+ 时间窗口
中文昵称存成问号	库或表字符集是`utf8`	改为`utf8mb4`
跨域请求失败	前端域名与后端不一致	后端配置 CORS，允许指定来源
token 过期后接口 401 未处理	前端缺少统一拦截	axios 响应拦截器统一跳登录
上传凭证图片后页面打不开	返回了服务器相对路径	拼接可访问的完整 URL 或使用静态资源映射
列表页加载慢	缺少`(status, created_at)`联合索引	补索引，并用`EXPLAIN`验证
管理员删单后对账不平	物理删除订单	改逻辑删除，`deleted`字段标记