企业官网建设流程全解析

简介：这是一套面向餐饮企业及PHP开发者的智能餐厅点餐支付管理系统，基于Web架构，覆盖顾客扫码点餐、订单管理、微信/支付宝支付等核心环节，适合用于门店点餐效率优化与服务流程数字化改造。资源共106个文件，压缩包约1.66MB，以26个PHP程序文件为主，配合46张页面图片、16个MP3提示音频、5个XML配置及安装说明文档，并划分client、server、member三个目录，分别对应前端界面、后台逻辑与会员管理模块，便于按需检索和二次开发，已有221人学习下载。系统支持顾客扫描桌面二维码进入电子菜单，自由增减菜品并直接提交订单，支付环节可自动调用微信或支付宝接口完成快速收款，也支持扫码支付；同时附带打印控件、安装脚本和使用说明，确保厨房、收银台与后台数据同步。这套源码完整呈现了扫码点餐、在线支付、会员管理及数据联动的落地思路，既帮助餐饮经营者理解数字化点餐流程，也为PHP开发者提供了移动支付对接和Web目录分层的真实项目参考。

1. 金味智能餐厅点餐支付管理系统：把点单、出菜、结账串成一条链

晚市高峰，前台围着一圈人催点单，服务员在桌台和后厨之间来回跑，出票机吐出的小票堆成一叠，打烊对账时发现现金和系统差了八十多块，查了半小时没查到错在哪。这是很多中小餐厅每天都在上演的场面。金味智能餐厅点餐支付管理系统做的就是把这些环节串起来：顾客扫码或由服务员下单，订单直达后厨屏和出票机，支付完成后自动记账扣库存，打烊时报表直接给出今日营收。它适合以堂食为主的中小餐厅、连锁门店，也适合帮餐饮店做系统落地的服务商。5.0.715 这个版本号从命名习惯看是 5.x 主线的迭代构建，功能框架基本定型，真正花时间的环节在部署、门店初始化和菜品数据迁移。

2. 金味系统在店里到底管什么：点餐、后厨、库存的模块边界

2.1 前台点餐三入口：桌台码、服务员手持与自助机的选型逻辑

三个入口本质都是「生成一张订单」，区别在于谁在操作、在哪里操作。桌台码适合客人到店后自己扫码下单，服务员不用站在桌边等着记菜，翻台效率能上来一些；服务员手持适合正餐、聚餐，客人翻菜单讨论，服务员边听边点，菜品规格和做法当场确认；自助机适合快餐、简餐、早餐，排队的人自己在大屏上选完直接付款，省掉收银员录单这一步。

选型不能只看门店大小，要看业态和动线。我做实施时一般先问三个问题：客人有没有固定桌台、点单高峰持续多久、店里有没有专门收银员。有固定桌台的火锅、烧烤店，桌台码是主力，顾客坐下先扫码，锅底和酒水自己点，比服务员站着等快得多；快餐店则把自助机放在进门处，客人点完付款等叫号，后厨直接按单号出餐。三种入口的取舍可以参考这张表：

入口之间不是互斥关系。我一般建议有服务的正餐店主用服务员手持，桌台码做补充；快餐店反过来，自助机为主，扫码为补充。别指望一套方案通吃所有门店，配错了入口，高峰期一样排队，只是从排队点单变成排队买单。

2.2 后厨 KDS 与出票：订单怎么从前厅走到灶台

订单在收银端生成后进入订单中心，系统按门店配置把订单内容推给后厨设备。常见两种模式：KDS 厨显和打印机出票。KDS 适合菜品多、需要控单的正餐店，屏幕按热菜、凉菜、饮品分区显示，超时未做的单自动变色提醒，划菜直接在屏幕上点掉；打印机适合菜品结构简单的店，出票成本低，后厨师傅习惯看纸单，不需要额外培训。

这里有个容易忽略的点：并单和拆单。一桌加菜时，后厨不希望再出一张完整的新票，正确做法是把新增菜品合到原有订单的出票逻辑里，KDS 上显示「加菜」标识，师傅一眼知道是同桌的追加菜；外卖或自取场景则要按订单号独立拆单。我之前见过一家店上线后加菜全部重新打票，后厨灶台堆了一摞纸，就是并单策略没配好。还有一个细节是打印机端口：同一台出票机可能同时接前台小票、后厨厨房票、外卖票，每种票要绑定不同的模板和声音，不然厨师分不清哪张是要做的菜，哪张只是结账单。

2.3 库存与估清：点餐系统为什么必须碰进销存

点餐系统不只是一张电子菜单。客人下单「青椒肉丝」，系统扣的不是「青椒肉丝」这个菜品，而是它对应的原料：青椒、肉丝、调料。这需要菜品和原料有 BOM 关系，也叫物料清单。金味这类系统常见的做法是给每个菜品绑定原料配方和用量，下单自动扣减原料库存，采购入库后库存回补，月底盘点时拿账面库存和实际库存一对比，损耗和浪费就有数了。

估清是库存功能里最重要的一个：某个菜品原料卖完，系统自动把菜品标记为「估清」，菜单上对应菜品显示售罄，客人就下不了单，避免下单后厨房再退菜。维护估清有两种思路，一种是每天开业时手动设置每个菜品的可售数量，卖完自动停售；一种是由库存联动自动估清，原料扣到零就停售。我建议中小门店先用后者，省人力，但前提是原料入库和盘点数据要准，否则估清会误判——明明还有原料，系统却显示售罄，白白损失营业额。

3. 把金味 5.0 部署落地：环境准备、建店初始化与菜品迁移

3.1 部署形态：门店本地服务器还是云端托管

先讲差异。本地部署：数据库和点餐服务跑在门店内网，收银点单不依赖外网，断网也能用，但门店要有人会维护，服务器坏了影响经营；云端部署：所有门店连同一个云端环境，总部统一管理菜谱和价格，门店网络一断就抓瞎。折中方案是混合：云端做总店管理，门店本地做缓存和离线兜底，网络恢复后自动同步。

服务器配置没有绝对标准，我按门店规模给一个参考区间：

网络要求比服务器参数还重要。门店内网建议千兆交换机，收银机、后厨屏、出票机能插网线就插网线，不要全走无线。营业高峰期几十台上网设备同时在线，无线丢包只要发生一次，后厨就可能漏单，客人催菜才发现菜根本没做。

提示：餐饮系统不建议用家用路由器加 WiFi 跑正式营业，营业高峰设备一多，家用路由很容易过热丢包，换企业级路由是性价比最高的投入。

3.2 门店初始化：营业时间、桌台区域与收费项目一次配好

系统装好后第一件事不是传菜谱，是建门店。常见初始化顺序：门店基本信息、营业时间、桌台区域、收费项目、操作员账号。营业时间不只是挂在页面上好看，它影响预约、估清重置和日结时间。比如设定凌晨 2 点日结，那么 1 点 59 分的订单算前一天，2 点 01 分的订单算新一天，这个时间点一旦定下来，连锁门店必须统一，否则汇总报表口径不一致。

桌台按区域分：大厅 A 区、包间 B 区、外摆 C 区。命名规则建议「区域-桌号」，比如 A-01，因为服务员传菜、客人扫码定位、后厨叫号都靠这个名字，命名随意后期很难改。收费项目单独说一句：茶位费、餐具费、服务费这类附加费用，要在建店时配好，并选好计费方式是按人、按桌还是按单。半路再加收费项目，容易导致历史账单统计口径不一致，月底查账才发现本月报表和上个月对不上。

3.3 菜品资料迁移：把 Excel 菜品表转成系统导入 JSON

绝大多数门店的菜谱资料都在 Excel 里，手动录入几百个菜不现实。常见做法是先用系统导出一份「菜品导入模板」，然后按模板字段整理 Excel，再转换成模板对应的 JSON 导入。下面是我一般会用来转换菜品表的脚本，以 JSON 为例：

import json import pandas as pd # 读取整理好的菜品 Excel，注意列名要和模板字段对应 df = pd.read_excel("菜品表.xlsx", dtype={"code": str}) def build_dish(row): return { "code": row["code"], # 菜品编码，建议用纯数字，避免中文做 key "name": row["name"], # 菜品名称 "category": row["category"], # 一级分类，如：热菜/凉菜/饮品 "price": float(row["price"]), # 售价，单位元 "cost": float(row["cost"]) if pd.notna(row["cost"]) else 0, # 成本，用于毛利统计 "unit": row.get("unit", "份"), # 单位 "specs": row["specs"].split("|") if pd.notna(row["specs"]) else [], # 规格/做法：大份|小份|微辣|中辣 "sold_out": int(row.get("sold_out", 0)), # 1 表示初始估清/停售 "print_group": row.get("print_group", "热菜") # 后厨出票分区 } dishes = [build_dish(row) for _, row in df.iterrows()] # 按分类聚合，输出系统可导入的 JSON 结构 output = {"dishes": dishes} with open("菜品导入.json", "w", encoding="utf-8") as f: json.dump(output, f, ensure_ascii=False, indent=2)

逻辑说明：脚本把 Excel 每一行转成一个菜品对象，最后聚合成一个 JSON 数组。先转格式再导入，比在系统里逐个录入快得多，也方便后续批量改价。dtype={"code": str}是为了让菜品编码以文本形式读入，避免长数字被 Excel 转成科学计数法，这种问题在菜品编码上非常常见。

参数说明：specs字段用竖线分隔多个规格或做法，因为系统里一般要求一个菜品的多个规格属于同一条菜品记录，而不是拆成多个菜品；sold_out初始为 1 表示这个菜录入后直接停售，适合还没准备好开卖的菜品；print_group决定这个菜出票到后厨哪个区域，和 KDS 分屏对应。导入前建议用 Excel 检查一下编码有没有重复，编码重复是导入报错最常见的原因。

3.4 资料进系统后的核对：别等开业当天才发现菜单错了

导入完成不代表结束。我一般会做两件事：一是在后台预览菜单，逐个分类看是否完整、价格是否带小数位错误；二是在测试桌台实际点一单，重点看小票上打印的分类、做法、价格和后厨分区是否正确。特别注意三类菜：时价菜，比如海鲜，价格每天浮动，要设置成下单时手动改价；称重菜，按斤计价，单位不是份；下架菜，不在菜单上但历史订单还要能查。这三类菜如果在导入时没有单独处理，开业当天大概率出问题，测试单能提前暴露八成错误。

4. 支付配置与日结对账：从通道接入到异常单处理

4.1 支付通道组合：主扫、被扫、现金与储值的优先级设置

支付是餐饮系统的命门。金味系统常见的支付配置有四种：主扫支付，客人扫桌台码或收银台码，在手机上完成付款；被扫支付，收银员用扫码枪扫客人的付款码；现金支付；会员储值支付。主扫和被扫对应不同的硬件：主扫需要一张静态码或动态码，被扫需要一把扫码枪或带扫码头的收银机。

配置时要注意支付优先级：同一个订单如果客人既扫了码，收银员这边又操作了一遍，系统会按优先级选支付方式，避免重复支付。我一般建议把主扫设为默认，现金放最后。另一个必须开的配置是「部分支付」：一单可以先用储值余额付一部分，再用扫码付剩下的。很多门店会员充值送金额，客人余额不够整单时，不开部分支付就只能整单用扫码，会员余额永远花不完，储值营销就失去了意义。

4.2 日结对账：门店流水和渠道账单对不上时怎么排查

支付通道的钱不是实时进门店账户，一般是 T+1 清算。所以每天打烊要做日结：把系统里的支付流水和渠道侧的账单拉出来对一遍，核三个字段：订单号一致、金额一致、支付状态一致。

对账有一个基本原则：以渠道账单为准确认实收金额，以系统订单为准确认订单是否真实存在。两边对不齐时，常见的差异有两种：一是系统显示已支付，渠道账单没有这笔，多半是测试单或退款单没处理干净；二是渠道账单有的订单系统里查不到，可能是收银端下单后没提交成功，但支付已经完成，也就是常说的单边账。

我一般会用一段 SQL 把本地流水里状态和金额的可疑单捞出来：

-- 找出本地已支付但金额不在渠道账单范围内的订单 SELECT o.order_no, o.pay_amount, o.pay_status, o.pay_time FROM orders o LEFT JOIN channel_bill c ON o.order_no = c.order_no WHERE o.pay_status = 'paid' AND (c.order_no IS NULL OR c.amount != o.pay_amount) AND o.pay_time >= '2025-01-01';

逻辑说明：用订单号关联本地订单表和渠道账单表，找出「本地已支付但渠道没记录」或「金额不一致」的订单，这些就是要人工复核的可疑单。

参数说明：pay_status='paid'限定只看已支付订单，避免把大量未支付单也捞出来；pay_time按设定的时间范围过滤，避免全表扫描拖垮收银数据库，实际使用时换成具体的日结日期区间；如果渠道侧订单号和本地订单号不一致，说明下单和支付环节走了两套编号，要优先查接口配置。对账脚本建议每天日结后跑一次，别等月底。

4.3 退款、反结账与冲正：单边账和重复支付的处理边界

退款分三种：整单退、部分退、免单。整单退走原路退回，钱从渠道退回客人账户；部分退只退部分菜品金额；免单是门店自己承担，系统里记为营业外支出。配置时建议设置退款权限：普通收银员只能退当班次订单，店长可以退历史订单，避免离职员工乱退，也减少高峰期误操作。

单边账的补法是用渠道侧的「主动查单」接口：输入订单号向渠道查询真实支付状态，查到已支付就把系统订单补成已支付，查到未支付就保持原状。金味系统一般会在收银端提供查单补单按钮或定时任务，我建议开启定时任务模式，因为人工在高峰期根本想不起来去点，等想起来时客人已经站在收银台前面了。

5. 金味系统落地的避坑清单：断网、丢单与账实不符的排查与处理

5.1 网络一断收银就「卡死」，问题多半在部署架构

现象：门店 WiFi 断了，收银台点单转圈，后厨不出票，整个店瘫痪。这是云端部署加无线网络组合下的典型事故。

原因：系统所有请求都走公网，收银、出票、支付全部依赖外网；也有的是本地部署，但数据库服务和收银机之间走无线，信号干扰导致连接总有重连。

解决：以堂食为主的门店优先本地部署，收银机、后厨屏、出票机用网线接到同一台交换机；如果必须云端部署，至少给收银端留一个离线缓存模式，网络恢复后自动补传订单。我自己的习惯是部署时先问一句：网络断了 10 分钟，你这个店还能不能正常做菜收钱？答不上来的，都要按断网场景重新设计。

5.2 后厨打印丢单：云打印机在线却不出票

现象：收银端显示下单成功，打印机也显示在线，后厨就是没有小票，直到客人催菜才发现漏单。

原因：最常见的是打印机绑定了出货模板，但没有绑定对应门店；其次是云打印机走 WiFi，和收银端不在同一网络，重启后 IP 变了连不上；还有的是多人同时下单，打印队列丢消息。

解决：在打印机后台确认设备绑定门店和模板正确，所有出票机改用固定 IP 或同一网段；开启打印失败重发，系统检测到出票任务超时自动补打一次。血泪经验是：不要只靠「打印机在线」判断能否出票，在线只能说明设备连着网，不能说明通道是通的，上线前一定要实际下一单试打，最好在营业高峰期试。

5.3 会员储值对不上：充值流水和余额表不一致

现象：月底导出会员储值余额，发现某些会员余额是负数，或者充值赠送金额和账目对不上，客人在店里反复消费，但账怎么都平不了。

原因：并发充值，同一个会员同一秒两笔充值，余额更新互相覆盖；退款原路退回储值卡但没有生成流水；人工调账直接在余额上加减，不留任何记录。

解决：储值余额不要直接存一个数，而是由「充值流水加消费流水减退款流水」实时算出来，这样每一分钱都能追溯到流水；所有调账必须走调整单，而不是直接改余额；定期跑一遍流水汇总对比余额表，差异直接定位到单笔流水。这个其实是数据库设计问题，但很多系统为了性能把余额做成单字段，翻车率极高。

5.4 估清没维护：顾客点了菜，后厨说卖完了

现象：菜单上显示可点的菜，客人下单后厨房退菜说估清，客人体验很差，服务员还得反复道歉。

原因：估清是人工维护的，早市卖完的菜中午没人改；或者系统估清开关只控制菜单展示，没有联动库存，原料其实已经没了但菜单还亮着。

解决：启用库存联动估清，原料库存扣到 0 自动估清，补货入库后自动恢复；同时在高峰期安排专人负责估清维护，卖完的菜第一时间在手持端操作停售。还要注意估清和退菜是两回事：估清是「接单前拦住」，退菜是「接单后补救」，前者永远比后者好，等退菜发生，客人已经在催了。

5.5 支付回调丢失：用户已扣款，订单还挂在「未支付」

现象：客人手机显示付款成功，收银端订单状态还是未支付，客人堵在收银台，店长不知道是该放人走还是再收一遍钱。

原因：支付回调是渠道服务器请求门店系统的接口，回调地址配错、回调时系统正在重启、网络超时，都会导致订单状态没更新。这不是玄学，是分布式系统里最常见的消息丢失场景。

解决：开启查单补偿任务，每隔一段时间主动向渠道侧查询未支付订单的真实状态，查到已支付就自动补单；把关单时间调长，给查单补偿留足时间窗口。收银端最好保留人工查单入口，真遇到补偿任务也没处理的情况，店长手动操作后补单，同时记录操作日志方便对账。

6. 让金味系统少出问题的小习惯：数据体检、接口联动和备份

6.1 每周一次数据体检，把异常单提前捞出来

我每周一早上会花几分钟跑一段固定的 SQL，把异常订单捞出来处理，而不是等月底对账再抓狂：

-- 体检一：退款金额大于实际支付的单 SELECT order_no, pay_amount, refund_amount FROM orders WHERE refund_amount > pay_amount; -- 体检二：储值余额异常的会员 SELECT member_id, balance FROM member_account WHERE balance < 0;

逻辑说明：体检一筛选退款金额大于实付的订单，这类单要么是退款操作失误，要么是退款后又有人工改单；体检二直接查负余额会员，负余额一般来自并发冲正或调账不规范。参数说明：两个查询都用数值直接比较，金额字段在系统里以「分」为单位存储，避免浮点误差。每周花 5 分钟清掉异常单，月底会轻松很多。

6.2 用接口把会员营销和电子发票接进来

金味这类系统一般会提供对外接口，常见的是订单创建、支付成功、退款完成这类事件通知。接法有两种：一种是定时拉取，另一种是注册回调地址让系统主动推送。我建议用回调方式接会员充值送券和电子发票自动开具，客人结账完成马上触发，不需要店员手动操作。接口对接时注意幂等处理：同一事件可能推送多次，接收方要用订单号加事件类型做去重，否则一张单开两张发票，客人投诉就来了。

我这些年做餐饮系统落地，最大的教训是：上线前把数据规则想清楚，比上线后修 bug 划算得多。菜谱编码、桌台命名、估清策略、支付优先级，这些都是一次配置、长期受益的东西，值得多花半天想清楚。另一个习惯是永远留一条退路——数据库每天自动备份，至少保留最近 30 天，出问题才有的查。希望这些能帮到你，把你的餐厅或客户的门店顺利跑起来。

本文还有配套的精品资源，点击获取