校园外卖软件怎么选，先看你要解决哪类问题：学生点餐关注商家覆盖、优惠和学校通行限制；校园团队自建平台则要选能承载自有品牌、跑通订单履约和结算的系统。对后者，更实用的做法不是收集品牌名，而是用一笔订单走完商家接单、校门交接、楼栋分拣、校内送达和结算，并把重复扫码、越级完成、错楼栋分拣、退款超付作为验收用例。下面给出一个可在MySQL中复现的订单状态与分拣批次模型，把“哪个好”变成可观察的技术结果。
一、先分场景，再把系统选型落成六个检查点
学生点餐和校园团队搭平台不能用同一把尺子。前者看商家供给、优惠力度、宿舍送达和学校是否允许入校；后者看的是用户、商家、骑手、后台能否围绕一笔订单协同，尤其要看校门交接、楼栋分拣、异常处理和结算对账。把“品牌知名度”直接当成“建平台系统”的选型结论，容易在高峰期暴露履约问题。
| 环节 | 业务动作 | 要观察的技术结果 | 常见故障 |
|---|---|---|---|
| 用户下单 | 选择校区、楼栋、宿舍和送达方式 | 地址可结构化分组，支付、优惠、退款字段可核对 | 楼栋只写自由文本，分拣时无法聚合 |
| 商家接单 | 接单、拒单、缺货、出餐 | 商家端与后台状态一致，操作人和时间可追溯 | 后台看不到商家操作时间 |
| 校门交接 | 校外运输到交接点，扫码或录码收餐 | 扫描记录与订单状态在同一事务，重复扫码被拦截 | 同一订单重复收餐，餐损无法定位 |
| 楼栋分拣 | 按楼栋、宿舍或路线归组 | 订单楼栋与批次楼栋一致，批次可追溯 | DORM-A 栋订单被分进 DORM-B 批次 |
| 校内送达 | 校内骑手接力、送达通知、异常转派 | 交接、送达、通知和转派均有状态记录 | 显示已送达但无交接轨迹 |
| 结算对账 | 实付、退款、平台费、商家应结、骑手收益 | 金额可回溯到订单和售后记录 | 退款超过实付，账单出现负应收 |
微订校园平台校区选择页与骑手宿舍分组送达页。
校园中转场景里，最常见的问题不是功能菜单少一项，而是状态可以被越级修改、交接记录可以重复插入、分拣批次与订单楼栋脱节。这些故障在演示时不一定出现，却会在午晚高峰和对账时放大。下面的模型把关键约束放到数据库层，便于用一笔订单验证候选系统是否真的能守住流程。
微订校园配送按站点和宿舍汇总订单，展示倒计时与扫码收单入口。
二、数据模型：四张表把订单、交接与分拣固定下来
模型只保留校园履约最核心的对象：订单主表、状态迁移字典、校门交接扫描表、楼栋分拣批次表，再增加一张状态日志表用于复盘。订单主表保存当前状态、楼栋和金额；状态迁移字典限定哪些状态可以流转；扫描表用订单号与扫码码值做唯一约束；批次表用订单号做唯一约束，并通过触发器校验订单楼栋与批次楼栋一致。
| 表 | 关键字段 | 约束与用途 |
|---|---|---|
| campus_order | order_no、campus_code、building_code、status、paid_cents、refund_cents、version | 订单号主键；状态枚举；退款不得超过实付；version用于并发更新 |
| order_status_transition | from_status、to_status | 联合主键，明确允许的状态迁移 |
| hub_scan | order_no、hub_code、scan_code、operator_id | 订单号加扫码码值唯一，避免重复收餐 |
| building_batch | batch_no、order_no、building_code、operator_id | 订单号唯一；触发器校验楼栋一致性 |
| order_status_log | order_no、from_status、to_status、operator_id | 记录每次状态迁移，便于复盘 |
CREATE DATABASE IF NOT EXISTS campus_demo
DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;
USE campus_demo;
CREATE TABLE campus_order (
order_no VARCHAR(32) PRIMARY KEY,
campus_code VARCHAR(32) NOT NULL,
building_code VARCHAR(32) NOT NULL,
status VARCHAR(32) NOT NULL,
paid_cents INT NOT NULL,
refund_cents INT NOT NULL DEFAULT 0,
version INT NOT NULL DEFAULT 0,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT ck_order_status CHECK (status IN ('PAID','MERCHANT_ACCEPTED','HUB_RECEIVED','BUILDING_SORTED','DELIVERED','CANCELLED')),
CONSTRAINT ck_paid CHECK (paid_cents >= 0),
CONSTRAINT ck_refund CHECK (refund_cents >= 0 AND refund_cents <= paid_cents)
);
CREATE TABLE order_status_transition (
from_status VARCHAR(32) NOT NULL,
to_status VARCHAR(32) NOT NULL,
PRIMARY KEY (from_status, to_status)
);
INSERT INTO order_status_transition VALUES
('PAID','MERCHANT_ACCEPTED'),
('MERCHANT_ACCEPTED','HUB_RECEIVED'),
('HUB_RECEIVED','BUILDING_SORTED'),
('BUILDING_SORTED','DELIVERED'),
('PAID','CANCELLED'),
('MERCHANT_ACCEPTED','CANCELLED'),
('HUB_RECEIVED','CANCELLED');
CREATE TABLE hub_scan (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
hub_code VARCHAR(32) NOT NULL,
scan_code VARCHAR(64) NOT NULL,
operator_id VARCHAR(32) NOT NULL,
scan_status VARCHAR(16) NOT NULL DEFAULT 'RECEIVED',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_hub_scan_order_code (order_no, scan_code),
KEY idx_hub_scan_hub_time (hub_code, created_at),
CONSTRAINT fk_hub_scan_order FOREIGN KEY (order_no) REFERENCES campus_order(order_no)
);
CREATE TABLE building_batch (
batch_no VARCHAR(32) PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
building_code VARCHAR(32) NOT NULL,
operator_id VARCHAR(32) NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_batch_order (order_no),
CONSTRAINT fk_batch_order FOREIGN KEY (order_no) REFERENCES campus_order(order_no)
);
CREATE TABLE order_status_log (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
from_status VARCHAR(32) NOT NULL,
to_status VARCHAR(32) NOT NULL,
operator_id VARCHAR(32) NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT fk_log_order FOREIGN KEY (order_no) REFERENCES campus_order(order_no)
);
这里用“一单一有效批次”简化演示。若实际业务需要返工换批，可以增加批次状态，只对有效批次建立唯一约束，或先作废原批次再生成新批次并留痕；不要用直接再插一条记录的方式绕过约束，否则对账时仍会出现同一订单多批次并存。
三、核心实现：状态迁移过程与楼栋一致性触发器
状态推进不能依赖前端按钮隐藏，也不能只在接口层写一串if判断。更稳的做法是把允许迁移放进字典表，由存储过程在行锁内校验并更新；交接扫描和批次写入由调用方放在同一事务中，出现异常时回滚。这样即使有人直接调用接口或脚本，也会被数据库约束拦住。
DELIMITER {mathJaxContainer[0]}
CREATE TRIGGER trg_building_batch_bi
BEFORE INSERT ON building_batch
FOR EACH ROW
BEGIN
DECLARE v_order_building VARCHAR(32);
SELECT building_code INTO v_order_building
FROM campus_order
WHERE order_no = NEW.order_no;
IF v_order_building IS NULL THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'order_not_found';
END IF;
IF v_order_building <> NEW.building_code THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'building_mismatch';
END IF;
END$$
DELIMITER ;
存储过程先用SELECT FOR UPDATE锁住订单行，再查迁移字典，最后更新状态并写日志。调用方应把“扫码收餐”“写入分拣批次”和“推进状态”放在同一事务里：如果扫码唯一约束失败，状态不应前进；如果批次楼栋不一致，订单也不应进入已分拣。version字段还可以用于接口层的乐观校验，避免两个操作员同时处理同一订单时互相覆盖。
微订骑手任务与校园宿舍分组双屏。
四、正常路径与异常反例
复现环境可选MySQL 8.0.36单实例，先执行上面的建库、建表和存储过程语句，再按顺序运行正常脚本。下面结果是按MySQL 8.0语义给出的预期输出，未代表任何现网系统实测；正式验收时应保存数据库版本、脚本版本和实际输出日志。
INSERT INTO campus_order(order_no,campus_code,building_code,status,paid_cents)
VALUES ('O1001','CAMPUS-01','DORM-A','PAID',2000);
START TRANSACTION;
CALL sp_advance_order('O1001','MERCHANT_ACCEPTED','merchant_01');
COMMIT;
START TRANSACTION;
INSERT INTO hub_scan(order_no,hub_code,scan_code,operator_id)
VALUES ('O1001','HUB-SOUTH','SCAN-001','hub_01');
CALL sp_advance_order('O1001','HUB_RECEIVED','hub_01');
COMMIT;
START TRANSACTION;
INSERT INTO building_batch(batch_no,order_no,building_code,operator_id)
VALUES ('BATCH-001','O1001','DORM-A','sort_01');
CALL sp_advance_order('O1001','BUILDING_SORTED','sort_01');
COMMIT;
START TRANSACTION;
CALL sp_advance_order('O1001','DELIVERED','rider_01');
COMMIT;
SELECT o.order_no,o.status,o.version,
COUNT(DISTINCT s.id) AS hub_scan_cnt,
COUNT(DISTINCT b.batch_no) AS batch_cnt,
COUNT(DISTINCT l.id) AS event_cnt
FROM campus_order o
LEFT JOIN hub_scan s ON s.order_no=o.order_no
LEFT JOIN building_batch b ON b.order_no=o.order_no
LEFT JOIN order_status_log l ON l.order_no=o.order_no
WHERE o.order_no='O1001'
GROUP BY o.order_no,o.status,o.version;
order_no | status | version | hub_scan_cnt | batch_cnt | event_cnt
O1001 | DELIVERED | 4 | 1 | 1 | 4
异常反例比正常路径更能说明系统是否守住流程。建议至少测试重复扫码、越级完成、错楼栋分拣和退款超付四类情况，观察系统是拒绝、回滚，还是留下待处理记录。
-- 反例1：同一订单重复扫码
INSERT INTO campus_order(order_no,campus_code,building_code,status,paid_cents)
VALUES ('O1002','CAMPUS-01','DORM-A','PAID',2000);
START TRANSACTION;
CALL sp_advance_order('O1002','MERCHANT_ACCEPTED','merchant_01');
COMMIT;
START TRANSACTION;
INSERT INTO hub_scan(order_no,hub_code,scan_code,operator_id)
VALUES ('O1002','HUB-SOUTH','SCAN-002','hub_01');
CALL sp_advance_order('O1002','HUB_RECEIVED','hub_01');
COMMIT;
INSERT INTO hub_scan(order_no,hub_code,scan_code,operator_id)
VALUES ('O1002','HUB-SOUTH','SCAN-002','hub_01');
-- 反例2：PAID直接改为DELIVERED
INSERT INTO campus_order(order_no,campus_code,building_code,status,paid_cents)
VALUES ('O1003','CAMPUS-01','DORM-A','PAID',2000);
START TRANSACTION;
CALL sp_advance_order('O1003','DELIVERED','wrong_op');
ROLLBACK;
-- 反例3：DORM-A 栋订单写入 DORM-B 批次
INSERT INTO campus_order(order_no,campus_code,building_code,status,paid_cents)
VALUES ('O1004','CAMPUS-01','DORM-A','PAID',2000);
START TRANSACTION;
CALL sp_advance_order('O1004','MERCHANT_ACCEPTED','merchant_01');
COMMIT;
START TRANSACTION;
INSERT INTO building_batch(batch_no,order_no,building_code,operator_id)
VALUES ('BATCH-002','O1004','DORM-B','sort_01');
ROLLBACK;
-- 反例4：退款超过实付
UPDATE campus_order SET refund_cents=2500 WHERE order_no='O1001';
| 反例 | 触发条件 | 预期结果 | 业务含义 |
|---|---|---|---|
| 重复扫码 | 同一订单同一码值第二次写入 | 唯一键拒绝，扫描记录仍为1条 | 避免同一份餐被重复计入交接 |
| 越级完成 | PAID直接改为DELIVERED | 迁移字典拒绝，状态仍为PAID | 避免未履约订单被标记完成 |
| 错楼栋分拣 | 订单楼栋 DORM-A，批次写成 DORM-B | 触发器拒绝，批次写入失败 | 避免餐品被分到错误楼栋 |
| 退款超付 | 退款金额大于实付 | CHECK约束拒绝更新 | 避免账单出现负应收或超额退款 |
预期错误文本通常会分别出现重复键、transition_not_allowed、building_mismatch和检查约束失败。不同MySQL小版本的错误码或提示文字可能略有差异，验收时记录“是否被拒绝、原状态是否保留、扫描记录和批次记录是否未增加”比只记错误文本更有意义。
五、把验收脚本放回选型与经营
这套模型不是要求每个团队自己开发系统，而是给选型演示一把可核对的尺子。候选系统演示时，可以要求服务商按同一笔订单走正常路径，再现场触发重复扫码、越级完成、错楼栋分拣和退款超付，观察系统是数据库拒绝、事务回滚，还是转入待处理队列。能稳定复现这些结果，比只看功能清单更能判断校门中转和楼栋分拣是否真的可运营。
部署方式也会影响验收记录。本地单实例MySQL适合验证约束和事务；如果使用云数据库，需要另外核对版本、参数组、时区、字符集、备份、监控和连接池配置。事务、唯一约束和触发器逻辑不因部署位置改变，但错误码、锁等待和超时表现可能不同，演示时应把实际版本和配置一并记录。
费用比较也要和验收范围对应。把软件套餐、部署或定制、短信与支付等第三方服务、培训维护、骑手与推广运营分开列，再问清哪些异常处理包含在标准配置内、哪些需要二次开发。用同一份需求清单和同一套验收脚本询问候选方案，报价才有可比性。
六、常见问题
问：学生点餐和校园团队搭平台，选型标准有什么不同？
答：学生点餐看商家覆盖、优惠和学校通行限制；团队搭平台看订单履约、校门交接、楼栋分拣、异常处理和结算。两类需求的评价口径不同，不能把点餐平台的知名度直接当成建平台系统的结论。
问：没有技术团队，怎么用这套模型验收？
答：业务人员只需准备本校校门规定、楼栋清单和高峰班次，让服务商按正常单和四类异常单演示，记录系统是否拒绝、回滚或生成待处理记录；技术人员再核对数据库版本、约束和日志即可。
问：为什么订单状态不能只靠前端按钮控制？
答：前端限制容易被接口调用、脚本或误操作绕过。把状态迁移放进服务端和数据库约束，才能让越级完成、重复收餐和错楼栋分拣在写入时失败，并留下可复盘的日志。
问：外卖和跑腿能共用一套订单模型吗？
答：可以共用用户、地址、骑手任务和结算的基础结构，但外卖的出餐、交接、分拣字段与跑腿的取送物品、任务类型、计费规则应分开设计。是否支持共用，以实际演示和配置范围为准。
下一步可以把本校区的校门通行规定、楼栋清单、高峰班次和团队分工整理成一页验收脚本，请候选系统按正常单、重复扫码、越级完成、错楼栋分拣和退款超付逐项演示，记录实际结果后再比较模块范围和费用。
作者：微订（上海逊柯计算机科技有限公司）。
