PHP外卖点餐源码实战：界面美观与功能清晰的工程克制

简介这是一套面向在线餐饮行业的PHP外卖点餐源码适合中小型餐厅搭建自有订餐平台也适合PHP开发者学习完整Web项目的前后端实现。源码以PHP为核心配合MySQL存储餐厅、菜品与订单数据前端采用响应式布局适配手机、平板与桌面设备涵盖注册登录、菜单浏览、下单支付、订单追踪等完整流程并集成支付宝、微信等第三方支付接口同时包含防SQL注入、XSS攻击等安全处理。压缩包共1166个文件以412个jpg与325个gif图片资源、193个php业务脚本、83个js与53个html页面为主另有css样式、db数据库文件及docx、txt说明文档整体约5.13MB。资源内附源码说明、安装指南、系统流程图与版本更新记录便于理解目录结构与部署逻辑。目前已有1813人学习下载可作为二次开发与餐饮平台搭建的参考方案。1. 外卖点餐源码选型为什么“界面美观、功能清晰”比功能多更重要做过餐饮 SaaS 外包的同行大概都有过这种经历客户拿着一份“功能清单”来询价上面列了三十多项从会员积分到拼团秒杀一应俱全结果上线三个月日订单量还没超过两位数。问题往往不在功能少而在于界面太乱、流程太长——顾客点一份黄焖鸡米饭要点五次才能下单商家后台找个“今日订单”要翻三层菜单。PHP 外卖点餐源码这个方向真正稀缺的不是功能堆叠而是界面美观、功能清晰这八个字背后的工程克制。这篇文章面向三类人想用 PHP 快速搭一套外卖点餐系统的独立开发者、需要给中小餐饮客户交付点餐小程序/网页的外包团队、以及正在做 PHP 期末大作业带数据库的学生。我会从源码结构、数据库设计、前后端交互、下单流程、后台管理几个层面把一套“能跑起来、能交付、能维护”的 PHP 外卖点餐源码该长什么样讲清楚。不堆功能只讲落地路径和踩过的坑。2. PHP 外卖点餐源码的目录结构与数据库设计2.1 一套能交付的源码该有哪些目录市面上流传的 PHP 外卖点餐源码很多是十年前的单文件堆砌——一个 index.php 里塞了三千行HTML、PHP、SQL 混在一起。这种代码改一个按钮颜色都要翻半天更别提二次开发。我一般会按下面的结构组织waimai/ ├── public/ # Web 根目录只暴露入口 │ ├── index.php # 前台入口 │ ├── admin.php # 后台入口 │ ├── static/ │ │ ├── css/ │ │ ├── js/ │ │ └── images/ │ └── uploads/ # 菜品图片上传目录 ├── app/ │ ├── controller/ # 控制器 │ │ ├── HomeController.php │ │ ├── OrderController.php │ │ └── AdminController.php │ ├── model/ # 数据模型 │ │ ├── DishModel.php │ │ ├── OrderModel.php │ │ └── UserModel.php │ ├── view/ # 模板文件 │ │ ├── home/ │ │ ├── order/ │ │ └── admin/ │ └── config/ │ └── database.php # 数据库配置 ├── vendor/ # Composer 依赖 ├── composer.json └── .htaccess # URL 重写这个结构的好处是入口收敛在public/app/目录不可直接访问避免源码泄露。uploads/单独放图片方便做 CDN 或对象存储迁移。控制器按业务拆分订单相关的逻辑全在OrderController.php里改需求时不用满项目找代码。2.2 数据库表设计六张核心表撑起整个点餐流程外卖点餐的数据模型不复杂但字段设计直接影响后续扩展。下面是我常用的六张核心表表名用途关键字段shop店铺信息id, name, logo, address, phone, open_time, statuscategory菜品分类id, shop_id, name, sort_orderdish菜品id, category_id, name, price, image, stock, statusorder订单主表id, order_no, user_id, shop_id, total_price, status, create_timeorder_item订单明细id, order_id, dish_id, dish_name, price, quantityuser用户id, openid, nickname, phone, address建表时有两个细节容易被忽略。第一order表的order_no要加唯一索引防止并发下单时生成重复订单号。第二dish表的price用decimal(10,2)而不是float避免金额计算出现0.1 0.2 0.30000000000000004这种玄学问题。CREATE TABLE 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, total_price decimal(10,2) NOT NULL DEFAULT 0.00, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已完成 3已取消, create_time int(11) NOT NULL, PRIMARY KEY (id), UNIQUE KEY idx_order_no (order_no), KEY idx_user (user_id), KEY idx_shop_status (shop_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;status用tinyint而不是varchar查询时WHERE status 1比WHERE status paid快得多而且不容易写错。create_time用int存时间戳跨时区处理时比datetime省心。2.3 配置文件与数据库连接数据库配置单独放app/config/database.php用常量或数组返回不要硬编码在业务代码里?php // app/config/database.php return [ host 127.0.0.1, port 3306, dbname waimai, username waimai_user, password your_password, charset utf8mb4, ];连接用 PDO预处理语句防注入?php // app/model/BaseModel.php class BaseModel { protected $pdo; public function __construct() { $config require __DIR__ . /../config/database.php; $dsn mysql:host{$config[host]};port{$config[port]};dbname{$config[dbname]};charset{$config[charset]}; $this-pdo new PDO($dsn, $config[username], $config[password], [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, ]); } }PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION让 SQL 出错时抛异常而不是静默返回 false调试时能第一时间发现问题。FETCH_ASSOC返回关联数组模板里用$dish[name]比$dish[1]可读性好太多。3. 下单流程与购物车逻辑从加菜到支付的状态流转3.1 购物车存 Session 还是存数据库这是外卖点餐源码里第一个要做的选型决策。存 Session 的优点是实现简单用户不登录也能加购缺点是换设备购物车就丢了而且 Session 文件在服务器上堆积清理不及时会拖慢磁盘 IO。存数据库的优点是跨设备同步缺点是每次加菜都要写库并发高时数据库压力大。我的做法是未登录用 Session登录后合并到数据库。用户打开页面时生成一个cart_token存 Cookie加菜时先写 Session点击“去结算”时如果已登录把 Session 购物车合并进cart表之后所有操作走数据库。这样既保证了游客体验又让登录用户的数据可追溯。?php // app/controller/OrderController.php public function addToCart() { $dishId (int)$_POST[dish_id]; $quantity (int)$_POST[quantity]; if ($quantity 0) { return json_encode([code 1, msg 数量必须大于0]); } // 检查库存 $dish $this-dishModel-find($dishId); if (!$dish || $dish[status] ! 1) { return json_encode([code 1, msg 菜品已下架]); } if ($dish[stock] $quantity) { return json_encode([code 1, msg 库存不足]); } // 未登录存 Session if (empty($_SESSION[user_id])) { $_SESSION[cart][$dishId] ($_SESSION[cart][$dishId] ?? 0) $quantity; } else { // 已登录写数据库 $this-cartModel-addOrUpdate($_SESSION[user_id], $dishId, $quantity); } return json_encode([code 0, msg 已加入购物车]); }这段代码里$quantity 0的判断不能省。我见过有源码直接$_POST[quantity]入库结果用户传-1把总价算成负数下单时反而要倒找钱。库存检查也要在加购时做一次下单时再做一次防止并发超卖。3.2 订单号生成别用时间戳加随机数很多源码用date(YmdHis) . rand(1000, 9999)生成订单号并发一高就重复。更稳的做法是时间戳 用户 ID 后四位 自增序列或者直接用数据库自增 ID 加前缀。?php // app/model/OrderModel.php public function generateOrderNo($userId) { // 用 Redis 自增没有 Redis 就用数据库序列表 $seq $this-redis-incr(order_seq: . date(Ymd)); $this-redis-expire(order_seq: . date(Ymd), 86400); return date(Ymd) . str_pad($userId % 10000, 4, 0, STR_PAD_LEFT) . str_pad($seq, 6, 0, STR_PAD_LEFT); }没有 Redis 的环境可以建一张order_seq表用INSERT ... ON DUPLICATE KEY UPDATE seq seq 1拿序列。关键是订单号必须唯一否则支付回调时对不上账用户付了钱订单显示未支付这就是血泪教训。3.3 下单接口的完整流程下单是整个系统最核心的接口涉及库存扣减、订单创建、购物车清空、支付发起四个步骤。顺序不能乱?php public function createOrder() { $this-pdo-beginTransaction(); try { $userId $_SESSION[user_id]; $cartItems $this-cartModel-getByUser($userId); if (empty($cartItems)) { throw new Exception(购物车为空); } $totalPrice 0; foreach ($cartItems as $item) { // 悲观锁锁定库存行 $dish $this-dishModel-findForUpdate($item[dish_id]); if ($dish[stock] $item[quantity]) { throw new Exception(菜品 {$dish[name]} 库存不足); } // 扣库存 $this-dishModel-decreaseStock($item[dish_id], $item[quantity]); $totalPrice $dish[price] * $item[quantity]; } // 创建订单 $orderNo $this-generateOrderNo($userId); $orderId $this-orderModel-create([ order_no $orderNo, user_id $userId, shop_id $cartItems[0][shop_id], total_price $totalPrice, status 0, create_time time(), ]); // 写入订单明细 foreach ($cartItems as $item) { $this-orderItemModel-create([ order_id $orderId, dish_id $item[dish_id], dish_name $item[dish_name], price $item[price], quantity $item[quantity], ]); } // 清空购物车 $this-cartModel-clearByUser($userId); $this-pdo-commit(); return json_encode([code 0, order_no $orderNo]); } catch (Exception $e) { $this-pdo-rollBack(); return json_encode([code 1, msg $e-getMessage()]); } }findForUpdate对应SELECT ... FOR UPDATE在事务里锁住库存行防止两个用户同时买最后一份菜。事务包裹所有写操作任何一步失败全部回滚不会出现“扣了库存没生成订单”的脏数据。注意SELECT ... FOR UPDATE必须在事务内使用且索引要命中否则会锁全表。dish表的id是主键这里没问题。4. 界面美观的落地模板渲染与前端交互细节4.1 用原生 PHP 模板还是引入模板引擎PHP 外卖点餐源码的界面美观三分靠设计七分靠实现。很多源码用echo div classdish . $dish[name] . /div拼 HTML改个样式要翻遍控制器。我一般用原生 PHP 模板加输出缓冲不引入 Twig 或 Blade减少依赖?php // app/view/home/index.php !DOCTYPE html html head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title? htmlspecialchars($shop[name]) ? - 在线点餐/title link relstylesheet href/static/css/home.css /head body header classshop-header img src? htmlspecialchars($shop[logo]) ? alt店铺logo classshop-logo h1? htmlspecialchars($shop[name]) ?/h1 p classshop-info营业时间? htmlspecialchars($shop[open_time]) ?/p /header main classdish-list ?php foreach ($categories as $cat): ? section classcategory h2? htmlspecialchars($cat[name]) ?/h2 div classdish-grid ?php foreach ($cat[dishes] as $dish): ? div classdish-card>// public/static/js/home.js async function addToCart(dishId) { const btn event.target; btn.disabled true; btn.textContent 添加中...; try { const res await fetch(/index.php?corderaaddToCart, { method: POST, headers: { Content-Type: application/x-www-form-urlencoded }, body: dish_id${dishId}quantity1 }); const data await res.json(); if (data.code 0) { btn.textContent 已加入; updateCartCount(); setTimeout(() { btn.textContent 加入购物车; btn.disabled false; }, 1000); } else { alert(data.msg); btn.textContent 加入购物车; btn.disabled false; } } catch (e) { alert(网络错误请重试); btn.textContent 加入购物车; btn.disabled false; } }按钮在请求期间置灰防止用户连点造成重复加购。成功后有 1 秒的“已加入”反馈比弹窗温和。失败时恢复按钮状态不让用户卡在“添加中”。4.3 移动端适配的三个关键点外卖点餐 80% 的流量来自手机移动端适配做不好界面再美也白搭。三个必须处理的点第一viewport必须加widthdevice-width, initial-scale1否则手机上字小得看不清。第二菜品卡片用grid布局两列或三列自适应不要用固定宽度。第三底部购物车栏用position: fixed加padding-bottom: env(safe-area-inset-bottom)适配 iPhone 底部横条。/* public/static/css/home.css */ .dish-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(160px, 1fr)); gap: 12px; padding: 12px; } .cart-bar { position: fixed; bottom: 0; left: 0; right: 0; height: 56px; padding-bottom: env(safe-area-inset-bottom); background: #fff; box-shadow: 0 -2px 8px rgba(0,0,0,0.08); display: flex; align-items: center; justify-content: space-between; padding-left: 16px; padding-right: 16px; }minmax(160px, 1fr)让卡片最小 160px屏幕宽时自动多列窄时两列不用写媒体查询。5. 后台管理与常见问题排查5.1 商家后台的订单管理页后台不需要花哨但订单列表必须一眼看清状态。用颜色区分待支付黄色、已支付绿色、已完成灰色、已取消红色。查询用分页每页 20 条按create_time倒序。?php // app/controller/AdminController.php public function orderList() { $page max(1, (int)($_GET[page] ?? 1)); $pageSize 20; $offset ($page - 1) * $pageSize; $status isset($_GET[status]) ? (int)$_GET[status] : -1; $where $status 0 ? WHERE status :status : ; $params $status 0 ? [:status $status] : []; $stmt $this-pdo-prepare(SELECT * FROM order {$where} ORDER BY create_time DESC LIMIT {$offset}, {$pageSize}); $stmt-execute($params); $orders $stmt-fetchAll(); $total $this-pdo-query(SELECT COUNT(*) FROM order {$where})-fetchColumn(); include __DIR__ . /../view/admin/order_list.php; }LIMIT的$offset和$pageSize已经强制转成整数不存在注入风险。状态筛选用参数绑定不拼字符串。5.2 常见问题排查现象一下单时提示“库存不足”但后台看库存还有。原因SELECT ... FOR UPDATE没有命中索引锁了全表其他事务等待超时。解决确认dish表的id是主键findForUpdate的 SQL 是WHERE id ? FOR UPDATE。现象二支付回调后订单状态没变。原因回调地址写错或者回调参数没做签名验证被过滤了。解决在回调入口打日志记录原始POST数据对比支付平台文档的签名字段。我一般会在runtime/pay_notify.log里记file_put_contents排查完再关。现象三菜品图片上传后显示裂图。原因uploads/目录没有写权限或者open_basedir限制了访问路径。解决chmod 755 uploads/确认 PHP 配置里upload_tmp_dir和open_basedir包含上传目录。现象四手机端点击“加入购物车”没反应。原因onclickaddToCart(? $dish[id] ?)里$dish[id]输出正常但event.target在异步函数里可能指向window。解决把event作为参数传入或者用document.activeElement。现象五订单号重复导致支付回调对不上。原因用了rand()生成订单号并发时碰撞。解决换成 Redis 自增或数据库序列表订单号加唯一索引插入失败时重试。提示所有涉及金额的接口入参和出参都要用decimal处理不要用float做加减乘除。PHP 的bcadd、bcmul函数可以精确计算虽然慢一点但账不会错。6. 从能跑到好用三个提升交付质量的技巧6.1 用 Docker 打包 PHP 环境交付不再“在我电脑上能跑”外包交付最怕客户环境不一致。PHP 版本、MySQL 版本、扩展缺失任何一个都能让源码跑不起来。用 Docker Compose 把环境固化# docker-compose.yml version: 3.8 services: web: image: php:7.4-apache ports: - 8080:80 volumes: - ./:/var/www/html depends_on: - db db: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: waimai ports: - 3306:3306 volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql客户拿到源码后docker-compose up -d就能跑不用装 PHP、不用配 MySQL。init.sql里放建表语句和测试数据启动时自动导入。6.2 接口返回统一格式前端不用猜所有 AJAX 接口返回{code, msg, data}三段式。code 0成功非 0 失败。前端统一处理async function request(url, options {}) { const res await fetch(url, options); const data await res.json(); if (data.code ! 0) { alert(data.msg || 操作失败); throw new Error(data.msg); } return data.data; }这样加购、下单、查询订单都用同一个request函数不用每个接口写一遍错误处理。6.3 日志记录关键操作出问题有后悔药订单创建、支付回调、库存变更这三个操作必须打日志。不用上 ELK写文件就行?php function writeLog($type, $message) { $dir __DIR__ . /../runtime/logs/; if (!is_dir($dir)) { mkdir($dir, 0755, true); } $file $dir . $type . _ . date(Ymd) . .log; $line date(Y-m-d H:i:s) . . $message . PHP_EOL; file_put_contents($file, $line, FILE_APPEND | LOCK_EX); } // 调用 writeLog(order, 创建订单 {$orderNo}用户 {$userId}金额 {$totalPrice}); writeLog(pay, 支付回调 {$orderNo}原始数据 . json_encode($_POST));LOCK_EX防止并发写日志时内容交错。日志按天分文件不会无限膨胀。出问题时tail -f runtime/logs/order_20250101.log就能看到完整链路。我做了六年 PHP 外包最大的教训就是别在功能数量上跟客户较劲把下单流程做顺、把界面做干净、把日志打全交付质量就超过了市面上八成源码。那些花哨的拼团、秒杀、分销等日订单过百再说也不迟。希望帮到你。本文还有配套的精品资源点击获取