2. 项目背景与痛点分析代替1. 项目概述结构1.1 大学食堂排队场景的真实困境做这个项目之前我先在几所高校的食堂蹲了几天。中午十二点下课铃一响几千人同时涌向食堂选餐窗口前排起十几米的长队打饭师傅忙得连抬头的时间都没有。尤其遇到麻辣烫、铁板饭这类制作时间长的窗口排队半小时以上是常态。更尴尬的是经常排到自己时想吃的菜已经卖完只能在剩下的菜品里将就。这种场景本质上是典型的供给侧与需求侧信息不对称。学生不知道哪个窗口还有哪些菜、大概要等多久食堂窗口也不知道今天的客流量分布只能凭经验备餐。排队浪费的时间、菜品售罄造成的失望、窗口备餐量不准导致的浪费这些痛点叠加在一起就是点餐APP要解决的核心问题。我做的这套系统核心出发点就一句话把先排队再看菜变成先看菜再下单。用户提前选好食堂、窗口、菜品下单后窗口按单备餐用户根据取餐号去窗口取或者选择堂食时段错峰就餐。整个流程把线下的随机排队挪到了线上的确定性预订。1.2 角色划分与核心业务链路系统涉及三类角色学生用户、食堂窗口商家、系统管理员。三类角色的诉求完全不同这也决定了功能模块的边界。学生用户最关心的是选菜是否直观、下单是否够快、订单状态是否清楚。食堂窗口最关心的是订单怎么接、备餐顺序怎么安排、菜品卖完了怎么及时下架。管理员最关心的是食堂公告怎么发、用户反馈怎么处理、数据统计怎么看出餐效率。核心业务链路是这样的用户注册登录后按食堂列表进入某个食堂再按窗口进入菜品列表选菜加入购物车结算生成订单。订单推送给对应窗口窗口接单后更新状态为备餐中备餐完成改为待取餐用户到窗口出示取餐号完成取餐。如果用户下单后食堂还没开始营业系统还需要支持预约单窗口营业后按预约时间顺序处理。这几条链路串起来就是一个标准的O2OOnline to Offline场景技术上和外卖平台的下单流程非常相似只是把配送环节换成了到店取餐。2. 技术选型与整体架构设计2.1 Android客户端技术栈的选择逻辑客户端采用原生Android开发语言选了Java。有人问我为什么不用Kotlin我的考虑是这个项目定位是课程设计和毕设级别的系统很多同学对Java的熟练度更高后续修改和维护压力小。Kotlin虽然更现代但对初学者的编译器报错理解门槛略高。如果你是自己练手完全可以用Kotlin两者的架构思路是通用的。网络层选择了OkHttp Retrofit组合。Retrofit负责接口定义和返回数据解析OkHttp负责底层网络请求。这套组合是目前Android开发的事实标准资料多、稳定、学习成本低。图片加载用Glide它内部做了内存缓存和磁盘缓存对于菜品图片这种高频重复加载的场景能明显减少流量消耗和卡顿感。本地存储用了SharedPreferences SQLite的组合。用户登录状态、token过期时间这类轻量数据放SharedPreferences购物车数据、历史订单缓存放SQLite里的自有表。为什么购物车要本地存一份因为用户加购十几样菜、中途杀掉APP再打开时购物车还得保留纯靠服务端存一份当然也行但本地缓存能保证弱网环境下购物车依然可操作。2.2 服务端框架与数据库方案服务端用的是Spring Boot。为什么不选Node.js或者Python Flask因为Spring Boot在高校教学和企业级项目中覆盖率极高身边人问问题比较好找人。而且Spring Boot自带的依赖注入、事务管理、JPA/MyBatis集成对订单这类强事务场景特别友好。比如用户下单时既要扣减库存又要生成订单记录还要清空购物车这三步必须在一个事务里否则会出现扣了库存没生成订单的数据不一致Spring框架的Transactional注解可以直接解决。数据库选了MySQL。做这种订单系统关系型数据库是必须的菜品分类、订单明细这些数据天然有外键关联用NoSQL反而费劲。ORM框架用MyBatisSQL语句可以手写遇到复杂联表查询比如统计某窗口一天各菜品销量时比JPA那种自动生成的SQL更可控。整体架构是一个典型的Android客户端 Spring Boot服务端 MySQL数据库的松耦合三层架构。客户端只负责UI展示和交互业务逻辑全部下沉到服务端两者通过JSON格式的RESTful接口通信。App端只管把订单数据POST给服务端至于订单怎么流转、库存怎么扣减都是服务端的事。这种架构的好处是后续想加一个iOS端或者小程序端直接复用服务端接口就行不用动底层逻辑。2.3 为什么不用Bmob或LeanCloud这类后端云这里说一点个人看法。现在很多学生做App图省事直接用Bmob、LeanCloud这类后端云服务注册登录、数据存储都不用自己写后端了。但这类服务的自由度有限复杂查询做不了事务支持几乎没有而且免费额度和并发限制是硬伤。食堂高峰期如果有几百人同时下单这类服务大概率会出现延迟和超时。自己做一套Spring Boot后端虽然前期多花两周时间但你能拿到完整的接口设计经验、SQL优化能力、事务处理能力面试时被问到你项目里如何处理高并发下的订单超卖你至少能说出用乐观锁事务这样的实质方案。所以我一直建议做这种完整系统还是老老实实从零搭后端。3. 核心功能模块与数据库设计拆解3.1 用户端功能模块的完整闭环整个App按照用户操作路径拆成了六个功能模块登录注册、食堂浏览、菜品选购、购物车管理、订单管理、个人中心。每个模块之间用Activity跳转串联用Intent传参。登录成功后用户信息放在一个全局的UserSession单例里避免每个页面都重复查询数据库。登录注册模块我做了账号密码登录 手机号快捷登录两种方式。账号密码走服务端校验手机号快捷登录用简单的验证码流程——服务端生成四位随机码通过短信服务商的API发送客户端输入后POST到服务端校验。短信服务接入需要企业资质个人开发时可以用调试模式代替服务端直接返回固定的1234在UI上提示调试模式验证码已固定为1234。菜品选购这块是用户停留时间最长的页面。食堂列表页用RecyclerView展示每个食堂的名称、图片、营业时间、当前营业状态。点击食堂进入窗口列表再点窗口进入菜品列表。菜品列表每行展示图片、名称、月售量、价格、加号按钮。月售量这个字段是亮点它直接影响用户决策数据是从订单明细表里实时聚合出来的。购物车模块在底部用了一个弹出式BottomSheet来展示。用户在任何菜品页点击加号菜品就进入购物车底部按钮实时更新总数量和总价。购物车页面支持修改数量、删除、清空操作。这里有个细节跨窗口的菜品在购物车里要分组展示因为一个订单只能属于一个窗口用户结算时必须按窗口拆成多个订单。很多新手初版购物车不分窗口结果结算时发现订单没法推送给对应的窗口这是一个比较常见的坑。订单模块是全系统的核心。提交订单时客户端要传一堆信息用户ID、窗口ID、备注、菜品ID列表、数量列表、期望取餐时间。服务端收到后先校验菜品是否还都在售然后在一个事务里扣减库存、生成主订单多条订单明细、清空服务端购物车缓存最后返回订单ID和取餐号。取餐号我用的是4位数字每天按1000递增重置比如当天第一个订单是0001取餐时报号即可。个人中心就是常规操作头像上传、修改密码、查看历史订单列表、查看余额并充值。我把余额支付也加进了支付方式里因为学生使用场景中虚拟账户支付反而比接入微信/支付宝更现实。余额表存在user表里的balance字段下单时服务端检查余额是否充足充足则扣款不充足则提示充值。3.2 窗口商家端与管理端模块窗口商家端和管理端我没有单独做App而是做成了Web管理后台。做App的话等于要再维护一套Android端的代码工作量翻倍而食堂窗口本身有电脑和扫码枪浏览器访问管理后台更符合实际使用习惯。商家端页面包括今日订单列表、订单详情、菜品管理、营业状态切换。订单列表按时间倒序待接单的订单高亮置顶。商家点击接单后订单状态变为备餐中备餐完成点出餐状态变为待取餐。每一步操作都直接改数据库里的status字段用户端通过轮询或推送同步看到状态变化。菜品管理支持上架新菜、修改价格、图片、是否售罄。这里我特意加了一键停售按钮某个菜卖完时商家点一下App端该菜品立即显示已售罄并置灰从源头避免超卖。管理端重点做三件事食堂和窗口的增删改查、全局公告发布、订单统计报表。统计报表用ECharts画了三个饼图和一个折线图分别展示各窗口营收占比、各菜品销量排名、全天订单量时段分布。这些数据对食堂优化备餐量极其有用比如某窗口发现连续两周麻辣香锅窗口的午高峰都在12:20-12:40就可以提前多备一批食材。3.3 数据库表设计思路与字段含义数据库一共建了七张核心表。user表存用户信息字段有id、username、password、phone、balance、avatar_url、create_time。password存的是加盐后的MD5值这是基本的安全要求明文存密码属于最低级失误。window表存食堂窗口信息包括window_name、canteen_id、description、business_hours、status。dish表存菜品字段有dish_name、window_id、price、image_url、month_sales、stock、status。month_sales是冗余字段本来可以从订单表聚合得出但菜品列表页要高频展示实时聚合开销太大所以用冗余字段缓存月销量每次订单成功提交时同步更新保证数据误差在可控范围。订单相关的表拆分成了order表和order_item表。主订单存订单的全局信息user_id、window_id、total_price、status、pickup_code、create_time订单明细存每个菜品和数量。为什么要拆两张表因为一个订单里可能有5种菜每种菜的单价和数量都不一样订单表和菜品表是多对多的关系必须用中间表来连接。status字段用tinyint类型0代表待接单1代表备餐中2代表待取餐3代表已完成4代表已取消。公告表notice存管理员发布的通知App端首页用一个跑马灯形式的横向滚动条展示最新三条。这个功能虽然简单但实际使用中很受欢迎比如今日二楼食堂提前半小时营业这类临时消息能第一时间触达所有用户。4. 实操过程从建库到联调的关键环节4.1 数据库建表与初始化数据开发第一步不是写代码而是建库建表。我用了Navicat连接MySQL先建了名为canteen_order的数据库字符集选了utf8mb4而不是utf8。原因很简单菜品名称里有黄焖鸡米饭biángbiáng面这类生僻字符utf8mb4才能完整支持否则插入数据时会直接报错。在建order表时我踩过一个比较典型的坑。order是MySQL的保留字直接CREATE TABLE order会报语法错误必须写成order_info或者加反引号。我后来统一把所有表名都用下划线命名避免和保留字冲突。初始化数据才是真正花时间的活。我手动录入了三个食堂、八个窗口、八十多条菜品信息每条菜品都配了图片URL。为了测试方便我没有用真实图片而是把图片放在服务端的静态资源目录下用相对路径访问。菜品价格设置成真实的食堂价位区间比如素菜2.5到4块、荤菜5到8块、套餐10到15块这样后面测试订单金额时才贴近真实场景。4.2 服务端接口设计与联调细节服务端接口设计遵循RESTful风格。这里贴几个最核心的接口约定// 接口示例1提交订单 POST /api/order/submit 请求体{ userId: 10086, windowId: 3, remark: 不要香菜, pickupTime: 2025-06-10 12:10, items: [ {dishId: 15, quantity: 2}, {dishId: 17, quantity: 1} ] } 响应{ code: 200, message: success, data: {orderId: 232, pickupCode: 0042} }// 接口示例2查询订单状态 GET /api/order/status?orderId232 响应{ code: 200, data: {status: 2, statusDesc: 待取餐} }联调过程中出过几次典型的对接问题。第一次是前端传的JSON字段名和后端的Java实体属性名不一致前端写的dishId后端实体写成dish_id结果数据一直绑定不上。后来统一约定前端传参一律用驼峰命名后端用JsonProperty注解映射到下划线字段彻底解决这类问题。第二个问题是时间格式。客户端传2025-06-10 12:10这种字符串后端直接用String接收没问题但写进MySQL时Date类型会自动转换。一定要在Spring Boot的application.yml里配好时区参数spring: datasource: url: jdbc:mysql://localhost:3306/canteen_order?useSSLfalseserverTimezoneAsia/Shanghai如果漏了serverTimezone数据库会报差8小时的时间错乱排查起来很隐蔽。4.3 Android端关键代码与UI交互实现Android端用MVP模式分层。View层是Activity和Fragment只负责UI渲染和用户事件回调。Presenter层处理业务逻辑比如用户点提交订单按钮事件传到PresenterPresenter构造请求体、调用Model层的Retrofit接口、处理回调、通知View更新状态。Model层就是Retrofit定义的API接口和实体类。说说购物车这个模块的具体实现。购物车数据保存在本地SQLite的一张cart表中每次用户点击加号先查本地是否有这个菜品的记录有则数量加一没有则插入新记录。同时通知服务端更新购物车缓存服务端缓存的作用是防止用户换手机或清除数据后购物车丢失。结算时客户端直接提交购物车里的数据结算成功后再清空本地和服务端的购物车数据。菜品列表页的加载用了下拉刷新和上拉加载更多。下拉刷新走SwipeRefreshLayout上拉加载用RecyclerView的scrollListener判断滑到底部后请求下一页。分页参数是pageNum和pageSize服务端返回时把总页数放进响应体里客户端判断是否还可以继续加载。网络层的统一处理是我比较满意的一个点。Retrofit的拦截器里做了三件事统一的token校验头、统一的错误码判断、统一的loading弹窗。用户token失效时拦截器收到401错误后自动跳转到登录页并弹出登录已过期提示。这个逻辑如果每个页面都写一遍代码量会爆炸集中到拦截器里才是正道。订单列表页用RecyclerView展示每种状态的订单用不同的背景色区分。待接单是浅灰色备餐中是浅黄色待取餐是浅绿色。用户点进订单详情可以看到完整的菜品清单和状态流转时间。查询订单状态我用的是定时轮询每10秒请求一次接口页面不可见时停止轮询用onStop回调控制。相比WebSocket或者推送轮询虽然不够高级但胜在简单直接对课程项目而言完全够用。5. 常见问题与排查技巧实录5.1 五种高频异常与处理方案开发调试和试运行阶段我遇到过几类高频问题逐一梳理一下解决过程。第一类是图片加载失败。用户反馈菜品列表页大面积白图排查后发现是图片URL写的是IP加端口的形式但测试手机连接的Wi-Fi和服务端不在同一网段。后来统一改成相对路径由客户端根据当前环境拼接完整地址连接本地模拟器时拼10.0.2.2连接真机时拼电脑局域网IP。这算是个环境问题规范做法是把访问地址抽到全局配置类里打包时区分debug和release环境。第二类是并发下单导致库存变负数。测试时我开两个模拟器用同一个账号同时对同一道菜下单结果数据库里库存变成了-3。根因是下单操作不是原子的。后来在dish表加了version字段做乐观锁更新库存的SQL语句改成UPDATE dish SET stock stock - #{num}, version version 1 WHERE id #{id} AND version #{version}如果返回的影响行数为0说明版本过时订单直接失败并提示菜品库存已变化请重新下单。这个方法能解决99%的课程设计级别的并发问题。第三类是订单状态通知不即时。用户提交订单后商家端过了两三分钟才看到新订单。原因是商家端Web页面用setInterval每15秒刷新一次。15秒的延迟对取餐场景来说太久了后来改成WebSocket主动推送服务端订单状态变化时立即推给商家端页面。Android端因为只在用户看订单详情时才需要最新状态保留轮询方案就行。第四类是内存抖动。菜品图片较多导致RecyclerView滚动时一卡一卡的用Profiler卡顿检测发现是图片压缩格式问题。Glide加载大图时会一次性把整张原图解码到内存。解决方案是在服务端统一把菜单图片压到720x540以内客户端加载时再用Glide的override方法二次压缩同时开启Glide的磁盘缓存策略。改完以后滚动流畅度提升明显。第五类是数据精度问题。订单总金额在App端显示两位小数但服务端计算时用float类型累计到一定次数后出现0.01的误差。后来把服务端金额字段全部改成BigDecimal类型客户端传参也改用字符串传金额彻底解决了精度问题。涉及钱的字段浮点类型是绝对的禁区。5.2 排障方法论从现象定位到根因排障不能靠瞎猜我总结了一个三板斧的排查思路先看网络请求通不通再看数据层有没有问题最后看业务逻辑是否真的走到预期分支。第一板斧是看接口请求。我用Android Studio内置的Network Inspector和Charles抓包工具先确认请求体格式、URL拼写、响应码。很多问题其实在第一步就能锁定比如客户端传的参数服务端没收到十有八九是字段名不一致抓包一眼就能看出来。第二板斧是看SQL和日志。服务端日志级别开到DEBUGMyBatis会打印完整的SQL执行语句。有一次订单查询一直返回空列表我看SQL发现多了一个不必要的LEFT JOIN条件把订单关联到了不存在的窗口记录上。通过日志里的SQL文本这类问题能直接定位。第三板斧是复现场景。有些bug偶尔出现记录用户操作路径后可以构造同样场景来复现。比如有用户反馈提交订单时偶发崩溃我分析崩溃日志发现是空指针异常在极端情况下购物车结算时收到了空的菜品ID数组。复现后修复方式是客户端结算前先做非空校验服务端再校验一遍两道防线总比一道好。6. 实操心得与后续扩展思路6.1 界面交互设计的几个加分细节系统功能做完之后我在UI交互上又打磨了几个细节让整个App的体验提升了一个档次。首页顶部的公告跑马灯第一次进App时能看到停留几秒后自动收起避免长期占用空间。食堂列表的营业状态用绿色和灰色圆点直观标识灰色窗口在非营业时间段不可点击并且弹出一个当前不在营业时间的Toast提示。菜品列表里售罄的菜品显示灰色置底效果点击时会提示该菜品已售罄看看别的吧而不是直接无响应。再就是加载中状态的优化。用Skeleton骨架屏替代传统的转圈loading用户在骨架屏上能大致看到列表结构心理等待时间明显缩短。这个改动不大但对用户观感的影响非常直接。6.2 从项目到完整系统的扩展方向做完这个点餐系统后续还能往几个方向迭代。加入推荐算法根据用户的点餐历史做个性化菜品推荐加入取餐提醒推送用极光推送或友盟Push订单状态变化时通知用户加入时段错峰建议基于历史订单数据告诉用户当前食堂预计排队15分钟建议12:30后取餐甚至可以做成小程序的版本学生无需安装App微信里直接扫一扫点单。不过在这里要提醒一句任何扩展都要以稳定性为前提。食堂的就餐高峰期是高并发场景核心下单链路必须稳。宁可先把基础的订单流程打磨到极致也不要为了炫技堆砌太多复杂的功能。功能做得多不如做得稳这是做这类实用型系统最重要的一条心得。我个人在实际开发中还有一个体会系统上线前后要格外重视模拟数据的设计。我当初在菜品库和订单表里造了一批看起来非常真实的模拟数据比如黄焖鸡米饭月售3000份土豆丝月售5200份这让我在调试首页排序、销量聚合、报表展示时效率高了非常多。数据越贴近现实越容易提前暴露边界问题和性能瓶颈。如果大家照着这个思路去搭建自己的点餐系统先从最忙碌的午高峰场景开始压测大部分隐藏问题都会在这个阶段暴露出来。