微信小程序咖啡店点餐系统设计与实现

周末下午三点店里排队点单的人从吧台一直堵到门口收银员一边听客人报“一杯冰美式换燕麦奶少冰”一边在收银机上找对应的按钮后厨的出杯节奏完全被打乱。这种场景在独立咖啡店几乎天天上演。我做完这套基于微信小程序的咖啡店点餐系统之后最大的感受是点餐动作虽然只是整个门店数字化里很小的一环但它牵动的却是前置点单、支付、后厨制作、叫号取餐、库存管理一整条链路。这套系统的价值不只是把菜单搬进手机而是把“排队点单”这个动作从高峰期剥离出去让收银台只处理现金、储值卡、打包等少数场景让咖啡师专心做咖啡。如果你正打算给自己的咖啡店、甜品店或者轻食店做一个小程序点餐系统或者在做一个类似的教学项目、毕业设计这篇内容应该能帮你少走很多弯路。我会从业务场景分析、数据模型设计、小程序端架构、后端接口设计、支付接入、门店接单端以及上线踩坑这几个维度把整套系统的设计思路和实操细节全部讲清楚。1. 为什么咖啡店点餐特别适合小程序化先把场景想明白很多人做点餐系统上来就画页面、写接口做到一半才发现业务上有个关键问题没想清楚。所以我建议先别碰代码把咖啡店的真实点餐场景拆开看。1.1 咖啡门店点单的三个核心痛点第一个痛点是排队拥挤。咖啡店的订单高峰往往集中在早上8点到10点、下午2点到4点这个时段的共同特点是出品速度远快于点单速度。客人站在收银台前选饮品、选规格、选温度、问“哪个好喝”、找零钱每单至少要花40秒到一分钟。小程序点单可以把这部分时间完全前置客人扫桌上的码或者店门口的码边走边点到店直接取。第二个痛点是信息传递误差。口头点单最怕的就是“少冰”“燕麦奶”“去咖啡因”这些关键词被听错一旦做错一杯日晒豆手冲的成本可能就白搭了。小程序点单天然规避了这个问题因为所有规格都是结构化选项选项落到订单里就是标准化的数据后厨看到的就是最精确的出品要求。第三个痛点是会员和复购无从下手。很多咖啡店还是靠收银系统里的手机号累计积分体验很差。小程序自带微信登录、订阅消息、支付即会员的能力可以把用户的消费记录、口味偏好、优惠券全部沉淀下来。虽然这套系统我没有做太复杂的营销模块但只要底层的用户ID和订单数据是完整的后续做会员、做优惠券就有基础。1.2 小程序方案的能力边界能做与不该做在动手之前明确边界特别重要。我的判断是小程序点餐系统在咖啡店场景里负责的是“顾客自助点单—在线支付—后厨接单—叫号取餐”这条线上的一切但它不应该一开始就试图替代收银系统、库存进销存、员工排班这些重系统。能力边界拆开看是这样该做的在线菜单展示、SKU规格选择、购物车、下单支付、取餐提醒、订单历史、门店信息展示。不该急着做的复杂后厨生产调度、多门店统一库存、储值卡账户体系、供应链进销存。这些等跑通之后再逐个叠加。微信小程序另一个优势是开发成本和获客成本都低。顾客不需要下载App扫一下码几秒就能进入点餐页面。用完即走这事在餐饮场景里反而是优点因为低频工具型应用本来就该做到零负担。1.3 咖啡品类对点餐系统的特殊要求咖啡和快餐、正餐的点餐逻辑不太一样主要体现在几个地方第一SKU的规格维度多。一杯咖啡默认就有杯型、温度、糖度、奶种、加料这五个可选维度。加燕麦奶、换低因豆、加一份浓缩这些都会影响价格。所以后端菜单数据结构必须支持“基础商品 多组规格 规格选项加价”而不是简单给商品表加几个字段。第二履约方式灵活。同一个订单可能选择“到店自提”“打包外带”“堂食”履约方式的差别会体现在取餐流上。有的顾客还会备注“晚30分钟再做”这类需求门店端需要能看到并人工确认。第三取餐叫号逻辑特别重要。咖啡店不像餐厅有桌号送餐客人取餐全靠叫号。我的设计里用“数字号简短口令”的方式降低过错率比如“178号冰美式”。取餐号直接从后端获取当天递增号口令则从订单商品的简称里取一个词做杯口贴单时一起打印出来。这些需求点想明白了后面的数据模型和接口设计才有据可依。2. 系统架构与数据模型订单状态机是整个项目的灵魂架构层面我选的是最务实的组合微信小程序原生实现顾客端和门店接单端两个小程序后端用单体服务数据存储用MySQL缓存用Redis静态资源和图片走对象存储加CDN。这套组合对咖啡店点餐场景来说足够稳定也足够便宜。2.1 技术选型为什么是原生小程序加轻量服务端先说前端。小程序端我坚持用原生框架没有引入第三方跨端框架。原因是点餐系统的页面复杂度其实不高页面数量少、交互集中在菜单、规格选择、购物车、支付这几块原生小程序完全可以覆盖而且原生框架对基础库的兼容性最好后续更新依赖也少。后端服务我选择单体而不是微服务核心考虑是团队维护成本。咖啡店点餐的并发量远远没到需要拆分服务的程度单体服务配一个数据库连接池就足够支撑几十家门店的日常流量。语言用的是JavaSpring Boot那一套换其他语言骨架同理核心在于数据模型和接口设计。数据库选MySQL是因为订单和支付数据有强事务性要求。下单、锁库存、生成支付流水、扣减库存这几个操作必须保证要么全部成功要么全部回滚关系型数据库的事务能力最合适。Redis在这里不是主力存储主要用来做库存的预扣减和高频读菜单缓存。2.2 数据表设计核心字段与关系的取舍数据模型是整个系统设计里最值得花时间的地方。我先把核心表列出来讲一下关键字段为什么这样设计。-- 菜品表简化 CREATE TABLE dish ( id bigint NOT NULL AUTO_INCREMENT, store_id bigint NOT NULL COMMENT 门店ID, category_id bigint NOT NULL COMMENT 分类ID, name varchar(64) NOT NULL, description varchar(255) DEFAULT , main_image varchar(255) NOT NULL COMMENT 主图URL, base_price decimal(10,2) NOT NULL COMMENT 基础价格(元), status tinyint NOT NULL DEFAULT 1 COMMENT 1上架 0下架, sort int DEFAULT 0, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 规格组表和规格选项表 CREATE TABLE sku_group ( id bigint NOT NULL AUTO_INCREMENT, dish_id bigint NOT NULL, group_name varchar(32) NOT NULL COMMENT 如杯型/温度/奶种, required tinyint NOT NULL DEFAULT 1 COMMENT 是否必选, sort int DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE sku_option ( id bigint NOT NULL AUTO_INCREMENT, group_id bigint NOT NULL, option_name varchar(32) NOT NULL COMMENT 如中杯/大杯, extra_price decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 加价金额, stock int NOT NULL DEFAULT 999 COMMENT 当前可售库存,-1不限, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表简化 CREATE TABLE orders ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, store_id bigint NOT NULL, customer_id bigint NOT NULL, status tinyint NOT NULL COMMENT 状态机见后文, fulfil_type tinyint NOT NULL COMMENT 1自提 2外带 3堂食, take_no int DEFAULT NULL COMMENT 取餐号, remark varchar(255) DEFAULT , total_amount decimal(10,2) NOT NULL, pay_amount decimal(10,2) NOT NULL, pay_time datetime DEFAULT NULL, cancel_time datetime DEFAULT NULL, finish_time datetime DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_customer_time (customer_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单明细记录下单时的商品快照 CREATE TABLE order_item ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL, dish_id bigint NOT NULL, dish_name varchar(64) NOT NULL COMMENT 冗余商品名, sku_desc varchar(255) NOT NULL COMMENT 规格描述:大杯/冰/燕麦奶/加一份浓缩, unit_price decimal(10,2) NOT NULL COMMENT 下单时单价快照, quantity int NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里面有两条设计经验值得单独说订单明细必须存商品快照。商品名称、价格、规格描述在下单那一刻原样存进order_item绝对不能下单之后再去关联查询商品现价。因为门店改价是常态如果订单数据关联实时价格历史订单的金额统计就会错乱对账也会出问题。订单号不要用数据库自增ID用业务订单号。我生成的规则是10位年月日 门店编号 4位随机数再加一个独立的自增ID作为主键。业务订单号给顾客看、给支付回调做幂等Key、给客服对账用自增ID只给内部关联用。这样既避免了并发下的ID猜测风险又方便日志排查。2.3 订单状态机的完整流转路径订单状态是整个系统里最容易写乱的地方我在设计时把所有状态转移画成一张严格的路径表代码里按这张表校验合法性状态含义可进入的下一状态触发条件10已创建待支付20 已支付 / 90 已取消用户支付成功 / 超时未支付自动取消20已支付待接单30 制作中 / 92 退款中门店接单 / 用户申请退款且门店同意30制作中40 待取餐 / 92 退款中门店点击出餐 / 商家主动退款40待取餐50 已完成顾客取餐门店核销50已完成不可流转终态90已取消不可流转终态92退款中94 已退款退款到账两个实操细节超时未支付取消不是任务调度扫描出来的是用户下次打开订单详情页、或者支付回调回来时顺带校验的。因为小程序端App切后台后定时器不可靠用懒结算方式反而简单避免了一套复杂的状态机定时任务。**退款状态必须拆成退款中和已退款两个状态。**很多系统只用一个“退款中”状态用户侧看到订单一直在退款中不知道钱到底回来没有。微信支付退款是异步的回调里更新状态之后才把订单推到已退款。这个状态机是整个系统的中枢所有角色——顾客端、门店接单端、支付回调——都在围绕这一组状态做操作设计阶段多花半小时画清楚后面写接口能少改一半代码。3. 小程序端页面架构与购物车状态管理小程序端的核心体验在于点餐过程的流畅度。用户扫码头几秒钟的耐心是很有限的如果页面加载慢、规格选择绕、购物车交互卡很容易流失。这一节讲页面骨架和购物车这块最关键的交互设计。3.1 页面与导航设计菜单页、确认订单页、订单中心整个顾客端小程序一共四个Tab页加两个二级页面pages/index/index 菜单点餐首页一级Tab pages/order/list 订单列表一级Tab pages/mine/mine 我的页面一级Tab pages/cart/cart 购物车页一级Tab pages/order/confirm 确认订单页二级 pages/order/detail 订单详情页二级实际使用中用户流量绝大部分落在index页。菜单页采用“左侧分类栏右侧菜品流”布局左栏是意式咖啡、手冲、茶饮、甜品等分类右栏是菜品卡片卡片上只显示主图、名称、价格规格选择放到弹层里处理。进入小程序时的onLoad逻辑里做三件事请求门店基础信息营业状态、门店公告、请求菜单数据、请求购物车本地缓存。菜单数据我做了本地缓存缓存Key是menu_版本号版本号由后端返回。只有版本号变化时才全量刷新菜单CDN该做的事不要让小程序每次启动都重复做。3.2 购物车为什么放前端内存而不放后端这是一个很多人在开始做时纠结的问题。我的结论是购物车放前端本地后端只管下单时的校验。放在前端的理由购物车是高频操作用户每加一件商品都请求一次后端接口不仅浪费网络还会让页面交互有明显的卡顿感。而购物车的本质是“用户的临时意愿集合”不涉及账户资金丢了也无所谓完全没必要承担后端存储的成本。下单时必须后端重新校验前端购物车里的菜品可能已经下架、可能改价、可能库存不足。所以本地购物车数据只是一份“草稿”真正提交订单时后端要根据订单里的商品明细重新查询数据库里的商品状态和实时价格逐项校验并重新计算金额。前后端以“后端计算结果为准”这个原则要刻在脑子里。实现层面我只用了一个轻量状态管理小程序App.js的globalData里维护一个cartItems数组页面每次操作购物车之后调用一次更新方法把最新数组写入Storage。这样切后台重启小程序购物车也不会丢同时页面切换时数据不需要重新mock直接读全局实例。// 购物车条目结构示例 { dishId: 101, dishName: 燕麦拿铁, skuOptions: [ { groupName: 杯型, optionName: 大杯, extraPrice: 3 }, { groupName: 温度, optionName: 热 }, { groupName: 奶种, optionName: 燕麦奶 } ], skuDesc: 大杯/热/燕麦奶, unitPrice: 29, quantity: 2 }这里有个小坑需要注意小程序页面跳转的时候页面栈里的数据不会自动同步。如果购物车在三个页面里都可能被修改每次onShow的时候都要重新从globalData拉一遍并setData否则会出现返回上一页时购物车数据没刷新、角标数字不对的经典Bug。3.3 SKU规格选择与库存置灰逻辑规格选择弹层是用户使用频率最高的组件它的交互细节直接决定转化率。设计原则是默认选中合法规格非法选项置灰用户一进来就能直接点“加入购物车”。比如用户点了一杯拿铁弹层默认选“中杯/热/全脂奶”这样只想点中杯热拿铁的顾客根本不用操作直接加购。只有想改规格的人才去点选。因为后端返回的SKU组合可能多达几十种前端不可能逐个枚举所以置灰逻辑的统一规则是当前已选的组合如果在某个必选组里没有可选项就把这个组里所有不可达的选项置灰。库存数字在SKU详情里由后端返回选项库存为0时前端直接禁用避免用户选了半天最后提交时被告知售罄。这个细节虽然小但在高峰期招牌豆卖完的时候特别有用能减少大量无效操作。4. 后端接口设计与权限控制从扫码进店到订单落库后端接口是整个系统能否支撑订单闭环的骨架。我把接口分成两组顾客端一组、门店接单端一组。这两组的鉴权逻辑和接口语义完全不同分清楚才能避免权限混乱。4.1 顾客端核心接口清单与字段设计顾客端接口围绕“点餐主流程”按顺序设计接口方法职责关键说明/api/user/wxLoginPOST微信登录换token前端拿wx.login的code换openid服务端返回自建token/api/store/homeGET门店信息营业状态、公告、菜单版本号/api/dish/listGET查询菜单返回分类、菜品、规格组、规格选项/api/cart/validatePOST校验并计算购物车提交前校验库存和价格返回最新金额/api/order/createPOST创建订单生成状态为待支付的订单返回订单号/api/order/payPOST获取支付参数调微信支付统一下单返回支付参数/api/order/statusGET查询订单状态轮询用返回状态机当前值/api/order/cancelPOST取消未支付订单校验订单状态必须为待支付有一个细节我特意分开了“创建订单”和“获取支付参数”两个接口而不是常见的一个接口里直接下单并返回支付参数。原因是如果合并微信支付统一下单这步一旦因为商户号配置问题报错订单已经写进数据库了就会产生一批“卡在待支付”的脏数据。分开之后流程更干净先创建订单再单独发起支付支付失败不污染订单表用户重新发起支付也只需要调用第二个接口。4.2 下单与库存并发控制Redis预扣减的正确姿势咖啡店高峰期最容易出问题的地方就是库存。热门的“限量SOE豆”可能在半小时内售罄如果库存校验完全依赖SQL更新时的乐观锁会导致大量下单请求打到数据库上拖慢整个订单接口。我的做法是两层控制第一层下单时用Redis做预扣减。菜品有库存限制时在Redis里维护一个库存Key提交订单时用Lua脚本原子执行“检查库存-预扣-返回结果”判断当前库存是否足够。这一步能挡掉99%的超卖请求MySQL数据库不会因为并发下单被打爆。第二层订单真正完成支付、回调确认之后再扣减数据库的最终库存。如果用户下单后一直不支付Redis里的预扣库存会在超时取消时释放掉。这样设计会有一个数据不同步的窗口期但在这个量级的业务里完全够用换来的是极高的并发承受能力。核心思路是把“可卖数量校验”放在Redis层把“真实库存数据”放在MySQL层二者通过订单的支付回调来对齐。这个方案对几千店的并发规模绰绰有余而且不会引入分布式事务这种复杂度。4.3 登录鉴权openid与自建token怎么配合小程序端登录流程是固定的三步前端wx.login拿临时code后端调用微信接口用code换取openid然后后端把openid存到用户表并生成一个自建token返回前端。这里要记住一个原则openid是用户的永久身份标识但不能直接暴露给前端。所有后续请求都通过自建token来识别用户openid只存在于服务端。原因是openid一旦泄露第三方可以拿它去请求微信接口存在安全隐患。自建token我用的方案是JWT签名密钥存在服务端环境变量里。token里只放用户ID和门店ID两个关键字段有效期设置成30天用户登录之后只要一直在小程序里活跃就不用重新登录。用户换手机重新进入时微信登录会返回同一个openid后端查用户表命中后直接刷新token用户根本不需要重新注册。5. 微信支付接入与对账从下单到落袋的完整链路支付是整个点餐系统里最不能出错的部分。这块我踩过一个坑当时总是收到“该订单已支付”的重复回调日志后来发现是回调处理没有做幂等。这一节把支付设计的几个关键点完整说一遍。5.1 支付流程的三个关键节点微信支付在小程序端的流程看起来不复杂但拆开之后至少有三个节点必须处理好下单节点后端拿到订单号之后调用微信支付“统一下单”接口传入金额、商品描述、回调URL等参数微信返回一个prepay_id。支付发起节点后端把prepay_id和签名等参数封装成小程序端wx.requestPayment需要的格式前端拉起收银台用户输入密码完成支付。回调节点微信服务端发送支付结果到后端的回调URL后端更新订单状态和支付流水。容易出错的地方在两处一是wx.requestPayment需要的参数必须严格按照timeStamp、nonceStr、package、signType、paySign这五要素构造后端要返回的是这五个字段的完整对象而不是只返回一个prepay_id让前端自己拼二是回调URL必须配置成公网可访问的HTTPS地址且不能带查询参数否则微信服务器无法正确回调到你的接口。5.2 回调处理与幂等设计重复通知是常态不是意外微信支付回调机制的一个特征是“通知可能重复”网络抖动、微信服务器重试同一个支付结果可能被回调多次。如果回调处理逻辑没有做幂等就会导致订单状态被重复推进、支付流水重复插入等问题。我的处理方案是第一步回调进来先验签。用微信商户密钥对回调报文做签名校验验签失败直接返回失败并记录日志防止伪造回调。第二步按订单号加锁。在支付回调处理中用订单号 支付流水号做唯一索引插入支付流水表。如果插入时发生唯一键冲突说明这条流水已经处理过直接返回成功响应不再重复更新订单。第三步更新订单状态时带上状态前置条件。SQL语句写成UPDATE orders SET status 20 WHERE order_no ? AND status 10。如果更新影响行数为0说明订单状态不是待支付可能已经被其他流程处理过同样直接返回成功并记录日志。这套幂等逻辑同样适用于退款回调。只要每个外部通知都对应一个唯一的业务流水号并且用流水号做唯一约束重复通知就是安全的。5.3 退款、对账与异常订单处理退款场景虽然订单量不高但设计上不能含糊。我做的退款入口有两个用户在小程序端发起退款申请、门店接单端主动发起退款。两个入口都走同一个退款服务调用微信支付退款接口并把退款状态落到订单状态机的“退款中”。对账方面我每天凌晨跑一个定时任务把昨天的微信支付对账单下载下来与本地支付流水表做匹配。凡是平台有记录但账单上没有的或者账单上有但平台没有的单子都打进异常订单表第二天人工核查。这个对账任务看起来不起眼但它能发现很多隐蔽的Bug比如漏处理的回调、手动改单产生的差异、测试环境的脏数据残留。6. 门店接单端与数据统计系统不能只服务顾客点餐系统如果只做顾客端门店根本没法运转。一个完整的咖啡店点餐系统必须包含门店接单端和经营数据看板。我这边门店端做了一个独立的小程序和顾客端完全分开账号体系也独立。6.1 商家端小程序的接单流程门店接单端的设计核心是“状态可视化 操作极简”。店员每天面对的不是程序员操作路径必须越短越好。我设计的接单流程如下新订单进入后门店端首页顶部实时刷新待处理订单列表。订单卡片上显示取餐号、商品明细、规格描述、备注一键点击“开始制作”订单状态从20变成30。制作完成点击“出餐”状态从30变成40顾客端立刻可以看到待取餐状态。顾客到吧台取餐时店员输入取餐号并点击“核销取餐”状态变为50完成。这里有个很重要的设计门店端的订单列表不能靠手动刷新必须做实时推送或者高频轮询。我用的是微信小程序原生WebSocket做新订单通知服务端在支付回调成功后向前端推送一条“新订单”事件同时轮询作为兜底。门店端一旦收到新订单通知就播放一个短短的提示音并震动防止店员错过订单。6.2 取餐提醒与订阅消息的一次性特性取餐提醒是咖啡店点餐特别重要的一环这里就涉及微信小程序的“订阅消息”能力。使用订阅消息有一个关键认知用户订阅一次只能收到一次消息且订阅时机越自然越好。微信规定一次性订阅消息的授权弹窗必须由用户主动触发不能在小程序加载时偷偷弹。我的做法是在用户完成支付、跳转到支付成功页的时候弹出一个“接收取餐提醒”按钮用户点击按钮时调用wx.requestSubscribeMessage请求订阅。这样订阅的动机最强因为此时用户正等着取餐触达率是最高的。后端在门店点击“出餐”时通过订阅消息接口推一条“取餐提醒”给用户消息里带着取餐号和取餐口令。实测下来这个场景的订阅率能到70%以上配合门店的取餐屏展示基本不会出现做好放那儿没人取的情况。6.3 经营数据看板给门店的决策依据数据看板需要避免做一堆华而不实的图表真正能给门店提供决策价值的就四个指标指标计算方式对门店的意义订单高峰时段分布按小时统计订单数和实收金额决定排班和备货节奏热销商品Top10按订单明细聚合销售数量决定物料采购重点客单价实收金额/有效订单数评估套餐和加购引导效果门店库存预警库存剩余量低于阈值时提示防止高峰期断货我用Spring定时任务每天早上生成昨天的数据汇总门店端直接查汇总表避免现场做复杂聚合查询把数据库查崩。首版数据看板控制在几个关键数字上比一堆图表堆叠更实用。7. 上线前后实测踩坑审核、性能与兼容性系统做到能跑只是第一步真正上线要过微信审核、做性能优化、处理各种机型兼容问题。这些坑不实际上线基本遇不到我一条条列出来能帮你省下大把调试时间。7.1 微信审核与资质最容易卡住的环节小程序审核是上线第一道坎咖啡店点餐属于“餐饮服务”类目审核时要求提供《食品经营许可证》相关资质。如果你的门店主体没有这个资质或者用的营业执照经营范围不含餐饮审核大概率会被驳回。这个前置条件必须在开发之前就确认好否则开发做完了都发不了版。另一个高频驳回原因是“登录功能未合规”。小程序的getUserInfo授权不能在小程序启动时强制拉取只能在用户主动点击按钮时触发。我们当时就是首版在启动时直接弹头像昵称授权窗口被审核驳回过一次。后来改成“点击授权登录”才通过。7.2 包体与首屏性能2MB红线不是闹着玩的小程序主包大小限制是2MB超过就没法走正常审核。诗点餐系统最容易超包的地方是两个本地图片资源和页面代码冗余。我的处理方案是所有菜品图片一律放CDN小程序包内不放任何超过10KB的图片。菜单页的图片是高频请求我用图片预加载策略首页进入后先加载首屏菜品图其他图片延迟到用户滚动到具体位置时用懒加载方式加载。配合CDN缓存用户的加载体验反而比本地打包图片更好。首屏速度上还做了一个优化菜单数据和服务端门店配置做了本地缓存用户第二次进入小程序时首屏直接读缓存渲染后台同步拉最新数据做diff更新。实测冷启动首屏能从1.8秒优化到1秒以内。7.3 低端机兼容与弱网容易暴露体验问题的场景小程序的基础库版本碎片化比较严重低端安卓机上的表现和开发工具里完全不一样。踩过的几个具体问题一是iPhone带刘海或Home指示条的安全区适配。底部Tab栏和“加入购物车”悬浮按钮都需要适配safe-area-inset-bottom不然会出现按钮被Home条遮挡的尴尬情况。解决办法是给底部操作栏加上env(safe-area-inset-bottom)的padding这个一定不要偷懒跳过。二是弱网环境下购物车数据丢失。用户刚刚加购完商品切到后台锁屏过几分钟回来发现购物车空了。原因是小程序被系统回收后globalData里只剩初始值Storage里又没有同步最新的购物车数据。我的修复方案是每次购物车变更时同步写一次StorageonLaunch恢复时先读Storage再让用户操作。频率不高但能保证基本不丢。三是支付返回后的页面状态刷新。用户支付成功返回原来的订单页时页面里的数据还停留在“待支付”状态。必须在onShow里重新调用一次订单状态查询用返回值刷新页面。这是最常见的一个交互Bug开发时忽略、用户使用时特别明显。做完整套系统再回头看工程难度不大真正的门槛其实在业务梳理和细节处理。菜单结构怎么设计才不冗余、订单状态怎么流转才不混乱、支付回调怎么处理才幂等、门店端怎么操作才高效这些才是决定系统好不好用的关键。小程序点餐只是咖啡店数字化的一小块拼图但它把最影响顾客体验的点单环节解决了门店的运转效率立刻就能看到改善。最后再给一个建议如果这套系统要放到真实门店运营先把“菜单维护”和“订单异常处理”这两个后台功能做扎实它们的使用频率远超你的想象。