H-ui与Gradle双端餐饮管理系统：毕业设计全栈复现指南

简介这份毕业设计资源以“溢香园餐饮管理系统”为主题完整覆盖Web管理端与Android客户端适合计算机相关专业学生作为毕设参考、课程设计或二次开发底稿。系统围绕用户管理、菜品管理、订单流转、库存监控、报表分析与评价评分等模块展开涉及前后端分离架构、RESTful API设计、数据库建模、Android网络通信与本地缓存等关键技术点Web端可关注Spring Boot/Node.js等接口层实现Android端涵盖Retrofit、OkHttp、SQLite及推送通知等常见集成方式。压缩包共960个文件、约77MB以Java源码、JSP页面、XML配置、JS/CSS前端样式和Android界面图片为主也包含SQL脚本、PDF与Word说明文档目录结构清晰便于分模块查阅。目前已有125人学习下载适合希望快速搭建餐饮管理原型、借鉴完整项目结构、深入理解全栈开发流程并用于毕业设计答辩展示的读者。1. 溢香园餐饮管理系统H-ui MUI Gradle 的餐饮管理全栈方案拿到一份毕业设计压缩包解压后一半是浏览器CSS框架文件一半是Android构建脚本这种Web端Android端双端毕设项目的典型形态。它不炫技但覆盖了餐饮门店最刚需的三件事点单结账、菜品维护、订单状态跟踪。这个系统定位在餐馆、咖啡厅这类堂食场景前台用Android平板模拟收银终端后厨和店长在Web端看订单进度并维护菜品。技术选型走的是低成本快速成型路线Web端用H-ui这个基于Bootstrap 3的前端框架把后台界面搭起来Android端用Gradle管理依赖两端共用一套RESTful API交换数据。适合两类人来复现一是计算机专业做毕设需要一套能讲清楚数据从前台到后厨是怎么跑的完整案例二是想给门店快速搭一个轻量管理后台、不打算上重型ERP系统的开发者。这个项目价值不在框架多新而在于订单、菜品、库存、用户四个业务域串成了闭环改一改就能落到自己的课程设计里。2. 拆解项目骨架从静态资源反推技术栈、数据库设计与API规范拿到一份只有文件名列表的代码包最忌讳的就是直接双击运行。我先按文件名把技术栈画出来心里有谱了再动手。这一章从资源文件清单出发告诉你怎么快速判断一个未知毕设项目的技术构成以及系统背后的数据模型和接口约定。2.1 资源文件清单里的前端框架线索项目正文只给了十几个文件名信息量已经很大。逐个拆开看文件作用技术线索gradlew.batGradle Wrapper执行脚本Android端使用Gradle构建H-ui.css / H-ui.min.cssH-ui框架核心样式Web端采用H-ui后台管理模板bootstrap.min.cssBootstrap 3样式库H-ui依赖Bootstrap 3style.css自定义样式覆盖层项目定制化主题styletree.css树形菜单样式后台管理左侧树结构font-awesome.cssFont Awesome图标库界面图标方案swiper3.07.min.cssSwiper 3.07轮播组件首页或Banner轮播mui.css / mui.min.cssMUI移动端UI框架Android端或H5页面组件从这张表能读出的第一层信息Web端不是从零手写的它站在三个成熟组件上——H-ui提供后台布局和表格、按钮等基础样式Bootstrap 3负责栅格系统Font Awesome统一图标风格。这种组合在近年来的国内毕设后台项目里非常常见因为H-ui的文档明确写了基于Bootstrap 3兼容IE8用它搭后台几乎不用自己写CSS。第二层信息藏在版本号里。swiper3.07.min.css暴露了Swiper的3.x时代版本这个版本用jQuery插件方式初始化跟5.x以后的原生ES模块写法完全不同。如果项目里出现轮播图初始化语句大概率是$(.swiper-container).swiper({...})而不是new Swiper(.swiper-container, {...})——你只有先对上了版本才能判断一个报错是插件问题还是自己的写法问题。mui.css的存在要分情况看一种是MUI这个移动端UI框架DCloud出品配套的mui.js提供接近原生App的列表和卡片组件另一种是在Web端H-ui后台里作为辅助被引入。判断标准是看Android端有没有用WebView加载HTML页面——如果用了mui.css多半在给WebView页面提供样式它与Android原生UI组件库如Material Design是两条平行线。Gradle方面gradlew.bat是Gradle Wrapper的Windows批处理入口它存在的意义是锁版本。只要项目里有gradle/wrapper/gradle-wrapper.properties构建时就会自动下载该文件里通过distributionUrl指定的Gradle版本不会因为你本地装了更好、更新的版本就翻车。第一次执行gradlew时要保证网络可用因为它会按distributionUrl指向的地址拉取Gradle发行版。提示拿到压缩包后先做一次静态体检把所有css、js、bat文件列成表格比直接读代码快得多几分钟就能判断出项目用的框架组合和大致的前端代码风格。2.2 数据库表设计与订单状态机餐饮管理系统绕不开四个核心业务域用户、菜品、订单、库存。毕设级别的表设计不追求范式完美但状态流转必须自洽。常见做法是按下面这组核心表来还原这个系统user表id、username、password_hash、roleadmin/waiter/customer、nickname、phone、created_at。role是权限判断的唯一依据Web端和Android端登录后拿到的JWT里必须包含它。dishes表id、name、category_id、price、image_url、description、is_selling、stock。is_selling和stock配合完成售罄置灰的前端逻辑is_selling管是否展示stock管是否可下单。orders表id、order_no、user_id、table_no、status、total_amount、remark、created_at、updated_at。status字段驱动整条业务线。order_items表id、order_id、dishes_id、count、price。一单多菜用关联表拆开不能把多个菜名拼进一个字段。category表id、name、sort。菜品分类在Android端点单页上展示为Tab。stock_log表id、dishes_id、change、operate_type、created_at。每次库存变动写一条日志方便对账。订单状态机是整个系统里最容易被讲清楚、也最容易被答辩老师追问的环节。常见做法是六态流转待支付 → 已支付/待接单 → 已接单 → 制作中 → 已出餐 → 已完成。终端用户可以主动取消的只有待支付状态一旦进入已支付取消操作必须走管理员后台审核否则财务对不平。用SQL把状态机落到表里一般给status字段加TINYINT约束并在应用层定义常量CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id INT NOT NULL, table_no VARCHAR(16), status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已接单 3制作中 4已出餐 5已完成 6已取消, total_amount DECIMAL(10,2) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );表设计里有三个易错点。第一total_amount必须用DECIMAL而不能用FLOAT餐饮金额涉及对账浮点误差在累计汇总时会变成对不上的黑匣子。第二order_no建议由应用层生成而不是依赖数据库自增格式取yyyyMMddHHmmss加3位随机数导出报表后直接按订单号排序就是时间顺序。第三status字段不建索引的话后台订单列表页一旦数据超过一万行按状态筛选会明显变慢——答辩时这是个可以主动讲的优化点。2.3 RESTful API接口规范与鉴权方案Web端和Android端共享同一套后端API接口设计决定了联调是否顺利。按RESTful风格核心端点大致如下方法路径功能权限POST/api/auth/login用户登录公开POST/api/auth/register用户注册公开GET/api/dishes获取菜品列表支持category和keyword过滤登录用户POST/api/dishes新增菜品管理员PUT/api/dishes/{id}编辑菜品管理员GET/api/orders按状态拉取订单列表登录用户POST/api/orders提交新订单登录用户PUT/api/orders/{id}/status推进订单状态登录用户DELETE/api/orders/{id}取消订单仅待支付登录用户鉴权方面毕设项目用JWT是最稳妥的选择。流程是登录成功后后端签发一个包含userId和role的JWT客户端把它存在本地Web端放localStorageAndroid端放SharedPreferences每次请求在Authorization: Bearer token头里带上。后端用一个拦截器统一校验不通过就返回401业务代码里不需要每个接口重复写身份判断。在Android端用OkHttp做这件事时通常会加一个拦截器自动附加token而不是在每个请求方法里手动拼头val client OkHttpClient.Builder() .addInterceptor { chain - val token prefs.getString(jwt_token, null) val request if (token ! null) { chain.request().newBuilder() .addHeader(Authorization, Bearer $token) .build() } else { chain.request() } chain.proceed(request) } .build()这段拦截器的逻辑是先从SharedPreferences里取token取到就构建带Authorization头的新请求取不到就放行原请求。价值在于把Token注入收敛到一个地方——如果每个接口自己拼Header后面换成OAuth或刷新Token逻辑时得改几十处而拦截器只需要改这一处。Android端目前主流网络库是Retrofit加OkHttp组合Retrofit负责把接口方法声明转成HTTP请求OkHttp负责底层连接和拦截器上面这段代码就是OkHttp层最常见的用法。到这里技术栈、表结构、接口风格都在脑子里成形了。接下来进入实操环节把Web端页面和核心业务模块真正跑起来。3. 复现核心功能模块Web端页面搭建、菜品管理与订单流转上一章讲的是看文件清单判断项目这一章进入复现一个能用的系统。不把每个页面都铺开讲只挑三个最核心、也最能体现毕设含金量的功能模块Web端页面骨架、菜品管理与库存联动、订单状态流转。3.1 H-ui页面骨架与静态资源加载顺序H-ui框架的页面结构非常固定顶部导航栏、左侧菜单树、中间内容区。一个标准的后台页面骨架长这样!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta http-equivX-UA-Compatible contentIEedge meta nameviewport contentwidthdevice-width, initial-scale1.0 title溢香园餐饮管理系统-后台/title link relstylesheet hreflib/bootstrap.min.css link relstylesheet hreflib/H-ui.min.css link relstylesheet hreflib/font-awesome.css link relstylesheet hreflib/styletree.css link relstylesheet hreflib/style.css /head body nav classnavbar navbar-default H-ui-nav div classcontainer-fluid div classnavbar-header a classnavbar-brand hrefindex.html溢香园后台管理/a /div div classnavbar-right H-ui-nav-user span idcurrentUser/span a hrefjavascript:logout()退出/a /div /div /nav div classH-ui-layout aside classH-ui-aside div classstyletree idmenuTree ul lia hrefdishes.htmli classfa fa-cutlery/i 菜品管理/a/li lia hreforders.htmli classfa fa-list-alt/i 订单管理/a/li lia hrefusers.htmli classfa fa-users/i 用户管理/a/li /ul /div /aside main classH-ui-content !-- 各功能页面渲染位置 -- /main /div script srclib/jquery.min.js/script script srclib/H-ui.min.js/script /body /html这里的加载顺序有讲究bootstrap.min.css必须在H-ui.min.css之前因为H-ui是在Bootstrap基础上做样式覆盖的反过来会让H-ui的栅格和按钮样式失效大半。font-awesome.css放在H-ui后面是安全的它只定义图标字体不会跟H-ui的类名冲突。style.css是项目的自定义覆盖层放在最后才能覆盖框架默认值不用去改动框架源码。HTML骨架把后台最典型的三个区域固定下来navbar是顶部导航H-ui-aside是左侧菜单H-ui-content是内容容器。styletree.css专门管左侧树形菜单的缩进与展开箭头对应的JS初始化一般长这样$(function() { // 初始化左侧树形菜单icon参数指定树节点的展开/收起图标 $(#menuTree).Huitree({ icon: [fa fa-folder, fa fa-folder-open], isOpen: true }); // 从localStorage取登录用户信息渲染到右上角 var user JSON.parse(localStorage.getItem(yxy_user) || {}); if (user.nickname) { $(#currentUser).text(欢迎 user.nickname); } });Huitree方法的两个参数值得注意icon数组里第一项是收起状态的图标第二项是展开状态的图标传的必须是Font Awesome类名isOpen控制树默认是否全部展开菜单超过三层时建议设成false不然页面加载时左侧一长串菜单影响观感。3.2 菜品管理图片上传、库存联动与前端交互菜品管理页是后台使用频率最高的页面操作集中在四个动作新增、编辑、上下架、库存调整。为了不让操作打断流程用弹窗H-ui的layer组件承载表单列表区保持整页刷新交互上更接近真实后台。新增菜品的核心是表单校验、图片上传、JSON数据回填三个环节。图片上传通常先传到服务器指定目录拿到返回的URL再拼进JSON提交不能把图片的本地路径当image_url传给后端——Android端访问Web端接口时拿到相对路径会直接404。function submitDish() { var formData { name: $(#dishName).val().trim(), categoryId: parseInt($(#dishCategory).val()), price: parseFloat($(#dishPrice).val()).toFixed(2), imageUrl: $(#dishImageUrl).val(), description: $(#dishDesc).val().trim(), stock: parseInt($(#dishStock).val()) }; if (!formData.name || isNaN(formData.price) || formData.price 0) { layer.msg(菜品名称和价格必须填写且价格要大于0, {icon: 2}); return; } $.ajax({ url: /api/dishes, type: POST, contentType: application/json, data: JSON.stringify(formData), headers: { Authorization: Bearer localStorage.getItem(yxy_token) }, success: function(res) { if (res.code 0) { layer.msg(保存成功, {icon: 1}); loadDishList(); } else { layer.msg(res.message, {icon: 2}); } }, error: function(xhr) { layer.msg(请求失败请检查网络或登录状态, {icon: 2}); } }); }代码里的几个细节都对应实践中的常见坑price用parseFloat(...).toFixed(2)转成两位小数字符串避免浮点运算在传输层被约简contentType: application/json和JSON.stringify必须成对出现漏掉stringify的话后端接到的会是[object Object]localStorage.getItem(yxy_token)从本地取JWT拼进Authorization头与第2章Android拦截器做的事情完全对称。库存联动是这个模块里最容易翻车的点。菜品展示时如果stock 0前端要把加购按钮置灰同时标注已售罄但后厨依然要在后台看到该菜品并补货。所以是否展示由is_selling字段控制是否可下单由stock字段控制两个字段绝不能合并成一个。页面初始化时调一次loadDishList接口前端按库存状态渲染function loadDishList() { $.get(/api/dishes, function(res) { var items res.data || []; $(#dishTbody).empty(); items.forEach(function(dish) { var isSoldOut dish.stock 0; var row tr td dish.name /td tdimg src dish.imageUrl width50 height50/td td¥ dish.price.toFixed(2) /td td dish.stock /td td (isSoldOut ? span classlabel label-danger已售罄/span : span classlabel label-success在售/span) /td td (isSoldOut ? button classbtn btn-danger btn-sm onclickrestock( dish.id )补货/button : button classbtn btn-primary btn-sm disabled售罄中/button) /td /tr; $(#dishTbody).append(row); }); }); }这段代码把库存状态直接渲染成行内标签和按钮售罄的菜品显示红色已售罄标签和补货按钮在售的菜品显示绿色在售标签和禁用的灰色按钮。虽然把HTML直接拼进jQuery的append不算优雅但毕设后台页面数据量不大引入模板渲染库的成本反而更高。答辩时如果被问为什么不分开可以答菜品量级在百位以内整页重渲染的性能损耗可以忽略。3.3 订单流转从用户下单到出餐确认的状态推进订单模块的核心不是页面而是状态推进。前端展示订单列表时用Tab按状态分组点击接单按钮调用状态机对应的推进接口。整个流转必须依赖后端校验不能只靠前端改一个数字就完事。后端接收推进状态请求时要做两件事校验当前状态是否允许跳转到目标状态、校验操作者有没有对应权限。用一个简单的状态映射表能挡住大部分非法操作# 订单状态机的合法流转表key为当前状态value为可跳转的下一状态集合 STATE_TRANSITIONS { 0: [1, 6], # 待支付 - 已支付 或 已取消 1: [2, 6], # 已支付 - 已接单 或 已取消(管理员) 2: [3], # 已接单 - 制作中 3: [4], # 制作中 - 已出餐 4: [5], # 已出餐 - 已完成 5: [], # 已完成终态 6: [] # 已取消终态 } def advance_order(current_status: int, target_status: int) - bool: if target_status not in STATE_TRANSITIONS.get(current_status, []): return False return True这段Python示例用面向过程写法方便在答辩时讲清状态机是一张表不是一个if-else堆出来的判断树。STATE_TRANSITIONS字典里每个value都是一个列表代表当前状态能合法跳转到哪些状态用户在待支付时可以取消0→6但支付后取消1→6就必须是管理员操作所以1对应的列表里虽然有6但接口层要额外校验操作者角色。订单列表查询页通常是整个系统里压力最大的接口因为Web端和Android端都会频繁轮询它。Android端点单页的轮询间隔建议放在3到5秒太短会把后端压垮太长用户体验卡顿。下拉刷新是更省资源的方案只在用户主动操作时重新拉取。轮询请求里有一个非常典型的优化点按状态分接口。GET /api/orders?status1只返回待接单列表GET /api/orders?status5只返回已完成列表比GET /api/orders返回全量数据再在前端过滤省掉大量网络流量。后厨平板端只需要关心待接单和制作中的订单把查询条件压到待处理范围内接口响应时间能明显降下来。4. 避坑指南餐饮管理系统复现中的五个典型问题把一份毕设项目从压缩包变成能跑的系统踩坑是常态。下面五条是我在拆这类双端项目时反复遇见的每条都按现象、原因、解决三个层面说透。4.1 gradlew.bat 执行即报错Gradle 版本不匹配现象在Windows上双击gradlew.bat窗口闪一下就退或者输出Could not determine java version from 11.0.2构建直接中断。换一台高版本JDK的机器报错内容可能变成Unsupported class file major version。原因gradlew.bat本身只是壳真正决定构建行为的在gradle/wrapper/gradle-wrapper.properties文件里。这个文件用distributionUrl指定的Gradle版本如果跟本地JDK大版本冲突比如Gradle 4.x遇到JDK 11以上wrapper会在环境检测阶段挂掉。另一种常见情况是distributionUrl指向的地址网络受限wrapper下载不到指定的发行版。很多毕设源码的wrapper配置是当年作者本机环境生成的换一台机器环境差异就炸。解决先打开gradle-wrapper.properties确认distributionUrl里的版本号再执行java -version看本地JDK版本。Gradle与JDK的匹配关系大体是Gradle 6.x配JDK 8到11Gradle 7.x配JDK 11到17Gradle 8.x配JDK 17。本地JDK版本过高时两种方案任选装回匹配的JDK或者改distributionUrl指向与JDK匹配的更高Gradle版本。改完wrapper后最好删掉项目根目录的.gradle缓存文件夹再重跑否则旧缓存还会干扰构建。4.2 页面样式全乱CSS 加载顺序被引擎忽略现象页面能打开但导航栏没有底色、按钮圆角消失、图标全变成小方块左侧菜单点不开。最诡异的是HTML源码里每个文件都在控制台也没有404。原因link标签的引入顺序错了。H-ui基于Bootstrap顺序必须是Bootstrap在前、H-ui在后如果先加载H-ui.css再加载BootstrapH-ui的样式会被Bootstrap的同类规则覆盖框架UI特征全部丢失。图标小方块则是font-awesome.css缺失或路径写错图标字体加载失败后文本会回退到系统占位符。解决把link统一调整成这个顺序bootstrap.min.css → H-ui.min.css → style.css → font-awesome.css → styletree.css → swiper3.07.min.css。font-awesome还依赖fonts目录下的字体文件检查fonts/fontawesome-webfont.woff2是否存在路径缺失时图标照样显示为方块。记住一个原则框架级样式在前、组件级样式次之、项目自定义样式永远放最后。4.3 中文字段全变问号数据库字符集没设对现象后台添加菜品宫保鸡丁后Web端列表显示正常但Android端拉到菜品名变成乱码或直接显示问号。有时候两端都正常导出SQL备份再导入新库后乱码。原因典型是数据库连接串没指定characterEncodingutf8或者建表时表级字符集继承自库级默认的latin1。旧库导出的SQL文件头部如果写着SET NAMES latin1导入新库时会把中文数据洗一遍。MUI和H-ui默认都是UTF-8编码的页面但后端连接MySQL若没指定字符集JDBC会按平台默认编码读数据中文在两端表现就分裂了。解决确认三处字符集统一为utf8mb4。第一处建库语句CREATE DATABASE yxy_db DEFAULT CHARACTER SET utf8mb4;。第二处连接串显式加参数例如jdbc:mysql://localhost:3306/yxy_db?useUnicodetruecharacterEncodingutf8。第三处Android端网络库解析响应时指定UTF-8Retrofit的GsonConverterFactory默认按UTF-8读但如果手动用response.body().string()且服务端响应头没带charset就有概率读成平台默认编码。SQL文件导入前先执行SET NAMES utf8mb4;能规避九成备份恢复乱码问题。4.4 Android 端和 Web 端数据对不上连接的是两套环境现象Web端能登录、能下单Android端却提示网络错误或登录接口404。同一个WiFi下Android模拟器访问http://localhost:8080/api直接失败。原因这几乎是毕设联调必踩的坑。Android模拟器里的localhost指向模拟器自身而不是宿主机真机调试时localhost指向手机自己。Web端代码写的是localhost:8080Android端代码照抄了一份结果请求打到设备本机的8080端口上当然什么都没有。Android端报的404并不是接口不存在而是压根连错了主机。解决手机和电脑连同一个局域网Android端API基地址改成电脑在局域网内的IP比如http://192.168.1.105:8080模拟器可以用http://10.0.2.2:8080访问宿主机。还要确认后端服务监听了0.0.0.0而不是默认的127.0.0.1否则局域网内其他设备连不进来。把API基地址放到Android的BuildConfig或gradle.properties里不要写死在Activity字符串里——多人拿同一份源码联调时环境差异只会集中在配置部分。4.5 浏览器拦截 Ajax 请求CORS 跨域不是后端一个注解能解决的事现象Web端页面里用jQuery发Ajax请求到后端控制台报Access to XMLHttpRequest at ... has been blocked by CORS policy请求根本没进后端业务代码。原因浏览器同源策略拦截了跨域请求。后端如果只设置Access-Control-Allow-Origin: *响应头遇到项目里自定义的Authorization头时会被CORS预检请求OPTIONS卡住。预检要求后端明确声明Access-Control-Allow-Headers: Authorization否则浏览器认为跨域不安全整个请求直接拦截。解决开发阶段用代理转发最省心。以常见的Vite或webpack-dev-server为例把/api路径代理到后端地址前端代码里继续写相对路径/api/xxx由开发服务器转发浏览器看到的就是同源请求。如果没有代理后端要在全局CORS配置里同时允许Authorization头、Content-Type头并显式放行OPTIONS方法// 以Spring Boot全局CORS配置为例覆盖所有API接口 Configuration public class CorsConfig { Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurer() { Override public void addCorsMappings(Registry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(Authorization, Content-Type) .allowCredentials(true); } }; } }这段配置的关键在于allowedHeaders把Authorization显式加进去而不是写*通配。allowCredentials(true)表示允许携带Cookie凭证但注意这个配置对Origin有限制不能再用简单的*而要换成allowedOriginPatterns(*)。另外addMapping(/api/**)限定了路径范围比直接配/**更安全登录外的静态资源不该被跨域放开。5. Android端联调与源码管理用抓包验证数据流、用版本控制兜底5.1 用 Fiddler 抓包验证 Android 端与 Web 端的数据一致性双端系统最怕Web端能用、Android端数据不对这种黑盒问题。与其来回猜不如用Fiddler抓包直接看两边发出的HTTP请求是否一致。操作流程Fiddler开启HTTPS解密并允许远程连接手机WiFi代理指向电脑IP和8888端口然后在Android端依次执行登录、拉菜单、下单三个操作抓到的请求会按域名分组列在面板里。对比Web端和Android端的抓包结果重点看三个位置URL路径是否一致、Authorization头里的Token是否有效、请求体里的JSON字段名是否匹配。最常见的现象是Android端传的是{userName: tom}Web端传的是{username: tom}字段名差一个字母后端就只认一端——这种问题看抓包面板一眼就能定位不用改代码反复试。5.2 借此机会把源码管理捡起来对接过几份毕设源码之后我有一个习惯改不掉了解压任何项目先git init提交一个初始版本再开始改代码。这套做法的价值体现在两个场景改坏了一处功能想回到昨天能跑的状态git checkout -- .一条命令的事答辩老师问代码是不是自己写的打开git log给他看提交历史比解释一万句都管用。整个项目跑通之后服务端、Web端、Android端三部分的配置要点其实都收敛到几个文件里服务端看application.properties里的数据源和端口Web端看config.js里的API地址Android端看gradle.properties里的构建配置。从那以后我每次拆新项目都强制走一遍先体检、后跑通、再改代码的流程——先看文件名清单判断技术栈再按依赖顺序搭环境最后用抓包工具确认两端数据一致。项目能跑只是及格能讲清楚每个状态为什么这样流转、每个接口为什么这样设计才是毕设答辩里真正拉开差距的地方。希望帮到你。本文还有配套的精品资源点击获取