任何一家正餐门店，都逃不过这样的日常：
午市高峰，后厨出菜口压了七八张单，前厅服务员刚帮三号桌写完加菜，五号桌又招手要买单。此时顾客扫桌上的码，正想下单招牌红烧肉，却发现这个菜在菜单上“消失了”。再过半小时，后厨喊“酸菜鱼没了”，服务员要挨桌去问“要不要换一个”，收银台还要处理已经下进去又做不了的退单。
传统扫码点餐软件并非没有“下架”和“售罄”功能，但大多数门店的实际使用是：售罄和下架分不清，混着用。卖完了就下架，补货了再上架，菜品档案改来改去，菜单内容频繁变动，顾客看得到的是“菜单怎么老在变”，后厨看到的是“货来了没人通知上架”，而店长看到的是“菜品状态一团乱，销售数据根本没法看”。
菜品售罄与下架，看起来只是一个小小的状态位，实际牵扯的是门店运营的效率、顾客体验的连贯性和管理后台的数据可信度。本文以一套完整的堂食扫码点餐项目为样本，拆解售罄与下架为何不能混为一谈，以及一个真正可落地的项目应如何围绕这一细节构建完整的业务闭环。
项目定位：不是“把菜单搬到手机上”，而是重构堂食协作链路
一期项目的定位很明确：服务单店堂食场景，覆盖顾客扫码点餐、后厨出餐、收银清台、店长管理的完整闭环。不做外卖、不做自取、不做会员运营，先解决一件事——让一家正餐门店在高峰时段不再靠吼、靠纸条、靠记忆来运转。
项目的使用方式很直接：顾客扫桌上码，选人数、点菜、下单、完成模拟支付；后厨在门店端更新出餐状态；收银看桌台动态、执行清台、下载桌码；店长在管理后台维护菜品、桌码和点餐设置。四个角色，三套终端，共享同一套数据，互相不越权。
这套系统的核心价值不在于“线上点餐”这个形式，而在于它把堂食场景里最容易出现分歧的环节——菜品状态、桌台状态、订单状态——全部变成了系统里的确定性数据。而这一切的起点，就是菜品档案里对“售罄”和“下架”的严格区分。
售罄与下架：两个状态，两种业务含义
许多门店管理者会问：“售罄和下架，不都是让顾客买不到吗？”从顾客角度看，确实都是“买不到”，但从门店运营角度看，两者的业务含义完全不同。
售罄（SOLD_OUT）是临时性缺货，不代表这道菜不卖了。 菜品还在菜单上，顾客还看得到，系统明确标识“售罄”，加购按钮禁用，避免顾客下单后后厨无法出餐。等食材补货到位，门店只需一键切回“上架”状态，菜单恢复，无需重新编辑菜品。售罄的菜留在菜单里，还有一个更微妙的作用：它告诉顾客“这道菜平时是有的，只是现在卖完了”，而不是“这家店不做这道菜了”，这对维护菜品心智和门店口碑至关重要。
下架（OFF）是永久性或长期性调整，代表这道菜从菜单上彻底消失。 下架后菜品不再出现在顾客菜单列表里，无需占位，不影响点餐体验。也不可被搜索到。若只是一道菜短期不想卖就下架，恢复时再上架即可，无需重建档案。
项目里将这两个状态分开处理，是为了让门店的菜单管理变得可控。如果售罄后菜单立即把菜隐藏，顾客会误以为“菜单怎么变来变去”，而门店如果不敢用售罄功能（因为一售罄就相当于下架），就会让顾客继续下单做不出来的菜，导致退单和差评。
这里的核心逻辑是：上架、售罄、下架，三个状态共同管理菜品从“可见”到“可售”的全过程。 顾客端的体验是“售罄仍可见、下架不留痕”，管理后台的操作是“状态随时切、数据不丢失”。一套状态机解决的问题，远远超出按钮本身。
从单品状态到全链路闭环：它如何串起整个项目
售罄与下架的差异化处理，不是孤立的功能点，而是整个扫码点餐项目运行逻辑的一个切面。把它放在全景里看，才能真正理解它的价值。
- 顾客端：顾客扫码进入门店主页，看到的是门店档案——店名、口号、地址、电话。进入菜单后，左侧分类导航、右侧菜品列表，有规格的菜先选规格再加购，无规格的菜直接加购。售罄菜展示售罄标识且不可加购，下架菜直接不可见。底栏购物车展示件数与合计，从下单到支付一气呵成。
- 门店端·后厨：核心是出餐看板，三列呈现待做/制作中/已完成。后厨不需要关心菜品是售罄还是下架，只需要按单出餐。门店档案在此作为顶栏摘要，展示当前店名与营业状态。一个简单的设计——打烊后不能新开台，但已开台会话可继续出餐与清台——保证了“营业状态”和“履约状态”之间的顺畅衔接。
- 门店端·收银：看板只读展示桌台状态，支持清台、桌码下载。收银不直接编辑菜品，但所有订单全量可见。
- 管理后台：这是整个闭环的“运营中枢”。分类列表可排序、可停用；菜品列表可筛选分类/状态，抽屉式维护规格、加料、价格、上下架、售罄；桌码桌台可分类管理并下载；点餐设置可配置并重置演示数据。管理后台必须能承接顾客端与门店端的全部业务，不能只做配置，这是项目设计的硬性要求。
闭环的核心在于：任何一个菜品状态的变化，都会在顾客端立即生效，在门店端智能感知，在管理后台留痕可查。 售罄不是一句“跟后厨说一声”就完了，而是系统层面的自动联动——后厨确认某道菜售罄，管理后台状态更新，顾客端立即禁用加购，订单不会产生，退单自然减少。
门店档案：菜单之外，门店数字化运营的基石
用户点开扫码点餐，第一眼看到的不是菜单，而是门店档案。项目对门店档案有四条硬性要求：首屏展示店名与一句主张；店长可在后台更新店名、口号、地址、电话；打烊后不可新开台但已开台会话可继续；门店端顶栏只读摘要。演示门店为“梧桐小馆”，口号“扫码即点 · 热菜趁热上”。
门店档案的价值常被低估。它解决的其实是三个问题：
品牌一致性问题。 菜单是门店的脸面，但门店档期更是顾客进入整个点餐流程的“第一印象”。如果门店连自己的的名字、地址、电话都不能自主维护，数字化就无从谈起。
运营权限问题。 门店档案的编辑权限属于店长，而不属于顾客端或收银端。这种分权逻辑贯穿整个系统：每个角色只用自己该用的功能，看得见的和用得着的严格分离。
经营数据安全。 项目明确要求门店首屏“禁止放今日单量、营收等经营数字”——这不是技术限制，而是产品设计的选择：扫码点餐是服务顾客的工具，不是展示门店业绩的大屏。
更深层地，门店档案与售罄/下架机制是同一套治理思想在两个维度的体现：用户看到的永远是运营者想让他们看到的，而运营者操作的能力边界是被系统明确约束的。
业务闭环的关键设计：图文一致与数据可信
售罄与下架的精细化处理，离不开一个底层前提：菜品档案本身的准确性。项目对菜品档案有一项强制要求——图文一致。菜名以照片实物为准，不允许“图是A、名是B”，分类、规格、价格、标签等字段均有规范：价格以分存储，规格如“小份/大份”“微辣/中辣”，状态在上架/下架/售罄三者间切换。封面必须是本地菜品图，禁止占位图或与菜名不符的图。
为什么这个设计如此重要？因为在绝大多数扫码点餐的失败案例里，问题从来不是功能不够多，而是菜品的图片、名称、价格与实物不一致，导致顾客点餐时有不信任感。一期直接规定演示菜的完整档案——梧桐红烧肉、酸菜鱼、宫保鸡丁、鱼香肉丝等——确保从第一天起，菜单上的每一道菜都是真实可信的。
菜品档案的可信化，是售罄与下架机制能够运作的基础。 如果一道菜本身图文不符，售罄了顾客不觉得可惜，上架了顾客不敢点，那状态切得再顺滑也无济于事。反过来，当菜品档案干净、准确、统一时，售罄是一道“令人遗憾”的提示，下架是一个“不影响信任”的调整，两者才能真正发挥价值。
技术架构与交付实践：稳定托底，而非炫技
从交付角度，这套项目的难度不在“扫码点餐”本身，而在于三端业务的一致性。一个简单的菜品状态字段，要同时影响顾客端的“可见性与可购性”、管理后台的“筛选与编辑”、门店端的“摘要展示”，甚至和桌台的开台/清台状态联动。这要求底层数据模型必须统一，业务边界必须清晰，状态流转必须精确。
例如，桌码桌台模块中，扫码后需校验桌码有效性；开台逻辑要求顾客先选人数才能进入点餐流程；订单模块需要区分堂食订单的流程状态与支付状态；出餐看板需要实时同步订单状态，且收银端进入只读模式。这些看起来“琐碎”的逻辑，恰恰是决定堂食流畅度的关键——店面运营不是一次高价购买的大屏系统，而是每个动作是否顺畅的日常。
系统的数据模型在设计阶段就预留了多门店扩展能力，但一期只服务单店。这不是能力不足，而是刻意为之的克制：先把单店堂食的每一个细节做透，再谈规模化复制。
结语：数字化菜单的“确定性”价值
回到最初的问题：售罄与下架的差别，真的那么重要吗？
对于一家日均客流过百的堂食门店，答案是显而易见的。售罄让顾客知道“这道菜值得等下一次”，下架让菜单保持简洁可信。一个状态字段的语义清晰，换来的是点单环节的确定性、后厨出餐的确定性、管理后台的数据可信度。
而确定性，恰恰是餐饮数字化最难能可贵的价值。当门店的每一次状态变更都能被系统准确承接、即时传达、留痕可查，门店的管理就从“靠经验的概率”走向“靠数据的确定”。这套项目把它拆成了一件件具体的事：菜品档案里的一张图、一个状态位、一次泾渭分明的“售罄”与“下架”。
