企业官网建设流程全解析

基于微信小程序的咖啡店点餐系统的设计与实践

我想起每次去咖啡店排队的场景：早高峰柜台前排着长队，点单员一边听用户说"大杯热拿铁、少糖、加一份浓缩、打包带走"，一边在收银机上翻找商品，后面的人不停抬手看表。这种混乱感，其实是点餐系统最典型的落点——一个能让用户扫小程序自助下单、到店直接取餐的方案，就能把柜台从"点单+收银+出杯"的多重压力里解放出来。这篇文章就围绕"基于微信小程序的咖啡店点餐系统"来写，我会把整个项目的需求分析、架构设计、核心功能落地的过程完整拆开，包括登录链路、商品规格组合、购物车与订单流转、后台管理，以及开发中真正踩过的坑。无论你是准备给自己店里做一套系统，还是想拿小程序练手做毕业设计或作品集，这篇都值得收藏。

1. 咖啡店点餐系统的需求锚点：排队痛点与小程序切入

1.1 咖啡店场景和普通餐饮点单有什么不一样

很多人以为点餐系统就是"商品列表 + 购物车 + 订单"，复制一套外卖模板就能上。但咖啡店这个场景有几个特殊点，直接影响系统设计：

• 商品定制维度多。一杯咖啡不是选完就结束，还有杯型（中杯/大杯/超大杯）、温度（热/冰/去冰）、糖度（正常/少糖/无糖）、奶品（全脂/燕麦奶）和加料（浓缩/糖浆/奶油）。这些组合不是简单的一个SKU字段能搞定的，而是"规格选项的自由组合"。
• 高峰期高度集中。咖啡店的订单峰值非常明确：工作日早上 8 点到 10 点、下午 14 点到 17 点。这两个时段里柜台同时要应对点单、支付、制作、叫号，人手稍不够就开始排队。系统必须能把"点选 + 支付"从前台分流出去。
• 堂食与自提并存。咖啡店不像正餐店有固定的桌台，很多客人是"到店取走"，也有部分在店里坐。所以订单状态里必须有"自提码/取餐号"概念，而且要支持备注"到店喝"和"打包带走"。
• 复购率天然高。喝咖啡是高频行为，用户可能一周来三四次，这意味着"历史订单再来一单""收藏常用规格"这类功能价值很高，不只是锦上添花。

基于这些特点，我把系统的核心目标定成：用户在小程序端以最少步骤完成"选规格 → 加购物车 → 下单支付 → 到店凭取餐号取餐"的闭环，商家在管理端完成商品维护、订单状态变更和基础经营统计。

1.2 为什么选微信小程序而不是原生App或H5

这个选择我是在需求阶段反复对比过的。一开始我考虑过直接做H5，套壳进公众号菜单；也考虑过原生App。但最后确定用微信小程序，理由非常实际：

• 获客成本极低。小程序扫码即用、无需下载安装。咖啡店柜台放一个桌贴二维码，顾客扫码就直接进入点餐页，这个动作比"打开应用市场下载App"轻太多。
• 用户身份天然打通。微信生态里wx.login()可以直接拿到登录凭证，后端换取openid，不需要用户注册手机号、设置密码。对于只想快点买到咖啡的用户，"免登录点餐"是非常重要的体验。
• 有取餐通知能力。微信小程序的订阅消息可以在订单备餐完成时给用户推送一条"您的拿铁已做好"的通知，这个能力在 H5 里几乎做不到，App 里则要维护推送通道，成本天差地别。
• 同领域课题的参考价值。市面上"食堂订餐""家政服务"的小程序方案不少，但食堂是固定套餐模式，家政是预约服务模式，咖啡店这种"高定制化商品 + 即时取餐"的组合，和它们都不是一回事。这也是我最终决定自己做一套设计，而不是直接套用某种现成模板的原因。

下表是我当时做的技术选型对比：

1.3 项目范围界定

一个完整的点餐系统要划清楚哪些做、哪些不做，否则很容易在功能堆叠里失控。我的第一版范围如下：

• 用户端小程序：商品浏览与分类、规格选择、购物车、下单支付、订单列表与详情、取餐号展示。
• 商家管理端：商品上下架与改价、库存编辑、订单状态处理（接单/备餐/出餐）、简单的营业统计。
• 非第一版范围：会员储值、优惠券营销、多门店切换、外送骑手配送。这些等在核心闭环跑通后再加。

2. 系统架构与数据模型设计：从接口到表结构

2.1 前后端选型与理由

前端这块我选了微信小程序原生开发，而不是 uniapp。原因有两个：第一，这个项目不需要跨端，最终只跑在微信里，原生框架的调试链路最短，报错信息最直接；第二，小程序有一些非常生态化的能力（订阅消息、支付、云开发），原生的封装和官方文档对齐度高，踩坑时搜到的答案最匹配。如果是个人开发者想顺便发布到支付宝小程序，再考虑 uniapp 不迟。

后端我采用的是"Node.js + Express + MySQL"的组合，部署在云服务器上。你可能要问，为什么不直接用微信云开发？我没有选择云开发是因为管理端需要一些复杂的聚合查询和定时任务，而且项目后续可能要和已有的会员系统打通，自己控制后端能自由得多。但如果你想用最短路径做出可演示的版本，云开发（云函数 + 云数据库）也是完全可行的，尤其省去了域名备案和HTTPS证书配置的麻烦。两种方式的取舍我放在下面：

考虑到本文面向的是"设计与实践"，后面我按传统的后端方案来讲，但在涉及登录、支付的部分，我会顺带说清楚云开发对应怎么做，方便你按自己的环境选择。

2.2 数据库表结构：咖啡杯上也该有"配置单"

商品规格是这套系统的数据模型里最需要动脑子的地方。一开始我想到的方案是每个商品建一个规格属性表，但咖啡的规格太不规则了——有的饮品没有糖度选项（美式/气泡水），加料列表则轻饮和咖啡完全不同。把每一种组合都拆成独立SKU既不现实，也会让后台维护商品时生不如死。

最终我采用"商品表 + 规格模板 JSON + 订单明细冗余规格快照"的组合方案。核心表如下：

几个值得展开的字段设计：

• product_spec.options直接存 JSON 数组。例如拿铁的规格模板可能是[{"name":"杯型","options":["中杯","大杯","超大杯"]},{"name":"温度","options":["热","去冰","少冰","标准冰"]},{"name":"糖度","options":["标准糖","少糖","无糖"]}]。这样可以做到每种商品有完全定制的规格结构，又不至于为每个商品建一堆关联表。
• order_item.spec_json在下单时把用户选择的规格组合快照存下来。这样做的好处是，哪怕以后商品价格调整、规格改名，订单历史里依然能看到"当时用户买的是什么"。这种"历史快照"思路在处理电商类订单时几乎是必须的，仅次于存一份纯 JSON 的快照。
• order.pickup_code是取餐号，比如"102"或"A03"，它在用户下单支付完成后生成，商家备餐完成时会把状态置为"待取餐"，用户在订单详情页能看到大大的取餐码。这个设计替代了传统叫号屏，微信通知 + 页面内码已经足够用。

2.3 接口协议：一张表理清前后端约定

接口设计遵循一个原则：小程序端只管展示和交互，所有业务规则都收敛到后端处理。核心接口如下：

所有接口统一返回{code, msg, data}结构。code === 0表示成功，非 0 为业务异常。登录中间件统一校验请求头里的Authorization，token 过期时返回特定错误码，小程序端自动重新走一遍wx.login刷新 token。

3. 小程序端核心功能落地：登录、点餐、购物车与订单流转

3.1 登录链路：少打扰用户的静默登录

小程序点餐和普通需要注册的App不一样，我强烈建议做成"静默登录"。用户扫二维码进来，不需要看到任何登录弹窗，直接就能浏览商品、加购物车，只有在提交订单的那一刻，系统才需要真正确定用户身份。

具体链路是：小程序端调用wx.login()拿一个临时 code，把它发给后端；后端用 code 调用微信接口换openid和session_key；后端生成自己的登录态 token 返回给小程序，小程序把 token 存在本地。后续所有请求都带这个 token。

// 小程序端登录示例 wx.login({ success: async (res) => { if (res.code) { const loginRes = await wxRequest('/api/login', 'POST', { code: res.code }); if (loginRes.code === 0) { wx.setStorageSync('token', loginRes.data.token); } } } });

这里有一个容易被忽略的点：老版本的wx.getUserInfo已经拿不到真实昵称和头像了，现在必须用wx.getUserProfile，而且这个接口只能在用户点击某个按钮的触发回调里调用，不能在页面 onLoad 里直接弹。所以我的处理是：进入点餐页完全不做用户信息授权，等用户第一次下单成功，再弹一个"完善资料"的可选组件，让用户自己决定要不要授权头像昵称。对于一杯咖啡的交易来说，openid 已经足够识别用户了。

3.2 点餐页设计：分类联动与规格弹层

点餐页是整个小程序里交互最复杂的页面，我把它拆成了三个区域：左侧分类栏、右侧商品列表、底部常驻购物车结算栏。

左侧分类栏用scroll-view纵向排列分类名称，右侧是当前分类下的商品列表。分类切换时，右侧列表滚动到顶部。我曾经试过"右侧滚动到哪个分类、左侧高亮到哪项"的双向联动，但第一版为了控制复杂度，只做了"点击分类切换右侧列表"的单向联动，跑通后再根据商品数量决定要不要做滚动监听。

每个商品卡片右下角有一个"+"按钮，点击后弹出规格选择浮层。这个浮层就是订单定制的核心：

// 规格弹层中处理用户选择 data: { product: null, selectedSpecs: {}, // { "杯型": "大杯", "温度": "热", "糖度": "少糖" } quantity: 1 }

规格选项我用radio-group来渲染，因为每种规格属性都只能单选。如果你在实现时用了radio，要注意两个细节：一是每个radio-group的name必须对应到规格模板里的属性名，比如"杯型""温度""糖度"，这样用户选择后直接event.detail.value就能按属性归位；二是最好给每个规格的第一个选项设置checked默认值，避免用户不操作时selectedSpecs里出现空值，导致后端校验报错。

选完规格后，商品卡片底部会实时显示已选内容，比如"大杯 / 热 / 少糖"，同时"加入购物车"按钮根据规格完整性决定是否可点击。这个过程看起来简单，但把"规格模板的 JSON 遍历渲染"和"选择结果的数据归并"做好，后面的购物车逻辑就非常顺。

3.3 购物车：本地同步优先，后端兜底

购物车我采用的是"本地即时操作 + 后端最终同步"的双层策略。用户在页面上加减商品、勾选结算项时，交互数据先存储在本地data里，界面立即刷新，不会有网络延迟感。当用户进入结算页时，小程序把购物车数据整体提交到后端，由后端校验库存、价格并生成订单。

这里有一个setData性能优化的细节：购物车里的商品数量变化是高频操作，千万不要对this.setData({ cartList: newArray })整数组赋值——少量数据时没问题，但购物车里塞十几件商品时就会出现轻微卡顿。我习惯用路径更新：

// 只更新购物车第 index 项的数量 this.setData({ [`cartList[${index}].quantity`]: newQuantity, 'totalPrice': this.calculateTotal() });

另外，小程序被微信切到后台再打开，内存里的数据可能丢失。所以每次加购、数量变更时，顺手把整个购物车结构wx.setStorageSync('cart', cartList)落一份到本地缓存。冷启动时先读缓存渲染购物车角标，避免用户中途离开再回来发现"购物车空了"。

3.4 订单提交、支付与取餐流程

订单提交时，小程序端把以下信息发给后端：

• 购物车商品与规格（来自本地结算数据）
• 订单类型：自提（到店取）或堂食
• 备注：比如"少冰去奶泡"、是否需要餐具

后端创建主订单和订单明细，生成唯一order_no和取餐号pickup_code，返回给小程序端。小程序端拿到订单号后发起支付。如果有微信支付商户号，可以直接用wx.requestPayment拉起真实支付；个人开发者或学生项目没有商户资质，我建议在后端做一个pay_type=simulate的模拟支付接口，方便把流程完整走通，等接入真实支付时再替换。

支付成功后订单状态变为"已支付"，商家管理端开始处理。之后用户能看到的关键信息是这几个：

• 当前状态文案："备餐中"、"待取餐"、"已完成"
• 取餐码：用于店员核对
• 预计等待时间：由商家端备餐完成动作触发

我在订单详情页做了一个较大的展示区专门放取餐码，因为这是用户到店最关心的东西。咖啡店场景下"取餐码 + 备餐完成通知"的组合，已经能省掉大量"我的做好了吗"的柜台询问。

3.5 代码结构建议（原生小程序）

我建议小程序端的目录这样组织，便于后期维护：

miniprogram/ ├── pages/ │ ├── index/ # 点餐首页 │ ├── cart/ # 购物车页（或与首页合并） │ ├── order/ # 提交订单页 │ ├── orderList/ # 我的订单 │ ├── orderDetail/ # 订单详情（取餐码） │ └── profile/ # 个人中心 ├── components/ │ ├── product-card/ # 商品卡片 │ ├── spec-popup/ # 规格选择弹层 │ └── cart-bar/ # 底部购物车栏 ├── utils/ │ ├── request.js # 请求封装 │ └── cart.js # 购物车本地状态管理 └── app.json

4. 开发中躲不开的坑：导航栏适配、分页加载与订阅消息

4.1 顶部导航栏高度与胶囊按钮适配

这个坑应该所有小程序开发者都踩过。为了让点餐页更沉浸，很多页面会设置"自定义导航栏"，但不同机型的顶部状态栏高度不一样，刘海屏和非刘海屏差距明显。如果自定义导航栏又写死高度，苹果刘海屏手机上导航栏就会和右上角胶囊按钮重叠。

我用的适配代码是：

const systemInfo = wx.getWindowInfo(); const statusBarHeight = systemInfo.statusBarHeight; const menuRect = wx.getMenuButtonBoundingClientRect(); // 胶囊按钮顶部与状态栏之间的间距 const navPaddingTop = menuRect.top - statusBarHeight; // 自定义导航栏高度 = (上方间距 + 胶囊高度) + 下方间距（微信规范上下间距相等） const navBarHeight = navPaddingTop * 2 + menuRect.height;

这段逻辑的原理不复杂：微信的胶囊按钮并不是紧贴状态栏的，上面有一小段留白。自定义导航栏要做得和系统导航栏视觉一致，只需要复刻这个间距——把导航栏总高度算成"上方留白 + 胶囊高度 + 对称的下方留白"。拿到statusBarHeight和navBarHeight之后，再通过 CSS 变量或者 WXML 内联样式注入到页面上所有需要定位的元素。

做完之后一定要在开发者工具的"机型模拟"里切换 iPhone 14 Pro、iPhone SE、各种安卓机型看一遍。真机预览也要重点检查。这是最容易让页面"看起来随便做的"的细节之一。

4.2 商品列表加载更多：onReachBottom 别重复触发

商品列表中如果分类下商品超过一屏，一次性渲染全部数据会让首屏加载很慢。我采取的是分页加载：每次请求 10 条，滚动到底部加载下一页。

// 分页参数 page: 1, loading: false, noMore: false, onReachBottom() { if (this.data.loading || this.data.noMore) return; this.fetchProducts(this.data.page + 1); }, fetchProducts(nextPage) { this.setData({ loading: true }); wxRequest('/api/product/list', 'GET', { page: nextPage, pageSize: 10 }).then(res => { const { list, total } = res.data; this.setData({ products: this.data.products.concat(list), page: nextPage, noMore: this.data.products.length + list.length >= total, loading: false }); }); }

这里有三个易错点：

• loading标志必须有。没有它，用户快速滚动时onReachBottom会被连续触发多次，导致同一页数据被请求好几遍。在请求完成前直接 return。
• noMore结束态要明确。如果后端返回的total小于等于已加载数量，要显示"没有更多了"，否则用户会一直往下滑一直看不到头。
• 分页时的"追加"不要用this.data.products.concat在旧数组上直接操作。上面的写法没问题，但注意不要直接改this.data.products，小程序的数据是不可变思维，每次赋值新数组才能保证视图正确更新。

4.3 订阅消息：授权弹窗的时机和次数要精算

订阅消息是这套系统里最有价值的一个能力，但权限机制用得不好就会成为骚扰源。微信小程序的wx.requestSubscribeMessage拿到的是"一次性订阅"，意味着用户每同意一次，后端只能给用户推送一条消息。所以不能一进小程序就弹窗，那几乎必然被拒绝。

我的做法是：用户完成下单支付后再请求订阅授权，模板用"订单进度通知"，文案是"您的咖啡制作完成后将通知您取餐"。这个时机点用户刚完成一次真实的消费动作，对"取餐通知"有真实需求，授权通过率明显比冷启动弹窗高很多。后端在备餐完成、状态变为待取餐时，调用微信的subscribeMessage.send推送一条通知。

// 用户支付成功后触发订阅授权 wx.requestSubscribeMessage({ tmplIds: ['你申请的模板ID'], success(res) { if (res['你申请的模板ID'] === 'accept') { // 授权成功，后端后续可以推送一次 } } });

还有一点要注意：订阅授权按钮必须是用户主动点击触发，如果支付完成后直接自动调用wx.requestSubscribeMessage，部分基础库版本会提示"需用户点击后触发"。稳妥做法是支付成功页上放一个明显的按钮，写"开启取餐提醒"，用户点击后弹授权窗，这样既合规通过率也高。

4.4 包体积超限与分包方案

我见过不少人开发到一半遇到"上传代码失败，代码包大小超过限制"。微信小程序默认主包有大小限制，如果图片资源或第三方库比较多，很容易碰线上限。我当时就因为商品图没有压缩，首包直奔 2MB 以上。

应对措施：

• 所有商品图片全部放到 CDN 或后端服务器，代码包内只放占位图。一张高清商品图动辄几百 KB，十张就超限，而 CDN 图片走外链不会占用代码包空间。
• 开启分包加载。把商品详情页、订单列表这类非首屏页面放到分包里，用户访问到时才下载对应包。

// app.json 中的分包配置示意 { "pages": ["pages/index/index", "pages/cart/cart", "pages/orderList/orderList"], "subpackages": [ { "root": "pages/order", "name": "order", "pages": ["orderDetail/orderDetail"] } ] }

这里有个经验：首屏点餐首页不要放太多自定义组件，每多一个组件就多一份代码体积。能做到"首页够用就绝不引入"是最好的原则，等后面功能确定了再按需拆分。

4.5 开发者工具、真机预览与体验版反馈收集

微信群里的开发文档说"模拟器和真机表现一致"，但实际差距非常大。举几个我遇到的差异：开发者工具里 storage 是跟随工具的，真机上是独立存储；部分设备信息模拟器取不到；模拟器中正常的下拉刷新手势，真机上可能出现滚动穿透。所以一个流程必须走全：开发者工具里完成功能开发 → 真机预览自测关键路径 → 上传代码生成体验版 → 把体验版二维码发给同事朋友收集反馈 → 再提交审核发布。

这里有一个团队协作细节：体验版怎么发给微信好友？在"微信公众平台 - 成员管理 - 体验成员"里添加对方为体验者，再把体验版二维码发给他。注意体验版和正式版是可以同时存在的，体验版改动不影响线上正式版，非常适合发布前内测。

5. 后台管理与订单状态机：门店运营的关键闭环

5.1 商品管理：上下架、改价与库存

后台管理端是整个闭环的另一半。如果没有它，小程序里所有商品都只能靠改代码维护，那这个系统就只是个 Demo。商品管理模块我实现的功能包括：商品新增、编辑、上下架、改价、排序、设置规格模板。其中最常用的是改价和上下架——咖啡店会因为季节性原料调整价格，或者某款产品售罄需要临时隐藏。

规格模板的编辑界面是管理端最复杂的部分，因为要处理类似"拿铁有杯型/温度/糖度，美式只有杯型和温度"的差异。我的做法是把规格模板设计成"可动态增加属性行"的表单，每行一个属性名 + 若干选项值，设置成 JSON 后保存到product_spec表。后端校验 JSON 合法性，前端拿到 JSON 渲染点餐弹层。

5.2 订单状态机：谁在什么时机做什么动作

订单状态机我在编码前专门画了状态图（这里用文字描述）：

• 待支付：用户提交订单但没付款，超时 15 分钟自动取消。
• 已支付/备餐中：用户支付完成后自动进入。商家端此时能看到新订单，点击"开始制作"后状态保持备餐中。
• 待取餐：商家制作完成，点击"出餐"，此时用户收到订阅消息通知，看到取餐码。
• 已完成：用户取走咖啡并确认，或商家点击完成。
• 已取消：用户取消或超时未支付。

简化成一句话就是：所有状态变更不能由用户端直接改，必须由后端记录操作者（用户操作还是商家操作）并且写入状态流转日志。这样一旦订单出了问题，可以快速回查是谁在什么时间把状态从 A 改到了 B。我在第一次开发时忽略了这个日志表，结果测试阶段出现"订单状态凭空变化"的问题时完全没法排查，后来补上order_status_log才解了这口气。

5.3 经营统计：先做有用的三个数

统计功能最容易做成一堆花里胡哨的图表。我在第一版只实现了三个数据：今日订单数、今日销售额、热销商品 Top5。这三个数据对店主的日常决策已经足够——比如今天某款卖得好要不要加量备货，某款半天没动要不要做活动。

第二版可以考虑加入"分时段订单分布"，这个数据能帮店主确定几点需要安排更多人手。不过这些都是后话，系统上线前期最要紧的是订单流程稳，不要让统计图表分散了开发精力。

5.4 简单的取餐叫号实现

小门店不一定需要硬件叫号屏。我用了一个极简方案：用户在订单详情页看取餐码，商家出餐后在管理端点击"出餐"，系统通过订阅消息推送给用户"您的咖啡好了，请凭取餐号取餐"。如果店里想放一个展示屏，也可以用一个网页接到后端接口轮询待取餐订单，把取餐码放大显示在电视上。第一版不做也没关系，API 已经留好了。

6. 从开发者工具到正式上线：测试、审核与发布复盘

6.1 测试清单：别只测"快乐路径"

我第一版测试时犯了一个典型错误：按自己的操作习惯把"点餐 → 支付 → 出餐 → 取餐"这条快乐路径测得很顺，结果上线前内测时朋友一次"支付后杀进程重新打开小程序"就把我打懵了——订单已经支付，但本地购物车数据没清掉，用户还能拿同一批商品重复下单。后来我在测试用例里增加了几类必须覆盖的场景：

• 加购后支付失败，购物车数据是否保留且订单不产生脏数据。
• 支付成功但小程序崩溃/杀进程，重新打开后订单列表能否正确显示已支付订单。
• 备餐中商家操作出餐，用户端订阅消息能否及时到达。
• 同时多个用户点单，取餐号是否唯一且递增。
• 弱网和断网状态下提交订单，是否有明确提示且不会重复创建订单。

最有效的测试手段是组织 3 到 5 个朋友拿各自的手机一起用体验版，大家同时下单，观察取餐号生成和库存扣减。一个人自测很难模拟出并发场景，多人实测能发现很多"两个人同时买最后一件商品"这类边界问题。

6.2 类目资质与认证：选错类目会被卡得很惨

小程序提审前最难过的一关是类目选择。如果定位是真实点餐服务，微信要求提供餐饮类目对应的资质，常见的如《食品经营许可证》。如果是个人开发者或学生做演示项目，没有这些资质，这边有一个合规取向：把项目定位成"点餐演示/工具模板"来提交，不要宣称是真实餐饮服务，类目选择上尽量低调。但注意，这只能用于学习和演示，如果你真要给一家实际营业的店做线上点餐，餐饮资质是绕不开的硬门槛。

另外，涉及微信支付必须完成微信认证，认证费用按平台现行规则收取，每年一次。而且个人主体的小程序无法开通微信支付，必须是个体工商户或企业主体。如果你只是自己练手，建议先用模拟支付走通流程；如果真的用于营业，提前准备好营业执照和相关许可证，把认证时间留足两周。

6.3 提审与发布的节奏

个人建议的发布流程顺序：

1. 线上开发自测通过后，上传代码生成体验版，在微信公众平台配置体验成员。
2. 体验版收集 3 至 5 天的反馈，重点修崩溃、白屏、订单异常这类高优先级问题。
3. 确认稳定后提交审核。首次提审一般一个工作日左右有结果，如果被驳回，看驳回原因改掉再提。
4. 审核通过后先不急着大范围宣传，可以先发布，在线下门店放一两个桌贴二维码，让到店顾客用，观察真实使用情况。
5. 前两周每日看后台订单数据和异常日志，优先处理"卡在支付结果回调""订单状态不同步"这类问题。

值得提醒的是，发布之后并不代表项目结束。小程序有基础库版本迭代、微信 API 策略调整、系统版本兼容等问题需要持续关注。比如某天微信改了用户隐私协议相关政策，那么你的代码里如果用了getUserProfile，就可能要在隐私弹窗配置里做适配。这类变更不在代码本身，而在平台规则，运营期间要经常留意公告。

最后说一点实际的体会。这套系统从需求梳理到第一版上线，前后大概用了一个多月，其中最重要的不是代码量，而是把"订单状态流转"和"规格数据结构"这两件事想清楚了再动工。如果你也想做一套类似的系统，我的建议是：先用一张 A4 纸把用户从扫码到取餐的每一步动作、每一步由谁触发、状态怎么变化画清楚，再开始写第一行代码。这个设计阶段省下的时间，远比你在编码阶段反复改逻辑要多。后面如果你打算扩展会员、优惠券或多门店，这套以 JSON 规格和状态机为核心的数据模型也能撑得住，算是给未来留好了接口。