简介面向Java/Android学习者的外卖订餐系统课程设计报告完整记录了从需求分析到项目落地的全过程。文档以软件工程规范为纲先阐述课程设计目的与任务再展开需求分析包含数据流图、用例图、时序图、活动图等建模内容随后给出系统概要设计、数据库逻辑与基表设计并分别说明Web管理端和Android客户端的详细实现最后附上软件测试报告、用户操作手册和项目开发总结结构清晰、层次分明。资源包内为单个doc文件大小仅2.65MB方便直接复制编辑或作为课程设计报告模板参考。已有556人浏览学习适合正在完成Java或Android课程设计、需要参考完整项目文档结构及设计思路的同学从文档目录到各章节撰写方式都能提供系统的规范示例也可作为毕业设计或软件工程课程报告的写作范本。1. 从一份课设题目看真实外卖系统java安卓开发外卖订餐系统课程设计到底在考什么「java安卓开发外卖订餐系统课程设计」这个标题在简历上出现的频率比真实外卖项目的上线频率高得多。很多人把它当做一个「安卓App项目」来做结果服务端只有几个Servlet数据库表就三张答辩时被老师一问订单状态怎么流转就卡壳。反过来也有团队把技术栈堆到Spring Cloud Redis 消息队列结果课程设计周期里连登录都没跑通。这个项目的真正难点不在客户端绘制几个列表页而在于你如何用Java把「点餐-支付-出餐-送达」这条链路的业务规则讲清楚同时让安卓端和服务端通过一套稳定的接口契约协作。适合正在做这个课设的学生以及需要快速评估这类项目代码质量的工程师——后者往往会发现接口设计和异常处理才是判断项目真实水平的第一眼。2. 服务端Java选型与安卓端架构外卖订餐系统的骨架怎么搭在开始写代码之前先把两端的技术选型钉死。我见过的课程设计里最常见的翻车点不是功能做不出来而是服务端和安卓端各写各的——服务端返回的字段叫userName安卓端解析的是name联调的时候浪费整整一个晚上。所以这一章先讲选型再讲架构分层最后把接口契约定下来。2.1 课程设计里Spring Boot够用但别直接上微服务服务端技术栈常见做法是Servlet JSP、SSMSpring MVC Spring MyBatis、Spring Boot三选一。如果还有时间能把这套做完建议直接Spring Boot 2.7 MyBatis MySQL理由很简单Spring Boot内嵌Tomcat不需要单独装服务器MyBatis的Mapper接口和XML对SQL的掌控力足够直观MySQL 5.7/8.0在这个量级完全够用没必要碰PostgreSQL或MongoDB。微服务框架在这个项目里是纯粹的负资产。外卖订餐系统的课程设计业务量撑死几十个并发单体应用反而好调试、好演示。你需要在答辩时说清楚的反而是为什么订单表要拆成主表和明细表为什么菜单要有上下架状态。下面给出一张常用的表结构参考这是课程设计最常见的7张表。表名核心字段说明userid, username, password, rolerole区分顾客/商家/管理员shopid, name, address, status一个商家对应多个菜品dishid, shop_id, name, price, statusstatus控制上下架cartid, user_id, dish_id, quantity购物车会话内临时数据ordersid, order_no, user_id, shop_id, total_price, status, create_time订单主表order_itemid, order_id, dish_id, dish_name, price, quantity订单明细冗余菜品快照addressid, user_id, receiver, phone, detail收货地址提示order_item里冗余dish_name和price是为了防止商家改价或下架后历史订单依然能正确展示。这是答辩时一个很好的加分点很多同学不知道「快照」这个概念。2.2 安卓端的MVP分层与包结构安卓端的技术选型课程设计最稳妥的组合是Java MVPModel-View-Presenter而不是MVVM原因是你对LiveData和DataBinding的掌握大概率还不熟面试官和答辩老师更关心你能不能把「视图层不直接访问网络」这个原则讲清楚。常见的包结构如下com.example.order ├── model // 数据模型 Java Bean和接口返回的JSON字段一一对应 ├── view // Activity/Fragment只做UI刷新和用户交互 ├── presenter // 业务逻辑调用Retrofit、处理回调、管理订单状态 ├── api // Retrofit接口定义和网络层配置 ├── adapter // RecyclerView的Adapter └── utils // SharedPreferences封装、日期格式化等在这个结构下Activity里不会出现数据库查询或网络请求代码。presenter层接收view层的动作调用api层拿到结果后再通过回调更新view。这样做的实际收益是答辩现场要临时改一个UI展示逻辑时不需要去翻网络请求的代码改动范围被控制在很小区域内。2.3 前后端接口契约用JSON把两端钉死接口契约是课程设计里最容易被忽略的部分。我会在工程里建一个api_doc.md把每个接口的URL、请求方法、请求参数、返回结构写清楚。这里给一个标准化返回包装类服务端和安卓端共用同一结构。public class ApiResultT { private int code; // 0表示成功非0为业务错误码 private String message; // 给用户看的提示信息 private T data; // 业务数据失败时为null public static T ApiResultT success(T data) { ApiResultT r new ApiResult(); r.code 0; r.message ok; r.data data; return r; } public static T ApiResultT error(int code, String message) { ApiResultT r new ApiResult(); r.code code; r.message message; r.data null; return r; } }代码逻辑说明success和error都是静态工厂方法返回同一个泛型结构。error里必须先把r.data置空再返回对象否则调用方拿到的data是旧值。安卓端对应这里的解析要特别注意如果直接用ApiResult.class去接Gson会因为泛型擦除而丢失List类型信息这一点在下一章单独展开。3. 外卖订餐核心流程的Java实现鉴权、菜单、订单状态机这一章进入核心业务代码。外卖订餐系统三个绕不开的模块用户登录与会话保持、菜单的展示与缓存、订单从创建到完成的流转。每一块都有课程设计答辩时容易答不上来的技术细节。3.1 登录与Token鉴权安卓端尽量别用Session在纯Servlet JSP的老课设里登录后靠request.getSession()存用户信息。但安卓端不是浏览器虽然OkHttp默认开启Cookie持久化跨端联调时Session的体感很差——服务端重启后Session全部清空Token过期时间不可控。我建议直接用Token方案课程设计完全能讲清楚。public ApiResultString login(String username, String password) { User user userMapper.findByUsername(username); if (user null || !user.getPassword().equals(md5(password))) { return ApiResult.error(1001, 用户名或密码错误); } String token UUID.randomUUID().toString().replace(-, ); tokenMapper.insert(token, user.getId(), System.currentTimeMillis() 7 * 24 * 3600 * 1000L); return ApiResult.success(token); }参数说明业务错误码1001在这里统一了「用户不存在」和「密码错误」两种情况防止攻击者通过提示文案探测用户名答辩时主动提这句话老师会认为你有安全意识。Token过期时间设为7天课程设计演示期间完全够用。安卓端拿到这个token后存入SharedPreferences之后的请求统一通过Authorization: Bearer token头携带。3.2 菜单数据模型与SQLite缓存弱网下的兜底方案菜单只有接口实时拉取面试官大概率会追一句弱网环境下怎么让菜单还能打开SQLite缓存就是答案。做法是第一次进入商家详情页时请求/api/dish/list把结果写入SQLite下一次进入先读缓存立即展示后台请求新数据并更新界面。Room在这里比原生SQLiteOpenHelper更合适编译期就能校验SQL语法Java项目下也完全是正常工程。Entity(tableName dish_cache) public class DishCacheEntity { PrimaryKey public int dishId; public String dishName; public double price; public int shopId; public long cacheTime; // 缓存时间戳用于过期判断 }字段说明cacheTime是缓存时间的核心字段。我用的过期策略是做时间戳对比——距今超过10分钟就强制从网络刷新。这里需要说明的是数据库访问直接写在presenter里属于课程设计可以接受的简化生产环境会再加一个Repository层presenter只跟Repository交互。3.3 订单状态机的流转设计一张Map替代if-else订单状态是最容易让答辩老师兴奋的点。常见状态枚举如下。public enum OrderStatus { CREATED(0, 已下单), PAID(1, 已支付), ACCEPTED(2, 商家已接单), DELIVERING(3, 配送中), COMPLETED(4, 已完成), CANCELED(-1, 已取消); public final int code; public final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } }状态流转的规则比枚举本身更重要CREATED - PAID - ACCEPTED - DELIVERING - COMPLETED是正向路径CREATED - CANCELED和PAID - CANCELED是允许的逆向路径但ACCEPTED之后不允许直接取消。用if-else写这些规则状态一多就乱我用一个MapOrderStatus, ListOrderStatus定义合法流转集合。MapOrderStatus, ListOrderStatus stateMachine new HashMap(); stateMachine.put(CREATED, Arrays.asList(PAID, CANCELED)); stateMachine.put(PAID, Arrays.asList(ACCEPTED, CANCELED)); stateMachine.put(ACCEPTED, Arrays.asList(DELIVERING)); stateMachine.put(DELIVERING, Arrays.asList(COMPLETED)); public void transition(OrderStatus from, OrderStatus to, Order order) { if (!stateMachine.get(from).contains(to)) { throw new IllegalStateException(非法状态流转: from - to); } order.setStatus(to.code); }这个写法的好处在答辩时特别明显老师问「支付失败订单还能回已下单状态吗」你可以直接回答支付失败订单停在CREATED并做超时关闭而不是在状态机里加一条PAID - CREATED的边。如果下单入口有并发要求记得在orders表加(user_id, create_time)唯一索引否则用户连续点击两次会插入重复订单。4. 安卓端网络层与线程模型Retrofit、Gson与主线程约束服务端接口写好后安卓端网络层是联调时最多坑的地方。聚焦三个高频问题Retrofit OkHttp怎么配置、Gson解析泛型为什么崩溃、为什么不能在主线程跑请求。4.1 Retrofit OkHttp超时参数与token拦截器课程设计里Retrofit 2.9 OkHttp 4.x是最稳妥的组合。OkHttp 4.x的包名仍然是okhttp3Java项目引用不需要额外适配。一个够用的网络层封装如下。OkHttpClient client new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) // 连接超时地址可达但握手慢的场景 .readTimeout(15, TimeUnit.SECONDS) // 读取超时菜品图片多时需要调大 .addInterceptor(new Interceptor() { Override public Response intercept(Chain chain) throws IOException { Request original chain.request(); String token PrefUtils.getString(token, ); Request request original.newBuilder() .header(Authorization, Bearer token) .build(); return chain.proceed(request); } }) .build(); Retrofit retrofit new Retrofit.Builder() .baseUrl(http://10.0.2.2:8080/api/) .client(client) .addConverterFactory(GsonConverterFactory.create()) .build();参数说明10.0.2.2是Android模拟器访问宿主机localhost的专用地址真机调试必须换成电脑的局域网IP比如http://192.168.1.101:8080/api/。另外安卓9开始默认禁止明文HTTP流量需要在AndroidManifest.xml声明android:usesCleartextTraffictrue或者在network_security_config.xml里对指定域名放开。这几乎是每次课程设计联调必踩的坑——服务端一切正常App死活请求失败日志里报CLEARTEXT communication not permitted。4.2 Gson泛型解析TypeToken救场订餐系统的列表接口返回的是ApiResultListDish如果图省事用ApiResult.class去接运行时不报错但拿到手的data类型是ListLinkedTreeMap在Adapter里调dish.getName()直接抛ClassCastException。正确写法是用TypeToken保全泛型信息。Type type new TypeTokenApiResultListDish() {}.getType(); ApiResultListDish result gson.fromJson(jsonString, type);代码里的花括号不能省它创建了一个匿名内部类让getType()能拿到真实的泛型参数。当时第一次遇到这个崩溃的人几乎都要花一个晚上才能搜到这个解法。另外还要注意如果服务端字段名是dish_name而Java Bean字段是dishName要用SerializedName(dish_name)做映射否则解析出来全是null。4.3 主线程网络请求与ANRenqueue会自动切线程安卓不允许在主线程执行网络请求超过5秒就会ANR。Retrofit的enqueue()方法内部自动切换线程onResponse回到主线程回调所以Activity里直接这样写。api.getMenu(shopId).enqueue(new CallbackApiResultListDish() { Override public void onResponse(CallApiResultListDish call, ResponseApiResultListDish response) { if (response.isSuccessful() response.body() ! null) { adapter.setData(response.body().data); } } Override public void onFailure(CallApiResultListDish call, Throwable t) { Toast.makeText(MainActivity.this, 网络异常, Toast.LENGTH_SHORT).show(); } });代码说明enqueue是异步的立刻返回不阻塞UI。onResponse里先判断response.isSuccessful()检查HTTP层是否2xx再判断body()是否为null防止服务端返回空body导致NPE。onFailure里只做提示重试逻辑放在presenter层而不是UI层。这里的Toast直接用Activity引用存在内存泄漏风险课程设计不深究但答辩时主动提一句「工程里会用WeakReference包裹」评价能高半档。4.4 联调排错日志拦截器与抓包建议在Debug构建下给OkHttp挂一个HttpLoggingInterceptorlevel设为BODYRelease构建必须设为NONE否则接口参数和token会裸露在系统日志里。如果日志不方便看就上抓包工具。注意安卓7.0以上默认不信任用户安装的抓包证书需要在network_security_config.xml里配置信任范围这是联调环节另一个高频磨人的点。5. 答辩前必做的验证清单与演示顺序写一个可操作的验证清单按顺序过一遍比场上临场发挥稳得多。第一验证Token鉴权。卸载重装App打开任意需要登录的页面确认会跳转到登录页而不是直接崩溃。清空SharedPreferences再启动同样验证。服务端清空token表后再请求确认返回401或1001错误码符合预期。第二验证订单状态机。用测试账号点单从「已下单」走到「已完成」每一步在服务端日志确认order_status字段变化正确。特别注意取消场景刚下单立刻取消应该成功支付后再取消应该走「申请取消」流程而不是直接改状态。第三验证菜品上下架联动。商家端把某个菜品下架顾客端刷新菜单确认该菜品消失且购物车中该菜品的数量被自动清理。这个联动逻辑如果做了是答辩的展示亮点很多组都会漏掉购物车数据一致性的处理。第四演示顺序建议先讲表结构和订单状态流转再打开App做登录、浏览菜单、下单、商家接单、配送、完成。把「下单」放到讲完架构图之后做实机演示让评委先看到设计再看到实现信息接收效率更高。第五善用边界case。故意输错密码、清空缓存、断网后打开菜单这些操作只要代码处理正确都会变成加分演示。学生最常犯的错误是只演示顺利路径遇到异常直接卡顿这恰恰是课程设计与工业级应用之间的分水岭。如果还有余力把订单超时自动关闭做成Spring的Scheduled定时任务每30秒扫描一次把超过15分钟未支付的CREATED订单改成CANCELED并在日志里打印扫描耗时。这项功能不但提升完整度还能让你在面试中接住连环追问——从「超时关单」可以自然引出分布式锁、延迟队列、定时任务幂等等一系列扩展话题。本文还有配套的精品资源点击获取 Java安卓外卖订餐系统课程设计实战：从选型到订单状态机
简介面向Java/Android学习者的外卖订餐系统课程设计报告完整记录了从需求分析到项目落地的全过程。文档以软件工程规范为纲先阐述课程设计目的与任务再展开需求分析包含数据流图、用例图、时序图、活动图等建模内容随后给出系统概要设计、数据库逻辑与基表设计并分别说明Web管理端和Android客户端的详细实现最后附上软件测试报告、用户操作手册和项目开发总结结构清晰、层次分明。资源包内为单个doc文件大小仅2.65MB方便直接复制编辑或作为课程设计报告模板参考。已有556人浏览学习适合正在完成Java或Android课程设计、需要参考完整项目文档结构及设计思路的同学从文档目录到各章节撰写方式都能提供系统的规范示例也可作为毕业设计或软件工程课程报告的写作范本。1. 从一份课设题目看真实外卖系统java安卓开发外卖订餐系统课程设计到底在考什么「java安卓开发外卖订餐系统课程设计」这个标题在简历上出现的频率比真实外卖项目的上线频率高得多。很多人把它当做一个「安卓App项目」来做结果服务端只有几个Servlet数据库表就三张答辩时被老师一问订单状态怎么流转就卡壳。反过来也有团队把技术栈堆到Spring Cloud Redis 消息队列结果课程设计周期里连登录都没跑通。这个项目的真正难点不在客户端绘制几个列表页而在于你如何用Java把「点餐-支付-出餐-送达」这条链路的业务规则讲清楚同时让安卓端和服务端通过一套稳定的接口契约协作。适合正在做这个课设的学生以及需要快速评估这类项目代码质量的工程师——后者往往会发现接口设计和异常处理才是判断项目真实水平的第一眼。2. 服务端Java选型与安卓端架构外卖订餐系统的骨架怎么搭在开始写代码之前先把两端的技术选型钉死。我见过的课程设计里最常见的翻车点不是功能做不出来而是服务端和安卓端各写各的——服务端返回的字段叫userName安卓端解析的是name联调的时候浪费整整一个晚上。所以这一章先讲选型再讲架构分层最后把接口契约定下来。2.1 课程设计里Spring Boot够用但别直接上微服务服务端技术栈常见做法是Servlet JSP、SSMSpring MVC Spring MyBatis、Spring Boot三选一。如果还有时间能把这套做完建议直接Spring Boot 2.7 MyBatis MySQL理由很简单Spring Boot内嵌Tomcat不需要单独装服务器MyBatis的Mapper接口和XML对SQL的掌控力足够直观MySQL 5.7/8.0在这个量级完全够用没必要碰PostgreSQL或MongoDB。微服务框架在这个项目里是纯粹的负资产。外卖订餐系统的课程设计业务量撑死几十个并发单体应用反而好调试、好演示。你需要在答辩时说清楚的反而是为什么订单表要拆成主表和明细表为什么菜单要有上下架状态。下面给出一张常用的表结构参考这是课程设计最常见的7张表。表名核心字段说明userid, username, password, rolerole区分顾客/商家/管理员shopid, name, address, status一个商家对应多个菜品dishid, shop_id, name, price, statusstatus控制上下架cartid, user_id, dish_id, quantity购物车会话内临时数据ordersid, order_no, user_id, shop_id, total_price, status, create_time订单主表order_itemid, order_id, dish_id, dish_name, price, quantity订单明细冗余菜品快照addressid, user_id, receiver, phone, detail收货地址提示order_item里冗余dish_name和price是为了防止商家改价或下架后历史订单依然能正确展示。这是答辩时一个很好的加分点很多同学不知道「快照」这个概念。2.2 安卓端的MVP分层与包结构安卓端的技术选型课程设计最稳妥的组合是Java MVPModel-View-Presenter而不是MVVM原因是你对LiveData和DataBinding的掌握大概率还不熟面试官和答辩老师更关心你能不能把「视图层不直接访问网络」这个原则讲清楚。常见的包结构如下com.example.order ├── model // 数据模型 Java Bean和接口返回的JSON字段一一对应 ├── view // Activity/Fragment只做UI刷新和用户交互 ├── presenter // 业务逻辑调用Retrofit、处理回调、管理订单状态 ├── api // Retrofit接口定义和网络层配置 ├── adapter // RecyclerView的Adapter └── utils // SharedPreferences封装、日期格式化等在这个结构下Activity里不会出现数据库查询或网络请求代码。presenter层接收view层的动作调用api层拿到结果后再通过回调更新view。这样做的实际收益是答辩现场要临时改一个UI展示逻辑时不需要去翻网络请求的代码改动范围被控制在很小区域内。2.3 前后端接口契约用JSON把两端钉死接口契约是课程设计里最容易被忽略的部分。我会在工程里建一个api_doc.md把每个接口的URL、请求方法、请求参数、返回结构写清楚。这里给一个标准化返回包装类服务端和安卓端共用同一结构。public class ApiResultT { private int code; // 0表示成功非0为业务错误码 private String message; // 给用户看的提示信息 private T data; // 业务数据失败时为null public static T ApiResultT success(T data) { ApiResultT r new ApiResult(); r.code 0; r.message ok; r.data data; return r; } public static T ApiResultT error(int code, String message) { ApiResultT r new ApiResult(); r.code code; r.message message; r.data null; return r; } }代码逻辑说明success和error都是静态工厂方法返回同一个泛型结构。error里必须先把r.data置空再返回对象否则调用方拿到的data是旧值。安卓端对应这里的解析要特别注意如果直接用ApiResult.class去接Gson会因为泛型擦除而丢失List类型信息这一点在下一章单独展开。3. 外卖订餐核心流程的Java实现鉴权、菜单、订单状态机这一章进入核心业务代码。外卖订餐系统三个绕不开的模块用户登录与会话保持、菜单的展示与缓存、订单从创建到完成的流转。每一块都有课程设计答辩时容易答不上来的技术细节。3.1 登录与Token鉴权安卓端尽量别用Session在纯Servlet JSP的老课设里登录后靠request.getSession()存用户信息。但安卓端不是浏览器虽然OkHttp默认开启Cookie持久化跨端联调时Session的体感很差——服务端重启后Session全部清空Token过期时间不可控。我建议直接用Token方案课程设计完全能讲清楚。public ApiResultString login(String username, String password) { User user userMapper.findByUsername(username); if (user null || !user.getPassword().equals(md5(password))) { return ApiResult.error(1001, 用户名或密码错误); } String token UUID.randomUUID().toString().replace(-, ); tokenMapper.insert(token, user.getId(), System.currentTimeMillis() 7 * 24 * 3600 * 1000L); return ApiResult.success(token); }参数说明业务错误码1001在这里统一了「用户不存在」和「密码错误」两种情况防止攻击者通过提示文案探测用户名答辩时主动提这句话老师会认为你有安全意识。Token过期时间设为7天课程设计演示期间完全够用。安卓端拿到这个token后存入SharedPreferences之后的请求统一通过Authorization: Bearer token头携带。3.2 菜单数据模型与SQLite缓存弱网下的兜底方案菜单只有接口实时拉取面试官大概率会追一句弱网环境下怎么让菜单还能打开SQLite缓存就是答案。做法是第一次进入商家详情页时请求/api/dish/list把结果写入SQLite下一次进入先读缓存立即展示后台请求新数据并更新界面。Room在这里比原生SQLiteOpenHelper更合适编译期就能校验SQL语法Java项目下也完全是正常工程。Entity(tableName dish_cache) public class DishCacheEntity { PrimaryKey public int dishId; public String dishName; public double price; public int shopId; public long cacheTime; // 缓存时间戳用于过期判断 }字段说明cacheTime是缓存时间的核心字段。我用的过期策略是做时间戳对比——距今超过10分钟就强制从网络刷新。这里需要说明的是数据库访问直接写在presenter里属于课程设计可以接受的简化生产环境会再加一个Repository层presenter只跟Repository交互。3.3 订单状态机的流转设计一张Map替代if-else订单状态是最容易让答辩老师兴奋的点。常见状态枚举如下。public enum OrderStatus { CREATED(0, 已下单), PAID(1, 已支付), ACCEPTED(2, 商家已接单), DELIVERING(3, 配送中), COMPLETED(4, 已完成), CANCELED(-1, 已取消); public final int code; public final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } }状态流转的规则比枚举本身更重要CREATED - PAID - ACCEPTED - DELIVERING - COMPLETED是正向路径CREATED - CANCELED和PAID - CANCELED是允许的逆向路径但ACCEPTED之后不允许直接取消。用if-else写这些规则状态一多就乱我用一个MapOrderStatus, ListOrderStatus定义合法流转集合。MapOrderStatus, ListOrderStatus stateMachine new HashMap(); stateMachine.put(CREATED, Arrays.asList(PAID, CANCELED)); stateMachine.put(PAID, Arrays.asList(ACCEPTED, CANCELED)); stateMachine.put(ACCEPTED, Arrays.asList(DELIVERING)); stateMachine.put(DELIVERING, Arrays.asList(COMPLETED)); public void transition(OrderStatus from, OrderStatus to, Order order) { if (!stateMachine.get(from).contains(to)) { throw new IllegalStateException(非法状态流转: from - to); } order.setStatus(to.code); }这个写法的好处在答辩时特别明显老师问「支付失败订单还能回已下单状态吗」你可以直接回答支付失败订单停在CREATED并做超时关闭而不是在状态机里加一条PAID - CREATED的边。如果下单入口有并发要求记得在orders表加(user_id, create_time)唯一索引否则用户连续点击两次会插入重复订单。4. 安卓端网络层与线程模型Retrofit、Gson与主线程约束服务端接口写好后安卓端网络层是联调时最多坑的地方。聚焦三个高频问题Retrofit OkHttp怎么配置、Gson解析泛型为什么崩溃、为什么不能在主线程跑请求。4.1 Retrofit OkHttp超时参数与token拦截器课程设计里Retrofit 2.9 OkHttp 4.x是最稳妥的组合。OkHttp 4.x的包名仍然是okhttp3Java项目引用不需要额外适配。一个够用的网络层封装如下。OkHttpClient client new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) // 连接超时地址可达但握手慢的场景 .readTimeout(15, TimeUnit.SECONDS) // 读取超时菜品图片多时需要调大 .addInterceptor(new Interceptor() { Override public Response intercept(Chain chain) throws IOException { Request original chain.request(); String token PrefUtils.getString(token, ); Request request original.newBuilder() .header(Authorization, Bearer token) .build(); return chain.proceed(request); } }) .build(); Retrofit retrofit new Retrofit.Builder() .baseUrl(http://10.0.2.2:8080/api/) .client(client) .addConverterFactory(GsonConverterFactory.create()) .build();参数说明10.0.2.2是Android模拟器访问宿主机localhost的专用地址真机调试必须换成电脑的局域网IP比如http://192.168.1.101:8080/api/。另外安卓9开始默认禁止明文HTTP流量需要在AndroidManifest.xml声明android:usesCleartextTraffictrue或者在network_security_config.xml里对指定域名放开。这几乎是每次课程设计联调必踩的坑——服务端一切正常App死活请求失败日志里报CLEARTEXT communication not permitted。4.2 Gson泛型解析TypeToken救场订餐系统的列表接口返回的是ApiResultListDish如果图省事用ApiResult.class去接运行时不报错但拿到手的data类型是ListLinkedTreeMap在Adapter里调dish.getName()直接抛ClassCastException。正确写法是用TypeToken保全泛型信息。Type type new TypeTokenApiResultListDish() {}.getType(); ApiResultListDish result gson.fromJson(jsonString, type);代码里的花括号不能省它创建了一个匿名内部类让getType()能拿到真实的泛型参数。当时第一次遇到这个崩溃的人几乎都要花一个晚上才能搜到这个解法。另外还要注意如果服务端字段名是dish_name而Java Bean字段是dishName要用SerializedName(dish_name)做映射否则解析出来全是null。4.3 主线程网络请求与ANRenqueue会自动切线程安卓不允许在主线程执行网络请求超过5秒就会ANR。Retrofit的enqueue()方法内部自动切换线程onResponse回到主线程回调所以Activity里直接这样写。api.getMenu(shopId).enqueue(new CallbackApiResultListDish() { Override public void onResponse(CallApiResultListDish call, ResponseApiResultListDish response) { if (response.isSuccessful() response.body() ! null) { adapter.setData(response.body().data); } } Override public void onFailure(CallApiResultListDish call, Throwable t) { Toast.makeText(MainActivity.this, 网络异常, Toast.LENGTH_SHORT).show(); } });代码说明enqueue是异步的立刻返回不阻塞UI。onResponse里先判断response.isSuccessful()检查HTTP层是否2xx再判断body()是否为null防止服务端返回空body导致NPE。onFailure里只做提示重试逻辑放在presenter层而不是UI层。这里的Toast直接用Activity引用存在内存泄漏风险课程设计不深究但答辩时主动提一句「工程里会用WeakReference包裹」评价能高半档。4.4 联调排错日志拦截器与抓包建议在Debug构建下给OkHttp挂一个HttpLoggingInterceptorlevel设为BODYRelease构建必须设为NONE否则接口参数和token会裸露在系统日志里。如果日志不方便看就上抓包工具。注意安卓7.0以上默认不信任用户安装的抓包证书需要在network_security_config.xml里配置信任范围这是联调环节另一个高频磨人的点。5. 答辩前必做的验证清单与演示顺序写一个可操作的验证清单按顺序过一遍比场上临场发挥稳得多。第一验证Token鉴权。卸载重装App打开任意需要登录的页面确认会跳转到登录页而不是直接崩溃。清空SharedPreferences再启动同样验证。服务端清空token表后再请求确认返回401或1001错误码符合预期。第二验证订单状态机。用测试账号点单从「已下单」走到「已完成」每一步在服务端日志确认order_status字段变化正确。特别注意取消场景刚下单立刻取消应该成功支付后再取消应该走「申请取消」流程而不是直接改状态。第三验证菜品上下架联动。商家端把某个菜品下架顾客端刷新菜单确认该菜品消失且购物车中该菜品的数量被自动清理。这个联动逻辑如果做了是答辩的展示亮点很多组都会漏掉购物车数据一致性的处理。第四演示顺序建议先讲表结构和订单状态流转再打开App做登录、浏览菜单、下单、商家接单、配送、完成。把「下单」放到讲完架构图之后做实机演示让评委先看到设计再看到实现信息接收效率更高。第五善用边界case。故意输错密码、清空缓存、断网后打开菜单这些操作只要代码处理正确都会变成加分演示。学生最常犯的错误是只演示顺利路径遇到异常直接卡顿这恰恰是课程设计与工业级应用之间的分水岭。如果还有余力把订单超时自动关闭做成Spring的Scheduled定时任务每30秒扫描一次把超过15分钟未支付的CREATED订单改成CANCELED并在日志里打印扫描耗时。这项功能不但提升完整度还能让你在面试中接住连环追问——从「超时关单」可以自然引出分布式锁、延迟队列、定时任务幂等等一系列扩展话题。本文还有配套的精品资源点击获取