戴影 CMS 餐厅外卖插件安装与使用图文教程：菜单识别、加料、支付与接单

一套菜单，从门头展示到在线点餐，再到厨房接单。本文用 Miyo’s on Forest 测试站的真实运行界面，演示戴影 CMS 餐厅外卖插件与配套 Restaurant Storefront 主题的安装检查、菜单录入、分类、午晚餐及儿童餐定价、收费加料、自取配送、支付和厨房操作。

阅读前请注意：截图来自本机隔离安装站，不是效果图，也不是餐馆正式营业网站。门头是 Owner 提供的实拍；菜单来自旧版资料，价格、翻译和配送范围尚待门店核定。本文不代表 Miyo’s 已开放网上接单，也不证明每种打印机均兼容。界面中的“LOCAL TEST”“本地测试”“付款未核实”和“在线付款暂不可用”均保留原样。

图 1：真实门头先让顾客认店，再进入菜单。测试站尚未开启在线付款，不是营业接单案例。

一、安装前：分清插件、主题和支付

• 餐厅插件 official.restaurant：负责菜单、分类、餐车、取餐配送规则、厨房票与打印任务，复用官方 Commerce 的商品及订单能力。
• Restaurant Storefront 主题：负责门头、导航、语言、菜单和手机展示；换主题不应删除插件的餐车和订单。
• 官方 Commerce：负责通用订单与官方支付衔接。Stripe 等支付适配器另行安装、启用和配置，不由主题收款。

本教程对应餐厅插件和主题 1.0.0 候选版。该组合要求 Core 1.2.83+、PHP 8.3.33+、Commerce 1.0.8+；使用 Stripe 时，餐厅组合要求其修复版适配器 1.2.8+。请先检查版本，不要只看“安装成功”。

2026-10-13 的发布边界：Commerce 1.0.8 已在官方市场发布；餐厅插件、主题及 Stripe 1.2.8 的正式可下载状态仍须以官方市场实际条目为准，本文不是上架公告。本次检查未取得餐厅插件可下载的正式市场版本。不要把测试站已安装候选版理解为现在任何网站都能从市场直接下载同一组合。

餐厅插件的 Owner 确定销售规则为 USD 2,000／终身使用／每站授权，配套主题免费。终身使用不等于承诺终身更新、安装服务或售后 SLA；购买和服务条款以实际合同为准。本文不提供未经核实的购买入口。

二、安装与启用：使用官方受支持入口

1. 在 CMS 后台先导出或备份网站内容、数据库及现有扩展配置，确认备份可验证；不要直接在营业站试候选版。
2. 检查 Core、PHP 和依赖版本。先安装并启用兼容的官方 Commerce，再安装所需官方支付适配器。
3. 正式条目可用后，从后台应用市场进入餐厅插件的官方授权安装流程，按页面填写合法的本站授权信息，完成兼容性、签名与权限预检后安装。条目未提供时，申请 Owner 授权的隔离测试分发，不自行伪造授权或信任。
4. 到“扩展 → 插件管理 → 餐厅外卖 → 详情”，核对 ID 为 official.restaurant、版本正确、依赖为 official.commerce；阅读权限后启用。
5. 通过正式主题安装器安装配套 Restaurant Storefront，进入“外观 → 主题”选择并启用；先保留旧主题设置备份。
6. 侧栏出现“餐厅外卖”后，再配置门店和菜单。插件已启用但支付插件未启用或未配置时，前台仍不能收款。

不要走错入口：official.restaurant 是官方可信 PHP 插件。普通“插件管理 → 上传 ZIP”的本地插件入口不能替代官方授权安装；不能通过改名、改 Manifest、手写信任记录或关闭完整性检查解决。截图只证明隔离站中候选版已安装并启用，不是普通 ZIP 上传成功的证据。

图 2：安装后检查真实身份、版本、依赖和启用状态；支付能否使用还要另查。

三、先配置门店：地址、时区、营业、税费

进入“餐厅外卖 → 店面设置”。填写真实名称、联系电话、营业地址和门店时区；美国门店要使用所在地区的实际时区，不能用服务器时间代替。填写中英西名称和介绍时，让熟悉菜单的人核对翻译。

1. 营业：配置每天的营业时段；临时停单可设置 paused，停业可设置 closed。检查顾客页面是否显示正确状态。
2. 自取：只在门店实际支持时开启 pickup_available。配送和预约也要单独配置，不能因为有按钮就认为已能提供服务。
3. 税费：在“税费”填写门店核定的税率百分比，并明确配送费是否计税。留空表示未配置，不是免税；只有依法确认适用零税率时才明确填写 0。
4. 交易区域：按照实际商户资料设置 merchant_region 和 transaction_region。缺少必要配置时，系统会阻止结账。

当前采用未含税菜单价格、单店统一税率。菜品及收费加料计入税基，配送费按后台选择处理；系统不自动推断美国各地税务规则。已经提交的订单不会因为之后改税率而追溯改价。税率和经营规则请由门店核定，本文不是税务意见。

图 3：本机测试站的税率尚未配置，截图不是推荐税率，也不是已能付款的状态。

四、批量识别菜单：先生成草稿，再核对导入

进入“餐厅外卖 → 识别菜单”。可以上传 PDF、JPG、PNG、WebP、UTF-8 TXT 或 CSV，也可以直接粘贴菜单文字。原来的手工新增和编辑一直保留，不必依赖识别。

1. 选择文件或粘贴文字，核对币种，然后点击“识别为待审核草稿”。这一步不会创建菜品。
2. 逐行对照原菜单：粗体通常是菜名，细体可能是配料或说明，不能把说明误当另一道菜。检查分类、午餐／晚餐／儿童餐分组、价格、小数点及组合价。
3. 取消勾选误识别行；空白价格或分类要补齐。特别检查多栏、跨行、共享价格及扫描模糊处，不能把“有草稿”当成“菜单已完整识别”。
4. 勾选“我已核对”，再决定是否勾选“导入后设为可售”，最后确认导入。营业站未核定的资料应先保存停用；隔离测试站可启用明确的测试菜品，以覆盖真实点餐交互。
5. 导入后回到菜单列表检查数量和价格。同名、同分类、同分组记录会跳过，不覆盖旧人工记录；修改已有菜品仍使用编辑页。

识别草稿保存在当前登录会话中，1 小时有效。单文件不超过 10 MB，PDF 最多处理前 6 页，草稿最多 200 行；还受服务器上传限制约束。文字 PDF 需要 Poppler，图片和扫描件需要 Tesseract 及相应语言包。后台会显示实际可用能力；组件缺失时改用 TXT、CSV 或粘贴文字，不必逐道重输。

站点 AI 整理是可选项，只有明确勾选同意才发送识别文字，可能产生原有服务费用；未配置时不能使用。AI 也不能替代人工核对。下图用三行“教程测试炒饭”生成草稿，没有确认导入或上架这些示例。

图 4：把识别结果变成可修改的草稿，而不是自动上架。所有示例价格仅用于说明。

五、人工维护：分类、三语、午晚餐和 Kids 价格

“分类”和“用餐分组”是两件事。分类用于找到寿司、炒菜、头台、汤、甜品或饮品；用餐分组用于选择全天、午餐、晚餐或儿童份量。不要把所有商品堆在一个分类里。

1. 在“餐厅外卖 → 分类”编辑分类标识与中英西显示名称。保存分类会同步更新该分类下的菜品；只移动一道菜时，在菜单编辑页更改它的分类。
2. 在“餐厅外卖 → 菜单”新增，或点击现有菜品 ID 编辑。填写菜名、三语名称／说明、分类、用餐分组、该分组售价、币种、制作岗位和状态。
3. 同一道菜的午餐、晚餐和 Kids 价格不同时，分别创建对应分组记录并填写各自售价。例如教程用 9.95／14.95／6.95 USD 说明三种份量，不是 Miyo’s 的确认价。
4. 午餐是可选份量／价位，没有额外午餐限时；晚上也可选择较小份量，但仍受门店营业及实际售卖状态约束。
5. 填写搜索别名，例如“蛋花, egg drop”，并检查三种语言的搜索。没有商户翻译时保留原文，不冒充完整翻译。
6. 售完改为“售罄”，暂不展示或供应改为“停用”。上传真实菜品图片到媒体库，在“高级展示与规格设置”的展示 JSON 中配置 image_url；没有照片时保留“暂无图片”，不要用假菜图冒充实物。

首页 House Favorites 不限主菜：在对应菜品的高级展示 JSON 中设置 featured 和 featured_order，汤、甜品、饮品也可入选。修改 JSON 前保留现有内容，只调整需要的字段；不熟悉配置时请安装服务人员协助，避免覆盖已有规格。

图 5：分类内容由店家维护，前台分类导航和搜索使用同一套菜单数据。

六、额外需求：收费项目用“加”，不要食材用备注

在菜品编辑页的“加”分区点击“加”，选择米饭、鸡肉、牛肉或“其他”，填写每份加多少钱，然后保存菜品。可以添加多行、移除某行；常用项目自动提供中英西名称，“其他”的名称和翻译由店家填写。

图 6：后台输入加料价格，顾客不能自己输入价格。截图中的加价仅供测试。

顾客打开菜品窗口，选择加料、数量，并在该道菜的备注中写“不要葱”“酱汁另放”等。每道菜的备注独立保存，不会自动减价，也不是免费多加肉的替代方式；过敏和特殊制作需求必须直接联系门店确认。

计价示例：测试菜价 10.95 USD，加牛肉 4.00 USD，买两份时该行是 (10.95 + 4.00) × 2 = 29.90 USD，尚未包含税费或配送费。后台更新加价会用于之后的点餐；旧餐车须重新核对，已提交历史订单保留原价格快照。

图 7：英语界面中的收费加料和逐菜备注。语言切换不代表菜品原文已经人工翻译。

七、自取、送餐与预约：配置真实可服务范围

顾客先选择自取或配送，再选菜。店家在“店面设置”的 JSON 中维护履约规则：pickup_available 开启自取；delivery_available 开启配送时，还须明确配置 delivery_fee_minor 和 delivery_postal_codes。USD 的最小货币单位是美分，例如 300 表示 3.00 USD，不是 300 美元。示例邮编 TEST01 只用于本机验证，不能作为真实配送范围上线。

预约开启需要 preorder_available、hours、preorder_lead_minutes 和 preorder_max_days。时间按门店时区计算，预约须落在营业时段并满足提前量。预约指预订取餐／送餐时间，不是订桌功能。本机截图中未开启预约；开启后仍需单独测试可选时间和后台显示。

这部分目前仍有 JSON 配置项，不是全部都已做成独立可视化开关。修改时先备份已有 JSON，按实际营业规则合并字段，不要把教程示例覆盖到真实门店。完成后测试自取、支持邮编、不支持邮编、即时和预约等不同情况。

图 8：先核对餐车内容再进入结账；这里展示的是测试餐车，不是已付款订单。

八、支付：先沙盒验收，不只看跳转回来

1. 在官方支付插件后台配置对应测试模式凭据及 Webhook。密钥只放在支付设置中，不放进主题、菜单、文章或截图；测试和正式模式不能混用。
2. 使用有合法 HTTPS、公网可达的隔离测试站接收回调。127.0.0.1 指当前电脑，外网支付服务不能直接回调这个地址；不能因本机打开成功就认为 Webhook 能到达。
3. 用该支付服务的沙盒方式完成测试，核对 Commerce 原订单、可信支付状态、币种、菜品及加料小计、配送费、税额和总额；不要把“已创建待付款订单”当成付款成功。
4. 确认支付成功后生成厨房票，再核验付款失败、重复通知、顾客不返回网站、取消和人工退款。重复通知不得新增重复厨房票或盲目重印。
5. 全部必要链路通过并经门店批准后，才切换正式收款模式。税率、商户区域或支付服务缺失时先解决配置，不隐藏错误提示强行营业。

截图中的本机站不能用于付款验收：其 Stripe 适配器仅安装、未启用，税率也未配置，所以首页真实显示“在线付款暂不可用”。此前 takeout 沙盒曾完成测试付款和 Mac 出纸，但这是特定测试版本的历史证据，不等于当前正式组合在所有站点、所有设备已验收。

九、厨房接单、订单凭证和人工退款

打开“餐厅外卖 → 订单看板”，检查原订单号／厨房票号、取餐方式、预约时间、顾客资料和付款核实。按实际进度更新接单、制作中、已出餐和完成；未来预约票不能当即时单出餐。交餐时核对订单号或票号及必要联系信息，再核对后台真实付款状态，不能只信顾客截图。

图 9：这里只展示未核实付款的模拟测试票，不作为营业出餐或支付成功证明。

顾客在原下单设备通过“订单凭证”查看该设备持有凭证的订单。姓名、手机或邮箱不是公开查单密码；换设备或遗失凭证由门店协助。不要公开转发包含订单凭证的完整链接。

退款由店家人工办理。顾客端没有退款申请入口；有支付管理权限的管理员通过官方支付管理发起人工退款并核验支付服务结果。取消厨房票不等于退款到账，打印失败也不会自动退款。部分退款或取消后，要核对厨房票与尚未打印任务；已经出纸的单据必须人工通知厨房停单。

十、打印是可选项：没有打印机也能先用看板

没有厨房打印机，可以先用订单看板人工接单。需要自动纸票时，由授权安装人员绑定厨房、寿司台或饮料区设备，并在餐馆电脑安装本地 Print Bridge。现有设备只能通过经授权的系统打印队列或厂商接口复用；独立设备使用已验证适配器，不能仅凭“有网线口”判断兼容。

1. 先确认电脑系统能打印，再在“厨房岗位／打印机”配置岗位路由与绑定，私下设置桥凭据和本地队列。不要把打印机端口直接开放到公网，不修改 POS 数据库。
2. 管理员设置服务器订单核对计划任务，使顾客付款后不返回网站、或本地桥暂时离线时，也能继续核对并生成待打印任务。这项调度不是安装后自动完成的；未配置时不能承诺即时入队。
3. 先打一张明确标记测试的三语票，核对菜品、数量、规格、加料、备注、取餐方式和时间；再核对沙盒已付款订单的实际纸票。
4. 正常任务自动发送，不要求每单人工点击确认。后台“已发送”表示队列提交成功，不等于证明纸已出来；失败或结果不确定时查看设备和“打印任务”，核实后有原因地人工重印，不盲目自动补打。

目前有 Canon MG2500／Mac 队列的历史三语实纸证据，但不能据此承诺 Epson、Windows、现有 POS 或热敏厨房机都已认证。缺纸、断网、断电及输出中断仍要针对最终设备测试。连接营业中的打印机前须取得 Owner 明确许可。

十一、主题与手机：让顾客先认店，再认菜

站点配置 Logo 优先于门店或主题 Logo。门头在店面设置中配置 storefront_image_url、desktop_focal_point 和 mobile_focal_point；配套主题设置提供品牌色和分区等选项。上传真实招牌照片后同时检查电脑与手机，保持牌匾完整，避免严重裁切。

有资料时完善 Gallery、About 和 Visit Us，填写真实地址、电话、地图、营业时间及网站规范地址；没有资料就隐藏或明确标示缺失，不能编造照片、评价或星级。中文、English、Español 的界面选择会在同一浏览器持久保存，商户菜单翻译仍须自己核对。

图 10：浏览器 390 × 844 手机视口截图，不是实体手机认证。底部购物车方便长菜单随时结算。

用真实手机再检查：输入搜索词、切换分类与三种语言、选择份量、添加收费加料和备注、修改餐车数量、查看结账明细。没有餐厅插件时主题应优雅降级，不能伪装成可下单页面。

十二、上线前检查清单与常见问题

• 版本、合法授权、签名及依赖已核对，备份可验证；候选包不直接冒充正式稳定发布。
• 门店名称、地址、电话、时区、营业时段、菜单价格、币种、税率和配送范围已由店家确认。
• 分类、午晚餐及 Kids 定价、三语搜索、售罄、逐菜备注、收费加料和手机餐车实际可用。
• 支付成功与失败、重复回调、不返回网站、订单凭证及店家人工退款已经用正确环境验证。
• 厨房看板有人负责；需要打印时，调度、路由、真实出纸及故障兜底均已验证。
• 顾客页面没有测试邮编、未核定价格、演示订单、密钥或后台凭据；真实照片与 Local SEO 信息正确。

找不到插件或 ZIP 安装失败？检查实际市场条目、官方授权入口和兼容版本；不要改名绕过可信插件规则。菜单识别按钮失败？看服务器能力与上传上限，先改用 CSV／文本，核对草稿后再导入。只能看菜单不能付款？检查支付插件是否启用、沙盒凭据／回调、税率及交易区域，不能把缺配置当成视觉问题。有付款没有厨房票？检查可信支付状态、餐厅订单映射和核对调度，不通过手写支付状态制造成功。任务已发送但没出纸？先看系统队列、纸张和连接；结果不确定的任务须核实，避免重复出单。

资料日期：2026-10-13。本文记录特定隔离测试站的安装和使用界面，适用于餐厅 1.0.0 候选版所述能力；正式包、支付适配器、安装入口与兼容范围以官方市场和随包说明的实际状态为准。教程发布不等于产品发布门禁通过。