1. 项目从哪儿来这个毕设到底要做什么先说点实际的。每年计算机毕业设计外卖和订餐类题目能占很大一块原因很简单业务链路完整、需求好理解、技术点覆盖全面。从用户注册登录、浏览餐厅和菜品、加入购物车、提交订单、在线支付到餐厅端接单、出餐、配送状态流转再到订单历史、评价体系这一整套流程做下来后端、移动端、数据库、接口设计全都能练到不管是做技术选型还是写毕业论文素材都够扎实。这个题目本身叫“客达外卖系统APP”关键词是Java、Android、移动端核心定位是“智慧餐饮配送服务平台”。翻译成人话就是用户拿手机点餐商家在后台管菜和订单骑手或商家自己完成配送整个过程在一套系统里闭环。平台侧还要能看数据、管用户、管餐厅。这是一个典型的“多端多角色全流程”项目比起只做一个增删改查的管理系统含金量高不少。我当时做同类项目时最深的感受是毕设难的不是某个技术点而是把整条业务链路串起来。很多同学卡在“每个功能单独都会但合在一起就乱”。所以这篇博文就从整体架构、数据库设计、核心流程、带坑实录几个层面来拆每一步都告诉你为什么这么做而不是只贴代码。无论你是刚开始选题还是代码写了一多半正在调BUG这篇都能帮你把思路理顺。2. 整体设计与技术选型不要一上来就写代码2.1 架构层面先想清楚四件事接到这个题目后我的习惯是先不做技术选型先把这个项目“是什么”想清楚。拆解一下这个系统至少要覆盖四个端用户端注册登录、浏览餐厅、查看菜品、加入购物车、下单支付、订单跟踪、评价。餐厅端菜品管理、订单接单/出餐、营业状态设置、基础信息维护。配送端配送单查看、状态更新取餐、送达。管理后台用户管理、餐厅审核、订单查看、数据统计。这四个端之间不是各自独立的它们共享同一个核心——订单数据。用户下了一单餐厅要看到新订单骑手要看到待配送订单管理员要能看到全平台订单流水。如果一开始没把数据流想清楚后面各端各写各的联调的时候一定会炸。我看过不少毕设代码最常见的问题就是用户端功能一堆但订单状态只有“未支付”和“已支付”两个字段商家端根本没法接单。这种项目答辩时一问就露馅。所以做这个项目我建议你要么把平台定位成“平台自营配送商家入驻”要么做成“商家自配送”二选一。这样角色和数据流才能闭环。我当时选的是“商家入驻平台调度骑手”的模式在答辩时更好讲因为有3个角色、状态流转更复杂体现工作量。但如果你时间紧做成“商家自配送”会少一个配送端能省不少事。2.2 技术栈选型Java、Android、后端框架怎么搭配这个题目标签里有Java、Android热词里也有Android Studio、java面试、移动端性能优化所以技术路线的方向基本是定了的移动端原生Android开发Java语言。IDE用Android Studio构建工具用Gradle。后端Java系。在毕设场景下SSMSpring SpringMVC MyBatis和Spring Boot是两条主流路线。数据库MySQL文本字段多的比如菜品描述、备注可以用VARCHAR图片用URL路径存储不要直接存大字段。接口风格RESTful APIJSON格式交互。图片资源本地存储方案项目下建upload目录或者OSS毕设建议本地存储就行简单可控。为什么这里强调原生Android而不是跨平台方案两个原因。第一题目明确写了“基于Android平台”你如果用Flutter、React Native答辩时评审老师第一句就会问“你选型为什么不贴合题目”。第二毕设的场景下原生开发能把Java知识点全串起来Activity生命周期、RecyclerView适配器、网络请求、多线程、SQLite、SharedPreferences、广播和Service这些都是java面试里高频的问题做完一个项目等于把这些知识点全都实操了一遍。后端选SSM还是Spring Boot我做的是Spring Boot MyBatis Plus原因很现实SSM的XML配置太繁琐写500行能做好的事情没必要写成2000行配置。Spring Boot自动配置、内嵌Tomcat部署也简单在毕设答辩时还能讲清楚“自动配置原理”这种亮点问题。MyBatis Plus在单表CRUD上连SQL都不用写可以省出大量时间去写订单流程和权限控制。如果你担心“太方便了会不会显得没有技术含量”其实不用慌——真正体现水平的是业务逻辑的完整性和代码结构不是手写SQL的数量。2.3 前后端交互协议设计移动端和后端的交互协议我推荐直接使用JSON over HTTP不用WebSocket原因很简单外卖场景下实时性要求没有聊天那么高轮询已经足够应付。用户端每秒或每5秒刷新一次订单状态餐厅端也一样服务器压力完全扛得住。接口设计上有一个关键决策统一返回体。我当时定义了一个Result类结构是这样的public class ResultT { private Integer code; // 200 成功400 参数错误401 未登录500 服务异常 private String message; private T data; }所有接口都返回这个结构Android端解析时只需要判断code不用每个接口都去做异常分支。这个设计在联调阶段帮我省了大量时间。很多同学接口返回格式不统一一会儿返回一个Map一会儿返回一个字符串Android端解析逻辑写得像八爪鱼——这是完全可以避免的。关于网络框架Android端我用的OkHttp Retrofit Gson。Retrofit处理注解和接口定义非常舒服配合GsonConverterFactory直接就能把JSON转成实体类。当然也有同学用Volley也可以但Retrofit在毕设答辩时讲起来更有深度——它是一个“基于OkHttp的RESTful网络请求框架”这句话一出来评审对网路层的疑问基本就没了。3. 数据库设计与核心业务模型先把底子打好3.1 核心表结构设计数据库是这个项目的命脉。表设计不对后面写代码全是补丁。我这版设计基于“用户端商家端平台骑手”三者模型一共设计了9张核心表列一下各自的职责和关键字段表名核心字段职责说明userid, username, password, phone, avatar, role用户表role字段区分普通用户/商家管理员/骑手/平台管理员restaurantid, user_id, name, address, avg_price, rating, status餐厅表user_id外键指向管理员账号categoryid, restaurant_id, name, sort菜品分类表一个餐厅多个分类dishid, restaurant_id, category_id, name, price, image, description, sales菜品表cartid, user_id, dish_id, quantity, checked购物车表记录未下单的临时选择ordersid, order_no, user_id, restaurant_id, total_amount, status, address, create_time订单主表order_itemid, order_id, dish_id, dish_name, price, quantity订单明细表下单时把菜品信息快照进来addressid, user_id, receiver_name, phone, detail收货地址表commentid, order_id, user_id, rating, content评价表这9张表的关系画出来就清晰了users是地基restaurant通过user_id关联restaurant下面挂category和dishcart记录用户对dish的临时关系orders作为核心枢纽关联user和restaurantorder_item作为订单快照记录下单时的菜品信息address和comment作为辅助。这里要特别强调order_item的设计理念。很多初学者会把订单表直接存一个“菜品列表”字段或者通过JSON字符串存到orders表里。这样做看似简单但有两个致命问题第一菜品价格是变动的今天下单时10块钱的菜明天调价成12块你订单里应该显示什么价答案是必须显示下单时的价格所以要把“菜品名称下单价格数量”快照到order_item表。第二SQL统计订单明细时拆不出菜品的维度数据。我之前看过一个同学的毕设订单用逗号拼接菜品字符串存储答辩老师让他统计“销量TOP5菜品”他写完SQL直接愣住了——这种细节细节正是平时练习的经验积累。说完踩坑我们来看真正实用的表设计逻辑。项目完全可以去掉两次外卖平台架构图——一次是前端客户端一次是后端管理端——把用户、商家、骑手三个角色合并进同一个应用靠角色切换来使用能省掉两套界面开发同时保留业务完整性。3.2 表时区、外键和字段规范表设计时几个容易踩的坑我直接放在一起说时间字段不推荐用varchar建议用datetime后端用Java的LocalDateTime统一生成这样写“查询今天订单”时能用DATE(create_time) CURDATE()高效过滤避免跨时区和字符串比较的坑。金额字段用decimal(10, 2)类型上别用float和double。前端展示时用BigDecimal转成字符串避免浮点精度问题。Java里用BigDecimal.valueOf(doubleValue)或直接后端返回字符串给前端Android端再解析这样不会出现10.000000001这种怪异数字。订单号order_no设计成唯一索引建议格式类似yyyyMMddHHmmss 随机4位。数据库自动ID不适合对外展示因为可能被遍历和猜测而且打印在外卖单上用户报单号也不方便。外键关联很灵活可以限制餐厅状态——比如餐厅休息时用户端不应该能下单。这个逻辑放在代码层而不是只靠数据库外键约束因为毕设项目里自由的外键关系加上后台逻辑处理比强迫数据库做级联操作更清晰。3.3 订单状态机全项目最重要的一张图订单状态流转是整个项目里最值得认真设计的点。如果你把订单状态机设计得清楚后面写代码会非常顺畅如果模糊最后改起来很痛苦。我把订单状态设计成这几个节点待付款status0用户下单但没支付15分钟后系统自动关闭。待接单status1用户已付款等待餐厅确认。这个阶段用户可申请退款。待配送status2餐厅已接单并出餐等待骑手取餐。配送中status3骑手已取餐正在送往用户地址。已完成status4用户确认收货或骑手标记送达订单完成。已取消status5包含超时未支付关闭、用户主动取消、商家拒单三种情况。“退款”是一种特殊的子状态我一般在orders表加一个refund_status字段0未申请1申请中2已退款不单独建表。状态转移用Java枚举管理迁移才允许被触发避免出现“已完成的订单还能被取消”这种逻辑冲突。关于定时关单毕设项目不推荐上消息队列延迟任务最简单的方案是启动一个定时线程池每30秒扫一次“待付款且创建时间超过15分钟”的订单统一改成已取消。代码量很少效果还很直观答辩时能讲清楚原理就够了。你要是想在项目里用一些“企业级”的技术比如RabbitMQ延迟队列也可以但时间不够的话先把核心业务跑通更重要。4. 实操过程和核心环节实现重点模块怎么写4.1 Android端工程搭建关键点工程搭建阶段最容易出问题的是环境。热词里“android studio怎么设置中文”“android studio下载”“android sdk”都在搜索引擎里被反复搜说明大家卡住的地方都差不多。一定先配好JDK环境我用的JDK 8或JDK 11开发Java很简单你写Java代码用的API也就是这版本的。Android Studio版本可以在官网下最新稳定版用Dolphin或Electric Eel即可新版本对中文支持也更友好。SDK Manager里最低装Android 6.0API 23到Android 13API 33它保证你的项目兼容几年前的手机。Gradle首次构建时下载依赖很慢可以在项目的build.gradle里配置阿里云镜像仓库直接把mavenCentral()和google()替换或前置加入阿里云的maven地址实测下来构建快3倍不止。创建项目时语言选Java包名建议com.keda.order这种和模块名一致后面代码好找。工程结构我用的是MVP模式view层放Activity和Adapterpresenter层处理业务逻辑model层封装数据源——本地缓存和网络请求。很多同学会纠结用MVP还是MVVM其实毕设阶段MVP足够清晰了。MVVM要用到ViewModel和LiveData概念比MVP多一倍在答辩里容易讲不清楚。MVP的核心好处是“视图和逻辑分离”这句话在答辩时非常好用。4.2 登录态管理Token和本地缓存怎么配合登录模块是所有模块的基础它做得好不好直接影响后续所有接口的调用。我的方案很简单用户登录后后端生成一个随机UUID作为token存在后端Redis里没配Redis的话存在内存Map里也能跑通同时设置7天过期。后端把token返回给Android端Android端用SharedPreferences存储token和userId。之后每一个需要登录的接口请求头都带上Authorization: Bearer token。后端用一个拦截器HandlerInterceptor统一校验token校验不过返回401Android端收到401就强制跳转登录页。这里有个细节密码不能明文存储和传输。后端用MD5或者BCrypt加密推荐BCrypt虽然计算慢一点但自带盐安全性高很多。传输时用HTTPS最好如果本地开发没有证书就至少加上请求参数签名防止被抓包篡改。毕设可能并不需要那么严格但答辩时能说出“我用BCrypt做密码加密”至少比“密码存明文”高一个层次这也是面试时能聊的内容。4.3 首页餐厅列表请求数据、解析JSON、绑定视图首页的数据是“附近餐厅列表”接口设计为GET /api/restaurant/list?page1size10返回每个餐厅的名称、图片、评分、月售、起送价、配送费。Android端用Retrofit定义接口public interface ApiService { GET(api/restaurant/list) CallResultListRestaurant getRestaurantList( Query(page) int page, Query(size) int size ); }拿到数据后用RecyclerView展示Adapter继承RecyclerView.AdapterViewHolder用itemView.findViewById绑定控件。图片加载用Glide一句Glide.with(context).load(url).into(imageView)就搞定自动处理缓存和异步加载。如果你用了ListView而没有用RecyclerView我建议改成RecyclerView因为RecyclerView的缓存机制和ViewHolder模板是官方推荐的同时也更好讲。一个重要细节Android网络请求不能在主线程执行Retrofit的enqueue方法是异步回调没这个问题。如果是OkHttp裸请求必须用子线程。封装网络层的时候我会在回调里统一做BaseResponse校验——code200时成功回调datacode401时跳转登录页code500时Toast显示message。这样各页面不用反复写try-catch。4.4 购物车和订单提交这些业务细节决定项目质量购物车是这个项目的核心难点不是技术上难而是业务逻辑容易漏。购物车的实体是“用户对多个菜品的选择”——用户加了3个菜品每个菜品的数量不同勾选状态也不同。我的cart表有user_id, dish_id, quantity, checked。Android端每次加购或修改数量都直接调用后端接口而不是只在本地保存。这样做的好处是——用户换了一台手机登录购物车还在数据是真实的。加入购物车接口设计POST(api/cart/add) public Result addToCart(RequestBody Cart cart);购物车列表接口GET(api/cart/list) public ResultListCartVO cartList(RequestParam int userId);CartVO是一个视图对象它里面包含dishId、菜名、单价、图片、数量、小计。为什么要定义VO而不是直接返回Cart实体因为Cart表只存了dish_id和quantity前端需要展示菜名和价格这些字段在dish表里。后端查购物车时关联dish表组装成CartVO返回Android端拿到直接用不用再去查菜品接口。提交订单时后端要做几件事校验购物车必须从cart表读取当前用户的已勾选菜品。计算总价后端用菜品单价×数量重新算一遍不信任前端传过来的总金额。这一步很关键防止用户手动改请求参数白嫖。生成订单号。插入订单主表和订单明细表事务中执行。用Transactional注解。清空当前用户已勾选的购物车记录。返回订单号给前端跳转支付页。这段逻辑里最容易踩的坑是“事务忘了加”。如果orders表插入了但order_item表插入失败数据就脏了。MyBatis Plus里加Transactional(rollbackFor Exception.class)即可但这行注解很多人容易漏掉。4.5 支付模块怎么做先模拟再扩展毕设的在线支付现实中接入支付宝或微信支付需要企业资质普通学生没有。所以这个项目用“模拟支付”是完全可以的也是绝大多数毕设的常规做法。交互上模仿真实支付流程用户在订单确认页点击“去支付”。后端生成一个支付流水记录状态为“待支付”。前端弹出一个模拟收银台显示订单号和金额。用户点击“确认支付”前端调用POST /api/pay/simulate传订单号和模拟的支付方式。后端把订单状态从“待付款”改成“待接单”同时更新支付流水状态为“已支付”。用户端跳转订单详情页看到最新的状态。答辩时如果被问“为什么用模拟支付”标准回答是“支付功能依赖第三方商户资质学生在开发环境下无法申请真实接口因此实现了完整的支付流程协议和服务端流水记录在企业落地时只需替换为支付宝SDK的支付调用方法不影响整体架构。”这个回答很务实。4.6 餐厅端的菜品管理和接单复用一套App餐厅端的页面和用户端风格完全不同如果单独做一个App工程工作量大一倍。我当时的做法是同一个Android工程里根据登录用户角色动态显示底部导航栏。普通用户登录底部导航显示“首页、订单、购物车、我的”。商家管理员登录底部导航显示“订单管理、菜品管理、数据概览、我的”。骑手登录底部导航显示“配送任务、我的”。用Role字段在启动后决定MainActivity里加载哪个Fragment即可。BaseActivity里做权限判断餐厅接口只允许role2的用户访问后端拦截器在请求头里带用户角色先判断角色再执行业务角色不对直接返回403。这个设计在答辩时很加分——“基于角色的权限控制”一个很标准的鉴权模型。餐厅端“菜品管理”的页面是典型的CRUD列表展示菜品点新增弹出表单填名称、分类、价格、上传图片提交后调POST接口点击编辑调PUT接口点击删除调DELETE接口。Android端删除前弹确认对话框防止误操作。图片上传用multipart/form-data方式后端用MultipartFile接收后存到服务器的upload目录然后把文件的URL返回给前端前端把URL存到dish表image字段。要防止重名导致覆盖上传文件保存时以UUID重命名比如a1b2c3d4.jpg。4.7 配送端极简但信息密度要高骑手端的核心功能只有一个——配送任务列表和状态更新。因为时间有限这个端我做了最简版本顶部是“待取餐”和“配送中”两个Tab下方是任务卡片卡片上显示订单号、餐厅地址、用户地址、下单手机号。点击“取餐”后状态更新为配送中点击“送达”后订单状态更新为已完成。这个端虽然简单但配置了消息刷新的逻辑——因为餐厅接单后要等骑手看到新单所以页面加大了一个轮询每隔5秒调一次GET /api/delivery/tasks?riderIdxx拿到数据后和当前列表比对新增的条目自动插入。为了不让页面频繁刷新造成卡顿列表DiffUpdate计算我用了简单的方法——在Adapter里记录当前数据集合的orderId集合每次请求回来对比如果集合改变了才notifyDataSetChanged()。这个优化在答辩时可以专门提一嘴是一个很实际的性能细节。后来在这个基础上我试过用推送SDK比如极光推送替代轮询但推送服务商限制较多反而增加了很多额外调试成本。对毕设来说轮询机制配合“仅在数据变化时刷新界面”的性能优化已经是一个完整且可讲的方案。5. 高频问题排查记录把这些坑提前排掉5.1 Android网络请求频繁失败这是我遇到最多的问题。症状是后端接口在浏览器里访问正常但Android端一请求就报java.net.ConnectException或者UnknownHostException。原因通常有三个一是Android模拟器访问本机后端时不能用localhost必须用10.0.2.2。如果是真机调试必须用电脑的局域网IP比如http://192.168.1.100:8080。二是Android 9.0API 28开始默认禁止明文HTTP流量需要在AndroidManifest.xml里的application标签加android:usesCleartextTraffictrue或者配置networkSecurityConfig允许特定域名明文传输。三是手机和电脑不在同一WiFi网段或电脑防火墙拦截了8080端口。这个坑几乎人人都会踩提前备注好能省两三天时间。5.2 读取本地图片路径变成nullAndroid 6.0以上需要动态申请存储权限我在餐厅端上传菜品图片时就在这上面卡过。用ActivityCompat.requestPermissions()申请READ_EXTERNAL_STORAGE然后onRequestPermissionsResult里判断是否授权再继续选择图片。Android 11以上对文件访问又变了要用ACTION_GET_CONTENT调系统文件选择器返回的Uri直接用不需要读存储路径。毕设层面最简单的方案是用PhotoPicker或PictureSelector这类成熟库里封装好的选图组件避开系统API版本差异。如果不用库记住一条原则不要试图去拿FilePath直接用返回的Uri通过ContentResolver读取输入流。5.3 MyBatis Plus主键ID赋值不生效这个坑是我写餐厅新增接口时遇到的。数据库表用的自增主键但是前端传过来的JSON里没有带id字段插入后需要拿到自增id做后续操作。MyBatis Plus的默认行为是插入后把自增主键回填到实体类中但前提是你在TableId(type IdType.AUTO)里正确指定了主键策略。如果没有这个注解框架默认按雪花算法生成一个长id插入后id不是自增的列表页却正常但新增时偶尔出现不规则的long值。这个看细节如果不想纠结就把所有表主键都统一用AUTO策略。5.4 高并发下单时库存超卖严格来说毕设项目不会有真正的并发压力但答辩时评委喜欢问“如果同一时间很多用户都在下一个菜还剩最后一份会不会超卖”。这个问题我知道很多同学答不上来。解决方案集中在语句层面更新菜品销量时在SQL里加上库存条件——UPDATE dish SET sales sales 1, stock stock - 1 WHERE id #{dishId} AND stock 0如果影响行数不足1说明库存不足抛异常回滚事务。这个方案叫“乐观锁”的一种变体逻辑简单且有效。我在答辩时专门讲了这段SQL评委基本没有再追问。5.5 订单列表分页模糊匹配出错用户端“我的订单”和餐厅端“待接单列表”都会用到分页。用MyBatis Plus时要配置分页插件PaginationInnerInterceptor不配置则page()方法返回的记录数不变翻页无效。这是很多新手漏掉的一步。列表页面加载更多数据时Android端用RecyclerView的addOnScrollListener监听是否滑到底部滑到底部时请求下一页追加数据到列表末尾。为了避免重复加载维护了一个isLoading布尔变量防止一次滑动触发多次请求。6. 一点经验沉淀做完这个项目的复盘总结最后聊几点做完整套系统后的真实体会。第一项目的亮点不在技术新而在逻辑完整。外卖系统每个模块单独拎出来都是很基础的东西但当你把用户、商家、骑手三端通过订单状态机串联起来形成一个完整的业务闭环后这个项目在毕设里就属于很能打的了。答辩时最忌讳的也是只讲“我用了什么框架”而应该讲“这个需求为什么这么设计这个状态为什么这么流转”。第二留给联调的时间一定要比写代码的时间多。我当初给自己排的计划是两周写完所有接口和页面结果联调阶段整整用掉了一周半。问题主要出在字段名不一致、返回结构不统一、时间格式对不上这些细节上。后来总结了规律前端和后端在开发之前一定要先一起定义好接口文档写清楚每个字段的类型和含义。这一份文档看似费时间实际省的时间远远大于付出。第三代码一定要分层。Controller层只接收参数和返回结果Service层写业务逻辑Mapper层操作数据库实体类只用字段和getter/setterVO类专门组装给前端的视图数据。分层乱了的话后面改一个需求你会发现自己到处找代码在哪改一个问题引出一堆BUG。分层清晰的话哪怕做到一半换个思路改动也能控制在某个层内。第四关于扩展方向。如果你做完这套系统还有余力可以做三件事一是把本地存储在OSS这种方案替换掉并把“存储对象”和“业务表”解耦二是给订单状态流转加上操作日志表记录谁在什么时间把订单从什么状态改成了什么状态——这是真实外卖平台里必须有的审计能力三是把轮询改成定时推送因为真实场景中骑手不可能每5秒请求一次列表。这三个方向任意做一个都能让答辩的深度再上一档。做毕设就是这样别把它想成一道非对即错的考试题——它更像一个完整的工程练习你在里面投入的每一分精力最后都会变成实实在在的能力。希望这篇拆解能帮你少走一些路把时间花在把项目真正做扎实上。祝你的项目一次跑通。
