餐饮管理系统双端联调实战：从Spring Boot后端到Android客户端的关键避坑指南

简介溢香园餐饮管理系统是一套面向高校毕业设计与课程设计的完整项目兼顾Web管理端与Android客户端适合需要完成餐饮类选题的学生参考。压缩包共960个文件约77MB文件类型涵盖125个Java源码、37个JSP页面、89个XML配置、35个JS与35个CSS前端资源、16个JAR依赖库以及1个SQL数据库脚本和14个PDF、12个DOCX项目文档另有大量PNG/GIF界面截图便于直观理解系统运行效果。功能上覆盖用户管理、菜品管理、订单处理、库存监控、报表分析和评论评分等核心模块并涉及JWT身份验证、SQLite本地缓存、RESTful API设计、云服务器部署等工程实践。已有125人学习浏览对于想快速搭建前后端分离架构、复用完整代码结构、界面素材与文档资料的同学来说是一份可操作性较强的参考资料。1. 溢香园餐饮管理系统一套双端业务三种打开方式花几天时间把一个“毕业设计-溢香园餐饮管理系统(web端Android端).zip”跑起来是拿到压缩包后的第一个念头。这个包听起来像作业拆开看其实是典型的小型餐饮SaaS原型Web端负责管理后台的菜品、桌台、订单与报表Android端负责移动侧的点餐和服务操作两头共享同一套业务逻辑。它的价值不在于代码量而在于“同一张订单在Web和Android两端怎么流转、怎么不错乱”这件事本身。适合三类人准备答辩、需要快速把项目跑起来并讲清楚架构的学生想拿它当底座改造成真实门店系统的开发者以及刚学完Spring Boot和Android、想找一份完整双端联调样例的初学者。如果你只是想要一个能点菜的App这套系统反而偏重——它的重点从来不是某个界面多好看而是数据怎么在两端之间保持一致。2. 把双端系统拆开看技术选型与数据流先于代码拿到zip先别急着解压运行先想清楚它是什么结构。“毕业设计”四个字意味着技术选型通常偏教学场景而非生产场景。常见做法是Spring Boot单体后端加上一个Web管理端和一个Android客户端业务全部收敛到一组REST接口里。你先把这个结构认出来后面所有修改才有落脚点。2.1 双端共用后端的单体架构接口约定是命门最常见的布局是后端一个工程Spring Boot或SSMWeb端可能是前后端分离的Vue工程也可能是服务端渲染的Thymeleaf/JSPAndroid端是原生Java/Kotlin工程用Retrofit或OkHttp调后端接口。判断方法很简单解压后找三种文件pom.xml或build.gradle代表后端package.json代表Web前端工程Android目录下会再出现一份build.gradle。不管两端长什么样一个事实不会变所有业务都共用同一套后端接口。这意味着接口约定是整个系统的命门。登录接口返回什么字段、订单接口接收什么参数、状态变更用哪个字段表达只要约定乱掉Web端和Android端必然有一个先翻车。拿到项目后第一件事不是读代码而是把Controller层的接口清单拉出来确认五个核心接口登录、菜品列表、提交订单、变更订单状态、结账。这份清单决定了后面所有联调工作怎么展开。接口请求方向核心参数返回要点登录Web/Android → 后端username, passwordtoken、角色、用户信息菜品列表Web/Android → 后端categoryId 可选菜品id、名称、价格、状态提交订单Web/Android → 后端tableId, items[{dishId, quantity}]orderNo、订单id变更订单状态Web/Android → 后端orderId, targetStatus最新状态结账Web/Android → 后端orderId, payType支付结果、桌台释放状态我一般会把这份清单画在一张纸上然后才开始碰代码。清单里任何一项对不上的都是后面联调时的定时炸弹。2.2 餐饮业务的核心表菜品、桌台、订单与明细接口的本质是对数据的操作所以表结构决定了接口能干什么。一个餐饮管理系统的核心表通常不超过六张菜品表、桌台表、订单主表、订单明细表、用户表外加一张分类表。订单相关是重点先看一套可复用的建表脚本-- 菜品表 CREATE TABLE dish ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, category_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 1, -- 1上架 0下架 image_url VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 桌台表 CREATE TABLE table_seat ( id INT PRIMARY KEY AUTO_INCREMENT, seat_no VARCHAR(16) NOT NULL, capacity INT DEFAULT 4, status TINYINT DEFAULT 0 -- 0空闲 1占用 2已预订 ); -- 订单主表 CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, table_id INT NOT NULL, status TINYINT DEFAULT 0, -- 0待确认 1制作中 2已完成 3已结账 4已取消 total_amount DECIMAL(10,2) DEFAULT 0, pay_type TINYINT DEFAULT 0, -- 0未支付 1微信 2支付宝 3现金 remark VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 订单明细表 CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, dish_id INT NOT NULL, dish_name VARCHAR(64) NOT NULL, -- 冗余菜品名快照 price DECIMAL(10,2) NOT NULL, -- 下单时价格快照 quantity INT NOT NULL );这里有两个细节值得注意。第一订单明细表冗余了dish_name和price这是故意的。菜品今天卖18元明天可能调到20元但历史订单必须保留下单那一刻的名字和价格否则财务报表对不上。第二订单状态用TINYINT而不是VARCHAR状态流转用数字表达代码里用常量或枚举做映射比直接存中文“制作中”要稳妥得多——数据库排序、接口传输、条件查询都更干净。orders.status和table_seat.status是两个独立字段这是常见的认知误区。订单状态管的是这笔订单走到哪一步桌台状态管的是这张桌子当前有没有人。结账动作同时改这两个字段但它们是两回事。如果合并成一个状态就会出现“菜还没上齐桌子已经被释放”的尴尬局面。2.3 角色与权限管理员、服务员、后厨的边界权限设计不能粗暴地做成“Web是管理员Android是服务员”。真实门店至少分三端管理员在后厨看板或办公室管菜品和报表服务员在现场开台、点餐、结账后厨只看待制作订单。常见的做法是为每个接口标注角色要求后端用拦截器统一校验。// 登录成功后生成token角色写进token后续每个请求带着 String token JWT.create() .withClaim(userId, user.getId()) .withClaim(role, user.getRole()) // admin / waiter / chef .withExpiresAt(new Date(System.currentTimeMillis() 2 * 3600 * 1000)) .sign(Algorithm.HMAC256(secret)); // 拦截器里做角色校验而不是把逻辑散落在每个Controller里 String role JwtUtil.getRole(request); if (!requiredRoles.contains(role)) { throw new AuthException(角色无权限); }角色判断写进拦截器而不是在每个Controller里复制粘贴是我强烈建议保持的做法。毕业设计里最常见的改造需求就是“加一个库存管理模块”如果权限判断散落在几十个接口里每加一个功能就要改一圈。拦截器收敛之后新增接口只需要在注解里声明允许哪些角色。接口鉴权做不好Web端和Android端都能越权访问这一类系统最常见的web安全漏洞就是这么来的。3. 从 zip 到能跑的本地环境数据库初始化与后端启动这个阶段的目标不是理解代码而是“让后端先跑起来让登录接口返回token”。我一般按三步走目录识别、数据库初始化、后端启动自测。每一步都有坑每一步都有后悔药——改配置之前先备份数据库误删了还能回头。3.1 先摸清目录结构三个工程与一份数据库脚本解压后不要双击就完事先用命令行打开看顶层结构。常见做法是压缩包里至少包含四个东西后端目录、Web前端目录、Android工程目录、数据库脚本文件。unzip 毕业设计-溢香园餐饮管理系统(web端Android端).zip -d yixiangyuan cd yixiangyuan find . -maxdepth 2 -type d | sort这条命令会把两层目录结构全部打出来。接下来你要确认的不是目录名好不好看而是三件事后端是不是Maven工程有没有pom.xmlWeb端是不是Node工程有没有package.jsonAndroid端能不能被Android Studio直接识别有没有build.gradle。这三个文件决定了你要装哪些工具链。如果find结果里只有后端目录没有前端目录说明Web端可能是服务端渲染页面模板在后端工程里如果有package.json那就是前后端分离需要另行启动一个Node服务。这个判断直接影响第3.4节的启动顺序。3.2 数据库初始化脚本执行与连接串修改找到.sql文件后用命令行导入比用Navicat图形界面更能看清报错。mysql -u root -p sql/init.sql mysql -u root -p -e SHOW TABLES; yixiangyuan第二步的SHOW TABLES是验证表是否齐全的最快方式。如果表数量对不上八成是脚本里有重复执行或外键依赖顺序问题逐个检查报错信息即可。数据库起来后改后端配置。这里最常翻车的是MySQL 8的时区问题。spring: datasource: url: jdbc:mysql://localhost:3306/yixiangyuan?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 username: root password: 123456 servlet: multipart: max-file-size: 10MB server: port: 8080 servlet: context-path: /apiserverTimezoneAsia/Shanghai不设的话MySQL 8驱动会直接报UTC时区错误这是新手最常遇到的第一个启动失败。context-path: /api决定所有接口的前缀Android端的BaseURL必须和它严格一致后面第5章还会回来讲这个问题。multipart.max-file-size是给菜品图片上传留的余量不配的话默认1MB一张手机照片就超限。注意执行数据库脚本前先确认库里没有同名表。反复改表结构时用mysqldump -u root -p yixiangyuan backup.sql先备份一次这是最便宜的后悔药。3.3 后端启动与接口自测登录接口不报错才算跑通启动命令本身很简单难的是判断“到底起没起来”。mvn spring-boot:run # 或者打好的jar包 java -jar target/yixiangyuan-0.0.1-SNAPSHOT.jar看到Started日志不代表万事大吉。验证方式是直接打登录接口curl -X POST http://localhost:8080/api/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}返回里有token说明数据库连接、接口映射、拦截器链路全部通了。如果报404优先查context-path是否匹配如果报500看控制台有没有打印SQL——MyBatis常见配置是打印执行的SQL把SQL复制到Navicat里跑一遍能快速定位是表名映射错了还是字段拼错了。这一步值得认真做因为后面Web端和Android端所有的请求都建立在登录接口能用的前提下。3.4 Web端与Android端的启动顺序后端起着别急着开Web端和Android端。我的习惯是“后端先行前端验证Android最后”——Android端一旦跑起来报错信息最密集应该留到最后单独处理。cd web npm install npm run devnpm install在这里是最大的不确定性来源。Node版本和依赖锁版本不匹配是常事报错时先看是不是registry源的问题把源切到国内镜像能解决大部分情况。Android端则用Android Studio打开工程目录等Gradle同步完成再尝试构建。这一步不要急Gradle首次同步下载依赖可能要十几分钟中途断网会留下半截缓存清掉~/.gradle/caches再重来就行。4. Web端改造登录态、订单流转与后厨展示的实战修改环境跑通只是热身。真正会让用户盯着的修改点集中在三个地方登录态怎么续、订单状态怎么流转、后厨页面怎么实时刷新。这三个点也是企业级web开发里最常被追问的细节。4.1 登录态与 Token 刷新别让客人吃饭到一半被踢下线毕业设计里最常见的登录实现是登录后存token过期就弹“登录已过期”用户重新登录。单机演示没问题真实门店场景不能这么干——服务员正给客人下单突然被踢下线这顿饭就结不了。常见的方案是双tokenaccessToken有效期两小时refreshToken有效期七天前端在请求返回401时用refreshToken静默续期。// request.js - axios 响应拦截器 axios.interceptors.response.use( res res, async err { const original err.config if (err.response err.response.status 401 !original._retry) { original._retry true try { const refreshed await axios.post(/refresh, { refreshToken: localStorage.getItem(refreshToken) }) localStorage.setItem(accessToken, refreshed.data.accessToken) original.headers.Authorization Bearer refreshed.data.accessToken return axios(original) } catch (e) { // refreshToken 也失效跳回登录页 window.location.href /login } } return Promise.reject(err) } )original._retry true这个标志位不能省否则401响应会触发无限循环请求。后端要配套一个/refresh接口校验refreshToken时把用户角色重新读一遍——用户权限可能在七天内变过不能直接信任旧信息。这套逻辑改完Web端和Android端的登录态处理就统一了Android端用OkHttp的拦截器写同样的逻辑。4.2 订单状态机用一张状态转移表管住整条链路点餐系统最怕的状态问题是“后厨标记完成前台还在等菜”。根源是状态流转没有约束谁都能把status改成任意值。常见做法是把状态变更收敛到一个服务方法里禁止在Controller里直接拼update status。public void changeStatus(Long orderId, int targetStatus) { Order order orderMapper.findById(orderId); if (order null) { throw new BizException(订单不存在); } // 只允许0待确认 - 1制作中 - 2已完成 - 3已结账0待确认 - 4已取消 int[][] allowed {{0, 1}, {1, 2}, {2, 3}, {0, 4}}; boolean ok Arrays.stream(allowed) .anyMatch(p - p[0] order.getStatus() p[1] targetStatus); if (!ok) { throw new BizException(非法状态流转: order.getStatus() - targetStatus); } orderMapper.updateStatus(orderId, targetStatus, new Date()); }用二维数组定义状态转移表简单、可读、可扩展。以后要加“已退款”状态往数组里加一组{3, 5}就行。毕业设计里翻车的写法是散装if (status 1) status 2三天后自己都看不懂哪里漏了判断。另外注意这个方法的返回值应该带出最新的订单状态方便前端刷新页面状态。4.3 后厨大屏的数据刷新轮询换 WebSocket 的取舍Web端如果有个后厨展示页通常的做法是每5秒轮询一次待办订单接口。能跑但有两个毛病订单多时请求密集状态变更后最多延迟5秒才显示。订单少的小店无所谓但想做得专业一点WebSocket是更合适的方案。Spring Boot原生支持WebSocket不需要额外引入重量级框架。Component public class OrderPushService { private final SetWebSocketSession sessions ConcurrentHashMap.newKeySet(); public void register(WebSocketSession session) { sessions.add(session); } public void broadcast(String message) { sessions.forEach(session - { try { session.sendMessage(new TextMessage(message)); } catch (IOException e) { // 单个连接断开不影响其他连接 sessions.remove(session); } }); } }前端连ws://localhost:8080/api/ws/order后端在订单状态变更时调用broadcast推送最新状态。这里的取舍很清楚门店桌台少于20张、并发订单少轮询完全够用要做后厨大屏、扫码点餐这类对实时性有感知的场景再上WebSocket。一个容易被忽略的坑是Nginx代理——WebSocket握手需要配置Upgrade和Connection请求头否则本地跑得好好的部署到服务器就断连。如果项目里没有运维条件第一次部署时宁可用轮询。5. 双端联调避坑四个高频翻车点与排查顺序Web端跑通只解决了一半问题。Android端能连上后端、能正常下单这个项目才算真正完整。如果你是从别人手里移植Android Studio项目过来以下四条是我每次接手都会先查的点。Android端的问题往往不是代码写得不对而是“开发环境和你以为的环境”不一样。5.1 模拟器能通、真机必挂10.0.2.2 与局域网 IP现象Android模拟器里点餐接口一切正常装到真机上请求全部超时。原因模拟器把10.0.2.2映射到宿主机localhost真机没有这层映射。真机必须用电脑在局域网里的实际IP。解决先把本机IP查出来再把它填到Android端的网络请求BaseURL里。# Windows ipconfig # macOS / Linux ifconfig en0让手机和电脑连同一个Wi-Fi然后用查到的IPv4地址替换BaseURL。这里有个更稳的做法把BaseURL提取到BuildConfig字段里debug构建走局域网IPrelease构建走服务器域名不要写死在代码里。另外记得检查电脑防火墙8080端口没放行的话真机请求会被拦在门外。5.2 Android 9 明文流量被拦偶尔也讲点玄学现象接口请求报Cleartext HTTP traffic not permitted后端明明好好的。原因Android 9API 28开始默认禁止明文HTTP流量。毕业设计的后端接口通常是http://而不是https://自然被系统拦下来。这个报错第一次遇到时会觉得是玄学其实就是一行配置的事。解决在AndroidManifest.xml的application标签里放开明文流量。application android:usesCleartextTraffictrue android:networkSecurityConfigxml/network_security_config ... /application如果只想对开发环境放行用network_security_config单独配置只允许局域网IP走明文其他域名强制HTTPS。release包建议不要全量放开明文流量否则应用市场审核会有安全提示。提示改完AndroidManifest.xml必须完整卸载重装App光点“重新运行”不会生效。这个细节能省你半小时排查时间。5.3 FileProvider 与图片上传content:// 路径崩溃现象拍照或从相册选图后上传App直接崩溃日志里出现FileUriExposedException或content://解析失败。原因Android 7 不允许App直接通过file://把文件路径暴露给其他应用必须用FileProvider生成content://形式的URI。很多旧教程还在贴file://的写法照抄就翻车。解决在Manifest里注册FileProvider并在res/xml/file_paths.xml里声明可访问的路径。provider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /providerfile_paths.xml里要覆盖你实际用到的目录拍照的缓存目录和相册目录是两回事。最常见的坑是只配了cache-path从相册选图时还是崩——因为相册文件的路径在external-path下。两个都配上问题基本消失。5.4 端口、时区与静态资源后端“启动成功”但前端白屏现象后端日志显示Started但浏览器打开白屏或者接口全部404。原因三类情况叠加——端口被占用、context-path和请求地址对不上、前端环境变量写死了端口。毕业设计最常用8080而8080恰恰是本机其他服务最爱占用的端口。解决先查端口再对齐路径。netstat -ano | findstr :8080 # Windows lsof -i :8080 # macOS / Linux查完端口后确认前端请求的baseURL是不是http://localhost:8080/apicontext-path一旦设置所有Controller的路径都要带/api前缀。改完后端端口Web端的代理配置和Android端的BaseURL要跟着一起改。这三处不统一就会出现“后端起来了但前后端谁也找不到谁”的尴尬局面。6. 用一条完整订单链路验收双端从开台到结账的关键操作所有模块都改完后不要只测单个接口。我每次验收都会走一遍“开台→点菜→后厨制作→出菜→结账”的完整链路任何一个环节两端数据不一致立刻就能暴露问题。下面的表格是验收清单你可以直接照着过。步骤操作预期结果开台Android端选择桌台并设为占用Web后台桌台状态变红显示“占用”点菜Android端提交2个菜品订单后端orders和order_item各新增一条记录后厨确认Web后厨页确认制作订单状态从0变为1Android端可见“制作中”出菜Web后厨页标记完成状态从1变为2订单金额与明细合计一致结账Web端或Android端执行结账状态从2变为3桌台释放回“空闲”验收时盯住数据库里的orders.status字段变化这是最笨但最可靠的办法。前后端任何一处“看不到变化”立刻能定位是推送没到还是查询条件写错。# 快速验证订单状态变更的核心接口 curl -X POST http://localhost:8080/api/order/1/status \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -d {targetStatus:1}这条请求跑通后再看Web端和Android端有没有同步刷新。如果Android端看不到状态变化多半是接口返回后没有重新拉取订单详情而不是后端的问题。我的习惯是验收前先给数据库做一次dump双端联调几轮下来总有改坏数据的时候备份永远是最靠谱的后悔药。整套流程走完再把图片上传、报表导出这些边角功能过一遍才算真正吃透了这套系统。希望帮到你。本文还有配套的精品资源点击获取