PHP外卖系统实战：从订单状态机到并发控制，毕业设计全攻略

又是一个外卖系统。每到毕业季，总会有一批又一批的小组把选题定在这里，然后在答辩前一个月开始问我说，学长，外卖系统怎么做才能不被老师挑毛病？

说实话，用 PHP 做外卖系统这件事，网上教程一抓一大把，但大多数都是这种路子：用户下单、商家接单、骑手配送，三个角色加一个后台，CRUD 一拼，完事。这样的系统答辩的时候确实能"跑起来"，但老师只要问一句"订单状态是怎么流转的""并发下单会不会超卖""骑手多个人同时抢单怎么办"，基本就卡住了。

这篇文章我想讲讲，从一个真实完成的小组项目出发，怎么把一个 PHP 外卖系统从"能跑"做到"能讲"。技术栈用的是 ThinkPHP 3.2.3，没错，就是这个老框架。你可能会觉得它旧，但毕设场景下它资料多、上手快、出活稳定，而且核心设计思路——订单状态机、数据库表结构、角色权限、实时性方案——放到任何框架里都是通用的。项目涵盖了用户端小程序/H5、骑手端、后台管理系统三个终端，走的是 B2C 订餐平台的完整闭环。我把中间踩过的坑、总结的经验、答辩前补的知识点全部理一遍，给正在做类似题目的同学一个可以直接参考的路线图。

1. 选型期先做的事：把订单流转图画清楚

很多小组拿到"外卖系统"这个题目，第一反应是打开编辑器开始建表。千万别急。我在这个项目里最先做的是一张草图，一张画在纸上的订单状态流转图。这张图决定了后面所有的数据库设计、接口设计、代码结构，甚至决定了小组成员之间的分工方式。

1.1 外卖和电商的本质区别：状态流转是主战场

为什么我强调先画状态图？因为外卖系统和一个普通电商系统的差别，恰恰不在"下单"这个动作上，而在"下单之后"。

普通电商的状态很简单：生成订单、付款、发货、确认收货，中间几乎没有实时协作的需求。但外卖系统里，一个订单从产生到完成，要经过用户、商家、骑手三个角色的接力。用户下单之后，商家要确认接单；商家出餐之后，骑手要去取；骑手取到餐之后，要送到用户手里；用户可能中途取消，商家可能超时未接单，骑手可能配送超时，这个订单还得有兜底机制。这一连串的动作，全靠"状态"这个字段在驱动。

如果项目一开始没把状态流转设计清楚，后面百分之百会出问题——最常见的例子就是：用户取消了订单，但商家那边还在备餐；或者骑手已经取了餐，但用户端还显示"商家制作中"。

1.2 最终落地的订单状态定义

我们这个项目最终定义的订单状态是这样的：

这个状态定义看起来不复杂，但里面有两个细节值得展开。

第一个细节是 -2 退款中 和 -3 退款完成。很多毕设项目会在"取消订单"这里偷懒，直接把状态改成已取消就完事。但实际上，支付后的取消往往涉及退款流程，而退款是需要时间处理的，所以必须有"退款中"这个中间状态。我们当时是用了一个 refund_status 字段配合订单主状态来处理的，订单状态进入已取消后，再根据退款状态判断是全额退款还是部分退款。这样能回答老师"取消订单的资金怎么处理"这个问题。

第二个细节是状态流转图中必须标清楚"哪些状态可以到哪些状态"。比如：

• 待支付 → 待接单（支付成功）
• 待支付 → 已取消（用户取消或超时）
• 待接单 → 待取餐（商家接单）
• 待接单 → 已取消（商家拒单，或用户申请取消且商家同意）
• 待取餐 → 配送中（骑手取餐）
• 配送中 → 已完成（骑手送达）

这些流转关系，在代码里就应该被限定死。我们是用一个状态流转映射表来做的，合法流转才能通过，非法流转直接抛异常。这个设计在答辩的时候非常加分，因为它是从"系统会不会出错"的角度去考虑的，而不是"功能有没有实现"。

1.3 先画图再写代码，到底省了什么

这个状态图画完之后，我们做了几件事：

第一，把所有相关的数据库操作列出来。每个状态变化背后，需要更新哪些字段、记录哪些日志、通知哪个角色，全部列出来。第二，把所有页面和接口按状态变化来划分。用户端的订单列表、商家端的订单操作、骑手端的接单按钮，本质上都是状态迁移的触发点。第三，把一些超时的逻辑提前想好。比如支付超时、商家接单超时，用什么机制去触发状态变化。

这一套流程走下来，后面的编码其实就变成了"翻译"的过程。我见过太多小组写到一半推翻重来的，绝大多数原因都是没想清楚状态流转就动手，结果写到后面发现有业务流程串不上。

2. 数据库设计实战：六张核心表怎么建才经得起追问

数据库设计是答辩时老师一定会追问的地方，也是最容易暴露"你是真做过还是照着网上代码拼的"的地方。我先把我们最终敲定的核心表结构给你拆开讲，再说几个被追问过、也设计对了的细节。

2.1 核心表一览：不只是"用户+商品+订单"三件套

很多教程里的外卖系统只有三张表：用户表、商品表、订单表。我们实际做的时候扩展到了十几张表，其中起决定性作用的是下面六张：

用户表 user

sql复制CREATE TABLE `user` (
  `user_id` int(11) NOT NULL AUTO_INCREMENT,
  `openid` varchar(64) DEFAULT NULL COMMENT '小程序openid',
  `username` varchar(50) NOT NULL,
  `password` varchar(255) NOT NULL COMMENT 'password_hash',
  `phone` varchar(20) DEFAULT NULL,
  `avatar` varchar(255) DEFAULT NULL,
  `status` tinyint(1) NOT NULL DEFAULT '1',
  `create_time` int(11) NOT NULL,
  PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

商家表 shop

sql复制CREATE TABLE `shop` (
  `shop_id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL COMMENT '店主账号ID',
  `shop_name` varchar(100) NOT NULL,
  `category` varchar(50) DEFAULT NULL,
  `address` varchar(255) NOT NULL,
  `latitude` decimal(10,6) NOT NULL,
  `longitude` decimal(10,6) NOT NULL,
  `license` varchar(255) DEFAULT NULL COMMENT '营业执照图片',
  `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0待审核 1营业中 2停业',
  PRIMARY KEY (`shop_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

商品表 product：核心字段是 shop_id（所属商家）、name、image、price、stock、sales、status（上架/下架）。

订单表 order

sql复制CREATE TABLE `order` (
  `order_id` int(11) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单号',
  `user_id` int(11) NOT NULL,
  `shop_id` int(11) NOT NULL,
  `rider_id` int(11) DEFAULT NULL COMMENT '接单骑手',
  `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '订单状态',
  `total_amount` decimal(10,2) NOT NULL COMMENT '总价',
  `pay_amount` decimal(10,2) NOT NULL COMMENT '实付',
  `discount_amount` decimal(10,2) NOT NULL DEFAULT '0.00',
  `receiver_name` varchar(50) NOT NULL,
  `receiver_phone` varchar(20) NOT NULL,
  `receiver_address` varchar(255) NOT NULL COMMENT '收货地址快照',
  `remark` varchar(255) DEFAULT NULL,
  `create_time` int(11) NOT NULL,
  `pay_time` int(11) DEFAULT NULL,
  `accept_time` int(11) DEFAULT NULL,
  `pickup_time` int(11) DEFAULT NULL,
  `finish_time` int(11) DEFAULT NULL,
  `cancel_time` int(11) DEFAULT NULL,
  PRIMARY KEY (`order_id`),
  KEY `idx_status` (`status`),
  KEY `idx_user_create` (`user_id`, `create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单明细表 order_detail：记录每个订单包含哪些商品、商品的名称和价格、数量、小计。这里有一个关键点——明细表里存的必须是"下单那一刻"的商品名称和价格快照，不能是外键关联到商品表实时查。为什么？因为商家可能改价、可能改名、可能下架商品。如果订单明细用外键关联实时查，历史订单的价格和名称都会变，这就有问题了。

骑手表 rider：核心字段是 user_id（关联用户表的账号）、real_name、phone、status（休息/接单中）、latitude、longitude。我们没把骑手单独做成一种用户类型，而是用用户表 + 角色字段来区分，然后骑手补充信息放到了 rider 表。这种设计在答辩时被老师确认过，说思路是正常的。

2.2 几个被追过问的字段设计

第一个是金额字段类型。价格我用的 DECIMAL(10,2)，不是 FLOAT。这个一定要记住，FLOAT 会有精度问题，比如 0.1 + 0.2 算出 0.30000000000000004，金额算错是大事。用 DECIMAL 从数据库层面就规避了。

第二个是地址快照。下单时把收货人、手机号、地址原样复制到订单表里。这样用户之后修改默认地址，历史订单的收货信息不受影响。很多同学在这里用外键关联地址表，一旦用户改了地址，历史订单显示也变了，这个逻辑上是错的。

第三个是订单号生成。我们用的不是自增 ID，而是 date('YmdHis') . rand(1000, 9999) 拼接的字符串，同时加了唯一索引。自增 ID 在订单场景里会泄露订单量，而且多终端生成订单时不好保证唯一，所以单独设计订单号是更稳妥的。

第四个是经纬度字段。用 DECIMAL(10,6)，精度足够到米级。这里要说一下，我们项目里经纬度有实际作用：下单时计算用户和商家的距离来预估配送费，骑手端展示"距离商家多远"。毕设阶段用 MySQL 直接算距离就行，用球面距离公式 6371 * acos(cos(radians(纬度)) * cos(...) ) 这种，数据量小跑起来没问题。

2.3 索引设计：不是所有字段都要加索引

很多同学的建表语句里，能加索引的字段全加上了，这其实不是好事。我们当时的做法是只给高频查询字段建索引：

• order 表的 status 单独索引——订单列表页按状态筛选是最高频的操作
• order 表的 user_id + create_time 联合索引——用户历史订单查询，按时间倒序
• order 表的 rider_id + status 联合索引——骑手端查"我的待取送订单"
• product 表的 shop_id + status 联合索引——商家的在售商品列表

索引这事儿答辩老师也喜欢问。被问"为什么建联合索引不建两个单独索引"时，可以答：联合索引能同时过滤两个字段的条件，比两个单列索引分别过滤再合并要高效。这个点能答上来，基本就是真写过的水平。

3. 后台管理系统：从 CRUD 页面升级成业务控制台

后台管理系统是毕设评分里的一个重要部分，但我发现一个很普遍的问题：很多小组把后台做成了一个纯粹的"增删改查页面堆砌"，就是每个表建一个列表页、一个编辑页、一个删除按钮，完事。但真正的后台管理系统，不应该只是数据库的图形化工具，它的定位应该是"业务控制台"。

3.1 后台的功能边界：别把每个表都做成一个页面

我们做后台的时候先列了一个问题清单：这个平台运营起来，后台的人每天要干什么？

答案是四类事情。第一，审核商家入驻申请，包括查看营业执照图片、设置商家营业状态。第二，处理用户/商家/骑手三方的纠纷，比如用户退款申请、骑手配送异常。第三，管理所有的基础数据，包括商品分类、公告、优惠券。第四，看数据，比如每日订单量、销售额、各商家的表现。

基于这个清单，我们后台最终做了五个模块：商家管理、订单管理、骑手管理、用户管理、数据统计。每个模块的功能不是把所有表的字段都暴露出来，而是"业务上需要什么就放什么"。比如商家管理页，重点是审核、启用/停用、查看该商家的订单数据，而不是去看商家的密码或 ID。

3.2 RBAC 权限模型：ThinkPHP 3.2.3 里的落地方式

后台不可能只有一个管理员。小组开发时的分工是：有人负责商家审核，有人负责骑手管理，有人只看数据。如果不做权限控制，所有人都能看到所有菜单，这在答辩的时候会被问"你们怎么控制不同管理员的操作范围"。

我们用了 RBAC（基于角色的权限控制）模型，建了五张表：

• admin（管理员表）：admin_id, username, password, status
• role（角色表）：role_id, role_name, remark
• permission（权限表）：permission_id, permission_name, module, controller, action
• admin_role（管理员角色关联表）
• role_permission（角色权限关联表）

在 ThinkPHP 3.2.3 里，我们是在后台的 BaseController 里面做了登录态校验和权限校验。每个后台控制器继承 BaseController，然后声明 public $needAuth = true; 表示需要登录，再配置当前控制器的标识符，比如 Admin/Shop/index。用一个公共方法去查当前角色的权限集合，判断是否有权限访问。没权限就跳转到无权限提示页。

这样做的好处是权限控制和业务代码完全分离。新加一个后台页面时，只需要在权限表里加一条记录，然后分配给对应角色即可，不用改一行业务代码。

3.3 后台 UI 选型：Bootstrap 模板还是 Vue3？

热词里提到了 vue3 后台管理系统，这里我多说一句。我们当时后台用的是基于 Bootstrap 的 AdminLTE 模板，配合 ThinkPHP 模板引擎直接渲染。原因很简单：快，而且开发过程中能减少一个团队成员的沟通成本。做后台管理的本质是业务逻辑，不是页面的花哨程度。

如果你的小组里有人对 Vue 特别熟，用 Vue3 + Element Plus 做一个前后端分离的后台也完全没问题，但要注意工作量会明显增加：接口要写一套 JSON 返回，前端要写一套列表组件和表单组件，还要处理登录态、路由守卫。对于毕设来说，我更推荐先用 Bootstrap 模板把后台的功能做完、做完整，如果还有富余时间再考虑升级前端框架。功能和逻辑的完整性永远大于技术栈的新旧。

3.4 后台最容易漏掉的两个业务功能

这里重点说一下我们踩过坑、也是答辩被问到的两个功能。

第一个是"订单干预"。线上跑着的订单不一定永远按正常流程走，比如骑手接错单了、奶茶洒了、用户和商家协商退款了。后台必须有一个订单干预的入口，管理员可以把一个订单的状态强制改到另一个合法状态，并且留下操作日志。我们当时加了一个"订单状态修正"功能，改状态时必须填写原因，每次修改都会通过日志函数记录管理员 ID、原状态、新状态、原因和时间。这个功能看起来不起眼，但它是"系统具备运营兜底能力"的证据。

第二个是"商家结算"。外卖平台的商业模式是抽成，用户付的钱不是直接全部进商家的口袋，平台要按比例抽成后再结算给商家。我们做了一个简单的结算模块：每天凌晨跑一个脚本，算出前一天每个商家的订单总金额、平台抽成、应结金额，生成结算记录。商家可以看自己的结算单。这个功能一下子把系统的完整度拉高了，因为大部分毕设外卖系统都没有"账"的概念，只有"单"的概念。

4. 骑手端开发：实时性需求下的三个隐藏难点

骑手端是整个项目里最容易让小组翻车的部分。从功能上看，骑手端要做的页面不多：待接单列表、我的订单、配送操作（取餐、送达）。但真的写起来你会发现，它的难点不在页面，而在"实时性"——系统的状态一直在被别人改变，骑手页面怎么同步？

4.1 骑手端定位：不是做配送，是做状态回传

在开始设计之前我们明确了一件事：毕设的骑手端不需要真实的 GPS 轨迹追踪，也不需要路径规划算法，那些是美团饿了么的核心技术。我们要做的是一个"状态回传终端"——骑手通过手机告诉系统：我看到了哪些单、我要抢哪一单、我取到餐了、我送达了。

这个定位很重要。很多小组在骑手端上花了好几个星期做轨迹绘制，结果核心业务没时间做完，最后只能靠演示视频"造假"。你要先想清楚，外卖系统答辩时，老师关心的是整个订单流的闭合，而不是骑手的行驶轨迹精不精确。

4.2 抢单逻辑：用一条 UPDATE 解决并发问题

骑手端最核心的业务场景是抢单。一个订单推送给骑手端之后，可能同时有十几个骑手在刷新列表，都看到了这个单，都点了"抢单"按钮。如果代码这样写：

php复制// 先查订单状态
$order = M('order')->where(['order_id' => $orderId, 'status' => 1])->find();
if ($order) {
    // 再把订单指派给当前骑手
    M('order')->where(['order_id' => $orderId])->save(['rider_id' => $riderId, 'status' => 2]);
}

那并发场景下一定会出问题：两个人同时查到订单是待接单状态，然后都执行了 save，最后这个订单被指派给了后写的那个骑手，但前一个骑手页面上也显示"抢单成功"。这就是典型的超卖问题。

正确做法是把两步合成一条 UPDATE 语句：

php复制$result = M('order')->where([
    'order_id' => $orderId,
    'status' => 1,
    'rider_id' => 0
])->save([
    'rider_id' => $riderId,
    'status' => 2
]);
if ($result) {
    // 抢单成功
} else {
    // 订单已被别人抢走
}

这里面的关键点是 where 条件里带了 status = 1 和 rider_id = 0。MySQL 执行 UPDATE 时会对匹配的行加锁，两个并发请求同时执行时，只有一个能影响行数返回 1，另一个影响行数为 0。这就从数据库层面杜绝了重复抢单。这个细节我强烈建议在做骑手端时优先写进去，因为它是真正的"分布式一致性"问题在单体应用里的解法，答辩老师听到这里会点头的。

4.3 状态同步方案：轮询比 WebSocket 更靠谱

骑手端需要实时感知订单状态变化——商家出餐了、订单被取消了、有新的待抢订单了。毕设里做实时同步，有两种方案：轮询和 WebSocket。

轮询就是前端每隔 N 秒调一次接口，把最新状态拉回来。WebSocket 是长连接，服务器主动推送。

我们的最终方案是：用户端和骑手端用轮询，后台用"操作后主动刷新"。轮询间隔设成 5 秒，也就是说骑手端每 5 秒请求一次接口查最新订单。为什么不用 WebSocket？因为 ThinkPHP 3.2.3 时代，PHP 跑长连接要么依赖 Swoole，要么单独起一个 Node 服务，部署复杂度一下子翻倍。对一个日活个位数的毕设系统来说，5 秒轮询完全够用，而且实现简单、不容易出 bug。

如果答辩时老师问"为什么不用 WebSocket 或者长连接"，你可以这样答：轮询在低并发场景下足够满足实时性要求，实现和维护成本最低；但接口设计上预留了升级空间——比如把订单查询接口的返回数据设计成增量式的，后续要迁移到长连接，前端只需把"定时主动请求"换成"接收服务端推送"，业务代码改动很小。这个回答既有权衡，又有远见。

4.4 骑手端的载体：小程序还是 H5？

骑手端我们用的小程序，用户端是 H5 嵌入微信公众账号里的，为什么这么分？不是因为技术偏好，而是因为省事。用户端 H5 可以用传统网页开发的思路快速实现，免去小程序审核；骑手端小程序则是因为它在多点位刷新和后台运行上体验更好。说实话，如果时间有限，两端都用 H5 也完全没问题，毕竟核心逻辑都在后端，前端只是展示。

4.5 定位功能：怎么算配送距离和配送费

骑手端展示"你离商家还有多远"时，我们不是用真实的高德导航，而是根据数据库里的经纬度计算直线距离。PHP 里封装了一个方法：

php复制function distance($lat1, $lng1, $lat2, $lng2) {
    $radLat1 = deg2rad($lat1);
    $radLat2 = deg2rad($lat2);
    $a = $radLat1 - $radLat2;
    $b = deg2rad($lng1) - deg2rad($lng2);
    $s = 2 * asin(sqrt(pow(sin($a / 2), 2) + cos($radLat1) * cos($radLat2) * pow(sin($b / 2), 2)));
    return $s * 6371; // 地球半径（km）
}

配送费就基于这个距离算：起步价 3 元，超过 2 公里每公里加 1 元，封顶 10 元。这个公式写死在配置项里，后台可以改参数。

要特别提醒的是，前端拿到的用户经纬度，是通过微信公众号的 JS-SDK 获取的，这需要在公众号后台配置 JS 接口安全域名，而且用户必须微信授权登录才能拿到。这个环节出问题的话，订单无法计算配送费，整个流程就走不通。好的做法是：前端获取定位失败时，默认给出一个兜底坐标，并提示手动输入地址，不要让整个下单流程卡死。

5. 小组协作开发：接口约定先于代码，封版机制避免合并地狱

这个项目是小组开发的，小组协作如果搞不好，代码合并就是灾难。我们的团队是三个人：一个做用户端和商家端，一个做骑手端，一个做后台管理系统和数据库。三个人开发的是同一个系统的不同页面，但操作的是同一批数据表，所以协调问题特别重要。

5.1 分工按业务闭环切，不按技术难度切

我们一开始也试过按技术分：一个人写前端页面，一个人写 PHP 后端，一个人测 bug。结果发现不行，因为做前端的人不懂数据结构，做后端的人又得反复确认页面字段，沟通成本极高。

后来改为按业务模块分：用户端 + 商家端是一块，骑手端是一块，后台管理系统是一块。每个模块由一个人负责到底，从头到尾包括接口、页面、逻辑、测试。这样的好处是每个人对自己负责的模块有完整的理解，答辩的时候能讲清楚每一行代码为什么这样写。数据库表结构是三个人一起设计的，设计完锁定，不允许任何人私下改表。

5.2 接口文档先行：不然后端要返工，前端要等着

我们做了开发中最关键的一步，三个人先花了一天时间，把接口文档定下来。文档里写清楚每个接口的 URL、请求方法、参数、返回格式、错误码。这份文档是共享的，放在一个在线文档里，谁改必须通知所有人。

举个例子，订单详情接口是这样定义的：

这个文档的价值在联调的时候充分体现出来了：前端不用等后端写完接口才开始，可以直接按文档里的返回 mock 数据；后端写完接口对照文档检查有没有漏字段。两个人不需要反复地问"你这个接口返回什么"，极大地避免了返工。

5.3 Git 分支管理和"封版"

Git 我们用了，而且是强制流程：开发都在各自的分支上进行，合并到主分支时必须先提交 Pull Request，由另一个成员检查。就算只是改一个变量名，也要走这个流程。这个规矩看着繁琐，但可以避免很多低级错误。

"封版"是联调阶段的一个机制：进入联调期之后，每周一和周四固定两次合并代码，其他时间不允许往主分支合并新功能，只准改 bug。原因是三个人并行开发的话，频繁合并会互相踩到，上一个版本还没测完，下一个版本又变了，问题就不知道是谁引起的。封版机制保证每个人拿到的代码是相对稳定的，改出来的 bug 也能快速定位归属。

5.4 最容易被拖垮的检查点：数据库变更

三个人做同一个系统，最怕的就是有人偷偷改了表结构。我们立了一个死规矩：数据库结构不允许任何人在开发过程中直接改，需要改的时候必须提出来，由负责数据库的人统一评估后修改，并在群公告里同步变更记录。同步的方式很简单，就是一份 upgrade.sql 文件，每次变更往里面追加 ALTER 语句。

这个规矩听起来很笨，但确实救过我们一次。有一回骑手端想加一个"骑手接单数"字段，直接在自己的分支里把 rider 表加了字段，结果和后台管理端的分支合并时，直接导致整个 rider 表字段结构冲突，花了大半天才理清楚。从那之后，数据库变更统一走流程，再也没有出过类似问题。

6. 答辩安全线：这六个问题答不上来，系统再炫也白搭

最后说一下自查阶段。系统已经能跑了，但能不能过答辩，看的不是代码量，而是你对系统"为什么这么设计"能不能给出合理答案。这一章节是血泪教训，建议逐一对照检查。

6.1 安全问题，至少要做对这三件事

第一，SQL 注入。ThinkPHP 3.2.3 的 M() 模型自带参数绑定，你用官方推荐的写法，比如 where(['user_id' => $id])，参数是被框架转义的。但如果你图省事用了字符串拼接查询，那就等于给攻击者开了后门。自查方法是搜索代码里有没有 where 里直接拼变量的地方，比如 where("user_id = " . $id)，有就是高风险。

第二，密码存储。用户表里的 password 字段，我们用 password_hash() 生成哈希，验证的时候用 password_verify() 比对。明文密码和简单 MD5 这两种情况都是答辩减分项，面试官必问密码安全问题。

第三，越权防护。最典型的越权是：用户 A 登录后，把订单 ID 改成订单 B，直接查看 B 的订单信息。我们的处理方式是，在查询订单详情时强制带上 user_id 条件，比如用户端查订单永远是 where(['order_id' => $id, 'user_id' => $this->uid])，这样就保证只能查自己的订单。同样，商家操作商品时也必须强制带 shop_id 条件，骑手操作订单时必须强制带 rider_id 条件。

6.2 业务追问：老师最爱问的六个问题

这里把我们在预答辩和正式答辩时被问到的、以及听别的组被问到的问题整理出来，每个都要能讲出一套完整的逻辑。

问题一：支付流程是怎么实现的？

我们接的是微信支付的模拟接口，不是在真实的商户平台注册的。前端调用统一下单接口后，后端生成一个模拟支付页面，点"确认支付"后模拟回调，把订单状态从待支付改成待接单，同时记录支付流水表。答辩时的说法是：业务逻辑和真实微信支付完全一致，只是支付网关换成了模拟实现，上线时只需要替换成微信官方 SDK 即可。

问题二：超时未支付的订单怎么处理？

我们的方案是"懒扫描 + 定时任务"结合。下单时记录 create_time 和 expire_time（15 分钟）。任何一次查询订单时，如果发现订单处于待支付且已超时，就顺手把它改成已取消并释放库存（延迟关闭）。另外用一个 Linux 定时任务每小时全表扫描一次超时未支付订单做兜底。这个设计在你不需要引入消息队列的前提下，把"超时关单"这个常见业务解释得比较清楚。

问题三：商家一直不接单，用户怎么办？

我们会做超时提醒。等待接单超过 10 分钟，用户端可以再次申请取消；后台管理员也会在订单管理页看到"接单超时"的标识，可以手动干预。这个逻辑结合了用户自助和管理员兜底两重保障。

问题四：库存是怎么控制的？

商品表里有一个 stock 字段。用户下单时，用类似抢单的乐观锁方式更新库存：UPDATE product SET stock = stock - 1 WHERE product_id = ? AND stock > 0。如果影响行数为 0，说明库存不足，下单失败。这能回答"并发下单时商品会不会超卖"的问题。

问题五：历史订单的商家名称和价格变了怎么办？

这就回到前面说的"快照"设计。订单明细表存了商品名称和价格快照，订单表存了收货地址快照。即使商家改价、改名、用户改地址，历史订单不受任何影响。

问题六：骑手抢单并发问题怎么解决的？

一条 UPDATE 语句加 where 条件，见上文 4.2 节。推荐直接给老师演示代码，比讲逻辑更直观。

6.3 一份加分的安全自查清单

最后给你一份我们答辩前一个晚上过了一遍的清单，每个项目打勾了才放心去睡：

• 后台所有密码明文 / 可逆加密？——必须改为 password_hash()
• 前端页面提交的数据，后端有没有做字段验证？——不能只靠前端 required 属性
• 管理员登录的 Session 有没有设置过期时间？——有，2 小时自动退出
• 后台的增删改操作有没有日志表？——有，记录操作人、时间、IP、操作内容
• 线上环境 debug 模式有没有关掉？——关掉了，不会暴露 SQL 语句和报错信息

这些点不需要做到完美，但至少每一项都要知道为什么需要、当前是怎么做的。就算某些项只是最简实现，也能让老师认可你具备基本的安全意识。

项目收尾时我有一个很深的体会：做一个外卖系统，真正难的其实不是框架怎么用、页面怎么写，而是你能不能把一条完整业务链上的每一个环节都讲清楚。从订单状态机、数据库快照、并发控制、权限模型到小组协作规范，这些在设计阶段多想一层、写代码时多写一行，答辩的时候就会少一分慌乱。把这个思路走通之后，你会发现不仅这个项目稳了，以后做其他系统的架构设计也有底了。