1. 项目概述与整体设计思路1.1 项目背景与需求拆解今年接了个线下餐饮门店的信息化改造项目门店老板要求同时覆盖Android收银机和顾客微信小程序两个入口项目标题就叫“基于Android的餐饮点餐系统 餐桌包厢预订系统”。说白了就是服务员和前台用Android端管理桌台、包厢、订单和菜品顾客用微信小程序扫码看菜单、下单、预订包间两端数据实时同步。这类项目在中小型餐饮门店里需求量很大尤其是带包厢的餐厅、私房菜馆、烧烤店和火锅店。老板们普遍遇到几个痛点纸质菜单更新麻烦、服务员来回跑腿传菜低效、包厢预订要靠电话和本子登记、高峰期容易漏单错单。我接这个项目的时候老板还特意强调了一点——不要一上来就给他搞什么高大上的“智慧餐厅”全套方案先把点餐和订包厢这两件事做顺能用起来、稳定不崩比什么都强。所以整个需求拆解下来核心就三块Android点餐端面向服务员和收银员负责开台、加菜、退菜、结账、桌台状态管理、包厢预订管理。微信小程序端面向顾客扫码进入对应桌台或包厢浏览菜单、下单、加菜、预订包厢。后台服务负责两端的数据同步、订单流转、桌台和包厢状态维护、菜品和库存管理。这里有一个容易被忽略的点餐饮系统不是一个“做完就完事”的软件它的核心难点不在功能多而在状态一致性。比如一张桌子能不能被两个人同时开台、一个包厢能不能被两波人同时预订成功、顾客在小程序上点的菜能不能及时出现在后厨的打印单上。这些在纸面上看都是小问题真正跑起来全是坑。1.2 技术选型与双端架构思考技术选型方面我一开始就排除了纯H5套壳方案。原因很简单Android收银端要长时间在店里运行涉及多窗口操作、键盘输入、打印机联动H5壳子在这种高强度交互场景下体验不稳定卡顿和兼容性问题会让你在客户现场被反复折磨。Android原生端我选的是Java Kotlin混编开发工具就是Android Studio。现在Android Studio已经到Koala等新版本了建议直接下载官方最新稳定版不要用旧版本否则后面接第三方SDK、Compose、协程这些都会遇到版本兼容问题。新手如果觉得英文界面不习惯Android Studio支持汉化在Settings - Plugins里搜索Chinese Language Pack安装即可不影响实际开发。小程序端我用的是原生微信小程序开发没有上uni-app或者Taro。原因是这个项目的小程序端页面结构不复杂就菜单、下单、预订、订单几个页面原生开发学习成本低、调试最直接后续维护也方便。不过这里要注意一点如果你以后想把同一套逻辑同时发到支付宝小程序、百度小程序那uni-app确实能省不少事。我接触过一个汽车4S店积分小程序加后台管理系统的项目那边就是多端需求明确才选择了uni-app搭配HBuilderX发行到各端。所以选型这种事一定要先看目标场景。后端我用的是Spring Boot MySQL Redis架构。Redis在这里不是装饰品它是处理桌台状态和包厢预订并发问题的关键角色。点餐系统业务上并不复杂但高并发场景很典型比如节假日晚上同一时间段几十上百个顾客同时提交预订请求如果没有Redis做分布式锁MySQL在默认隔离级别下很容易出现超卖、重复预订的问题。这部分后面单独展开讲。最终的整体形态是Android端和小程序端共用同一套后端APIAndroid端主要走局域网和云端双通道小程序端全部走云端。考虑到门店的网络环境经常不稳定Android端还在本地做了SQLite缓存断网时能保证服务员至少能完成开台和录入订单的操作等网络恢复再自动同步。这个设计是上线之后才验证出价值的有次门店路由器故障全场断网将近半小时收银端硬是靠着本地缓存撑了下来老板对这件事印象极深。2. 两大核心业务模块的细节拆解2.1 点餐系统的状态与流程设计点餐系统听起来简单就是“选菜、下单、结账”嘛但实际做起来状态管理才是真正的核心。我一开始画流程图时想得太简单了直接就是“空桌 - 已点餐 - 已结账”结果开发到一半发现业务上根本走不通。现实情况是什么一张桌子可能从上午十点坐到下午三点中间加了三次菜还免了一个菜最后还拆了两张单分账。你用一个线性状态根本描述不了这种真实场景。我最终的设计是围绕“订单”这个核心实体来做状态管理桌台只是一个承载订单的容器桌台状态空闲、占用、待清洁、已锁定。空闲就是没有人占用是桌上有正在进行中的订单待清洁是客人刚走还没收拾已锁定是这张桌子因为设备故障或预留等原因暂时不能使用。订单状态待支付、已支付、已完结、已取消。点餐后先进入待支付结账后变为已支付然后进入财务对账的已完成状态。这里面最容易出问题的是“加菜”和“退菜”的流程。加菜不能简单地在原订单上加一行数据因为后厨要根据每次出菜时间打单。我当时的做法是每个订单下面挂多个子单每一次加菜或者退菜都生成一个独立的子单并关联一条操作流水。这样既能按时间线回溯整桌人吃了什么也方便后厨按批次出餐。菜单这块我用的是类目 标签两层结构。类目就是冷菜、热菜、主食、饮品这种大的分类标签用来做“招牌菜”“辣度”“推荐”这类横向筛选。这里有个比较实用的经验菜品表里一定要有一个is_sold_out字段控制售罄状态并且Android端和小程序端的菜单接口都要实时读取这个字段。否则顾客在小程序上点了一个已经售罄的菜后厨做不出来服务员还得跑去给顾客解释体验非常差。另外点餐系统里还接了一个很轻的“互动小游戏”模块。老板看到别家店排队等位时顾客能在小程序上玩玩“珠了个珠”这类合成小游戏觉得能减少顾客催单的焦虑感就让加了一个简易版。其实就是用Canvas做的消除类小游戏代码量不大但顾客反馈出乎意料地好有很多人为了消磨时间等餐反而翻菜单翻了更久。2.2 餐桌与包厢预订的关键逻辑餐桌预订和包厢预订是两个不同的业务模型必须分开处理。餐桌预订的核心是“按时间段锁桌”。比如明天中午12点到14点客人要预订一张靠窗的四人桌。这里的关键是时间段冲突判断。我一开始踩过一个坑直接查这张桌子在目标时间段内有没有重叠的预订记录但SQL写得太粗暴只判断了开始时间是否在已有预订范围内结果出现了“预订的结束时间卡在别人预订的开始时间之后”这种边界漏判。正确做法是判断两个时间段是否重叠重叠的条件是 开始时间小于已有预订的结束时间并且结束时间大于已有预订的开始时间。就这一句话当时让我改了三版SQL而且要在Android端和小程序端都用同一个校验接口绝不能两端各写一套逻辑。包厢预订比餐桌预订复杂的地方在于它自带最低消费和订金逻辑。很多带包厢的餐厅是有最低消费标准的比如小包低消800元大包低消1500元而且必须支付一部分订金才算预订成功。所以我在包厢订单里加了一个订金金额字段同时关联一个支付单。顾客在小程序端提交预订申请后先进入“待付订金”状态只有支付成功后才真正锁定包厢否则该时段释放给其他人。这里还有一个容易被业务方忽略的点取消预订和超时释放。我做了一个自动任务每天凌晨清理超过30分钟未支付订金的预订单把包厢重新释放回可预订池。因为经常有顾客随便提交一个预订又不付钱如果不做超时释放别人就永远订不到。包厢的排号、布置要求、备注信息这些细节我也都做了字段设计但我建议业务上不要过度设计。最开始我想加“圆桌方桌”“是否带独立卫生间”“是否可加座”这些精细化筛选实际上门店端服务员根本用不过来。后来精简成“人数范围、包厢名称、低消金额、状态”四个核心字段反而大家都觉得好用。做To B业务系统的经验就是这样功能不是越多越好每个功能都要有真实的业务场景支撑。3. 端到端实操从Android到小程序的完整落地3.1 Android端核心实现要点Android端是这个系统的“操作中枢”它承担了大量高频操作所以性能和稳定性要求非常高。开发环境上我直接用的Android Studio配合Gradle管理依赖。这里要给新入行的朋友一个建议Android Studio的下载安装不要图方便去第三方网站下一定要去官方渠道否则很容易装到捆绑插件或者带广告的版本。装完之后第一件事是把Android SDK配好项目里我用的是API 34最低兼容API 24这样既能覆盖绝大多数门店里的老旧收银机设备又能用到新系统的特性。界面方面我没有用传统的XML布局一撸到底而是用了RecyclerView DiffUtil来做菜单列表的刷新。为什么这么选因为菜单列表要频繁响应售罄、价格变更等操作如果每次刷新都整体notifyDataSetChanged在低端设备上会出现明显卡顿让人非常难受。DiffUtil会计算出新旧列表的差异只更新发生变化的那几行实测优化效果非常明显。Android端有一个模块设计我觉得是整项目的点睛之笔就是桌台状态机。我复用了一个状态模式设计每个桌台对象内部维护一个State接口具体有IdleState、OccupiedState、CleaningState、LockedState四个实现类。状态切换的动作全部封装在Context类里外部调用方不需要关心状态的流转规则。比如“开台”这个动作在IdleState里是合法的在OccupiedState里就会直接抛异常防止服务员重复开台。这个在多人同时操作时非常有用能从代码层面避免很多业务错误。网络请求我用的是Retrofit OkHttp这个是安卓开发绕不开的标配唯一要注意的是超时时间不要设太短。门店的WiFi经常不稳定我一开始把超时设成5秒结果训收银员训得最多的就是“点完菜转圈圈”。后来把connectTimeout和readTimeout都调到了15秒并加了失败重试机制问题才缓解。这里还要强调一个细节OkHttp的重试要区分请求类型POST请求不能盲目重试否则会重复下单需要在请求头里加一个幂等键。关于Android端的文件目录访问这里要特别提醒一下。你在开发时如果涉及导出账单、上传图片这类功能会遇到FileProvider的配置问题。很多人第一次接触时会被类似 content://com.tencent.wework.fileprovider/external_path/android/data/com.xxx.xxx/... 这种路径绕晕。其实就是FileProvider配置的authorities和实际代码里传入的Uri不匹配导致的。我的建议是所有需要跨进程共享的文件统一放到应用专属外部目录下并且authorities命名用包名 .fileprovider不要随便改否则微信分享、扫码识别这些系统组件都会找不到资源。3.2 小程序端搭建与页面实现小程序端的搭建流程我现在已经熟到不用过脑子了微信开发者工具新建项目填好AppID选原生JavaScript模板配置好app.json里的页面路由和窗口样式然后把项目里用到的网络域名加到微信公众平台的白名单里。这里有一步很多人会忘开发调试时要在开发者工具里勾选“不校验合法域名”否则请求本地后端API会一直被拦截。但上线前一定要取消这个勾选并确保所有请求都走HTTPS的合法域名。菜单浏览页是小程序端的流量入口。设计上我主打极简风格顶部是动态设置的导航栏标题根据顾客是从“扫码点餐”还是“包厢预订”进入标题会动态切换成对应的场景名。微信小程序设置导航栏标题有个wx.setNavigationBarTitle接口这个接口并不复杂但很多人不知道它可以在onLoad和onShow里反复调用完全能实现“一码多场景”的效果。还有一个细节就是小程序的顶部导航栏高度。不同机型上导航栏高度不一样刘海屏、灵动岛那种更是各玩各的。如果你要自定义头部组件不能用死值需要通过wx.getSystemInfoSync()获取statusBarHeight再根据胶囊按钮的位置动态计算导航栏的可用高度。这块代码我的做法是抽成了一个工具函数全项目复用保证任何机型上都不会出现标题顶到状态栏上的惨案。点餐页面的核心组件是菜品卡片列表和购物车。本来我想用小程序内置的swiper组件做横向滑动的分类切换但实际用下来体验并不好因为swiper的纵向滚动和页面的scroll-view会冲突。后来改成普通的tab切换每个分类下方挂一个scroll-view配合bindscrolltolower做分页加载反而稳定可靠得多。这里要给个比较直白的建议不要为了炫技去追求复杂组件小程序端的用户要的就是顺畅、直观、不迷路。包厢预订页里我用到了小程序原生的单选框组件。选择日期、选择时段、选择包厢每个都对应一个radio-group数据源是后端接口返回的可预订时间段。这里有个交互细节值得注意提交预订前要给用户一个清晰的确认弹窗里面展示包厢名称、日期、时段、最低消费、订金金额等关键信息减少误操作。我在项目上就遇到过顾客反复提交多次预订的情况后来就是靠这个确认弹窗加前端按钮防重复点击给降下来的。如果你后续想把小程序集成到App里从App端拉起小程序可以用uniapp的uni.navigateToMiniProgram接口或者原生微信SDK里的WXLaunchMiniProgram。但坦白讲这个项目现在的场景用不到这个功能我是因为有别的项目做了类似对接顺手研究过。做项目最忌讳的就是提前给没有需求的功能做设计这两者一定要分清。3.3 后端接口设计与参数计算后端API我按照RESTful风格设计资源名全部用名词复数比如/tables、/dishes、/orders、/reservations。接口要考虑两端复用所以请求和响应的字段设计上不能偏向任何一端。比如返回菜品列表时每个菜品同时包含price和memberPrice两个字段Android收银端可以用memberPrice做会员价展示小程序端也可以直接用同一份数据不需要再单独写接口。这里提一下订单金额的计算过程。餐饮行业的金额计算必须极其小心因为牵涉到折扣、会员价、餐位费、打包费、服务费等多种叠加逻辑。我的做法是后端统一计算前端只做展示。计算顺序是先算菜品原价总和再按会员折扣计算折后金额接着叠加餐位费和服务费最后减去手动优惠。每一步都记录在order_amount_log表里方便日后对账追溯。这个设计在门店月底对账时帮了大忙财务小姐姐专门打电话来夸过。Redis这部分我重点处理了两个场景。第一个是桌台状态变更的分布式锁。服务员A在Android端给3号桌开台顾客B在小程序端同时扫码进入3号桌点餐两个请求如果同时到达后端没有锁的话就会出现状态错乱。我用的是Redis的SETNX命令实现简单分布式锁key就是tableLock:{tableId}拿到锁的请求才能执行状态变更执行完后释放锁同时设置5秒过期时间防止死锁。第二个场景是包厢预订的防并发。顾客A和顾客B同时提交了同一个包厢在同一个時間段的预订请求我先用前面说的重叠判断SQL过滤一遍然后再过Redis锁只有第一个拿到锁的请求能成功创建预订单。这套“数据库检查 Redis锁兜底”的组合方案在上线后经历了两个节假日的考验没有出现过一次重复预订。负载方面我这套系统在普通配置的云服务器上单机就足以支撑一个中型餐厅的并发量了。但为了后续扩展我把接口层和数据层都做了分离设计。现在只在数据库读写上做了主从分离后续如果再升级可以在这个基础上加Redis集群和消息队列接口层的改动成本会很小。4. 实测中扎心的问题与排查技巧4.1 真机路径与文件访问的坑项目联调阶段出的最多的问题就是Android端的文件路径访问。门店用的收银机品牌很杂系统版本从Android 7到Android 14都有各家厂商对文件路径的管理策略又不完全一样。项目里要导出订单报表、打印小票、分享菜品图片这些功能都涉及文件读写稍不留神就会出现“图片显示不出来”“打印时提示文件不存在”这类问题。最经典的一个坑是Android 10以后引入了分区存储机制你的App不能随意访问公共目录下其他应用的文件。网上很多人遇到类似 content://com.tencent.wework.fileprovider/external_path/android/data/com.xxx... 这样的路径报错本质就是因为目标文件不在你自己的应用目录下系统拒绝让FileProvider跨应用访问。我的排查经验是打印日志里如果出现FileNotFound或者Permission denied不要先怀疑权限配置先看一眼完整的路径大概率是路径里的包名和应用实际的包名对不上。再把所有涉及文件访问的操作集中封装在一个FileHelper类里统一走FileProvider.getUriForFile生成Uri不要让自己在业务代码里满天飞new Uri不然排错排到你怀疑人生。另外一个非常实用的小技巧联调阶段我在每个文件操作的关键节点都加了Log输出打印出文件和Uri的完整路径。刚开始觉得这些Log很啰嗦但到了现场排障的时候才发现没有这些日志你根本不知道收银机上跑的是哪个路径。格式化日志的代码写的时候有点耐心调试的时候能救你一条命。小程序端的调试也有个类似的隐性坑。很多人发现小程序在开发者工具里一切正常一到真机就出问题往往就是没有做真机调试。微信开发者工具里可以开启真机调试用手机扫码后能看到实时日志。小程序抓包也要养成习惯Charles加HTTPS代理把请求和响应都看一遍很多问题根本不需要猜抓包看一眼就明白了。4.2 并发预订与数据一致性问题的实战修复上线后的第一个周末包厢预订模块就出了事故。那天中午有两个顾客在差不多同一时间提交了同一个包厢的预订请求系统居然都提示预订成功。我赶紧查日志发现两个请求确实都通过了重叠判断又在几乎同一时间拿到了Redis锁理论上锁应该只有一个线程拿到才对怎么会两个都成功了排查之后发现问题出在锁的释放逻辑上。我写的代码是拿到锁之后在finally块里执行delete操作释放锁。但有一个请求线程在等待拿锁的过程中超时了它并没有真正拿到锁却在finally里把锁给删了导致第二个请求趁虚而入也拿到了锁。修复方案有两个改动点。第一每个请求生成一个唯一标识作为锁的value删除锁之前先判断value是否等于自己的标识只能删除自己持有的锁。第二把“加锁 - 校验重叠 - 创建预订单”这三步操作放到一个事务里用数据库唯一索引做最后的兜底。经过这两轮修改之后这个问题才算彻底解决。这种并发问题有个共性你很难通过本地测试完整复现只有在真正的高并发场景下才会暴露。所以我建议所有做预订类系统的朋友在设计初期就要把“幂等”和“唯一性约束”这两个概念刻在脑子里。不能让业务逻辑只依赖代码层的判断数据库层的唯一约束才是最后一道防线。4.3 发布环节的备案与平台兼容清单小程序开发完成后发布上线前有几件事是绕不开的。首先是微信公众平台的备案流程目前小程序在上线前必须要完成备案否则无法发布。备案时填写备注信息的时候很多人不知道“备注”该填什么这里给个参考话术写明小程序的实际用途和服务类目比如“为餐饮门店提供在线点餐和包厢预订服务”言简意赅不要写废话也不要填错类目否则审核打回来重填一次就要耽误好几天。类目审核也是个容易踩坑的点。点餐和包厢预订如果不小心填成“电商平台”审核人员大概率会因为资质不足直接驳回。正确做法是选择“餐饮-餐厅排号/点餐”这类专门的类目按微信的规范来说这类目对资质要求最宽松通过率最高。平台兼容性这块我最近在做一个餐饮广告视频轮播功能时遇到一个问题在鸿蒙系统的手机上小程序播放视频偶尔出现闪屏或卡死的现象。排查下来发现是video组件的autoplay属性在某些系统版本上表现不一致导致的。后来我干脆不依赖autoplay自动播改成在onShow里判断用户操作后再手动调用play方法同时给video组件设置了固定的宽高比例问题就解决了。这种平台差异问题很难预判只能靠多机型测试来发现所以有条件的话测试设备池一定要覆盖不同品牌和系统版本。最后一个小建议项目上线只是开始后面每个版本迭代都要保持克制。我这个项目做了半年多回头看前期的核心框架没什么大改动新增的功能基本都是边缘需求。真正让我骄傲的不是功能多而是系统稳定开业到现在门店没有因为系统问题中断过一次营业。这比什么都值钱。