1. 项目背景与整体设计思路这个选题我第一眼看到就想拍大腿典型的技术栈好看业务能落地型毕设题目。Spring Boot做后端接口Android做前端移动端中间再配上MySQL存数据一套完整的家教服务平台就出来了。你说它是管理系统其实本质上是一个双向匹配的在线平台——家长端找家教、家教端接单子中间夹杂订单、评价、排课、结算这一条完整的业务链。先聊聊为什么这个题适合做毕业设计因为它的复杂度刚好卡在能把你和其他人区分开的位置。你要是只做一个普通的CRUD管理系统老师一眼就能看穿但加上订单状态机、教师等级认证、家长评价体系之后整个系统的业务完整性立刻不一样了。而且Spring Boot Android这个组合本身就自带话题性答辩的时候老师问什么你都能接得上话。再说说场景怎么拆。一个合格的家教平台至少要覆盖三类角色管理员、家长、家教老师。家长端要能浏览老师列表、按科目筛选、看评分、下单预约家教老师要能上传资质、管理自己的课程时间、接受或拒绝订单管理员则要负责审核老师资质、处理投诉、统计平台数据。这三条线合在一起才是完整的家教管理系统缺了任何一条线都只是半成品。从技术演进的角度看其实现在很多人会纠结要不要用小程序替代Android端我的看法是毕设直接用Android原生就行原因后面工具选型部分详细说。这里先明确一个共识——做这个项目的核心目标不是真的上线运营而是通过一个完整的全栈项目展示你对前端交互后端接口数据库设计的整合能力。2. 技术选型与核心原理2.1 Spring Boot 3.x MyBatis Plus 的组合逻辑后端我推荐直接用Spring Boot 3.x配合MyBatis Plus这是目前Java系毕设里的主流搭配。Spring Boot负责把整个Web服务的骨架搭起来内嵌Tomcat一行代码都不用配就能跑起来这对时间紧张的毕业生来说太友好了。MyBatis Plus相比纯MyBatis的优势在于单表CRUD根本不用写SQLBaseMapper里那些insert、selectById、updateById直接拿来用省下来的时间都够你把订单状态机多写两个状态了。不过我要提醒一句MyBatis Plus不是万能药多表关联查询老老实实自己写XML里的SQL别硬套它那个Wrapper很多时候查出来的字段对不上会让你排查到怀疑人生。接口设计上走RESTful风格统一返回Result对象code message dataAndroid端拿到这个结构体再解析协作效率会高很多。权限认证用JWT登录成功后颁发一个有效期为24小时的tokenAndroid端保存到SharedPreferences里每次请求带上Authorization头就行。为什么不用SessionAndroid端不像浏览器会自动管理Cookie用JWT免去了很多会话同步的麻烦而且天然支持无状态扩展这点在答辩的时候可以拿出来说。2.2 Android原生开发到底选Java还是Kotlin现在去搜Android开发相关内容铺天盖地都是Kotlin但我不建议毕设一上来就啃Kotlin除非你之前已经用Kotlin写过项目。原因是大部分学校的Android课程还是用Java教的你需要在短时间内同时搞明白Activity生命周期、RecyclerView适配器、网络请求回调这几个硬骨头没必要再叠加一门新语言的认知负担。当然你完全可以最后冲刺阶段把代码重构成Kotlin这属于锦上添花。但核心逻辑用Java写完并且能跑通比什么都强。Android端架构上我建议MVP就够了Activity当View层Presenter负责业务逻辑Model管数据。MVVM也行但LiveData ViewModel这套组合对于毕设来说有点over-engineering你还要处理生命周期绑定的细节时间不划算。网络框架用OkHttp Retrofit。Retrofit的注解式接口定义方式非常适合这种前后端分离的协作模式后端接口一定义好Android端照着接口文档写interface就行自动把JSON解析成Java对象。JSON解析就用Gson简单直接都是Java系的东西配合格外顺畅。2.3 数据库选型和表结构设计的第一性原理MySQL 8.0是标配这没什么好纠结的。关键在于表结构怎么设计——这决定了你的业务逻辑是清晰还是混乱。我见过太多人做毕设时随手下两张表就开始写代码结果到后面订单状态一复杂整个系统直接崩盘。一个家教平台的核心表我建议至少包含这些用户表user、老师详情表teacher_info、科目表subject、老师科目关联表teacher_subject、订单表order、排课表course_schedule、评价表review、收藏表favorite、公告表notice。这些表之间的外键关系要不要物理外键我建议不要逻辑外键就够了。毕业设计阶段物理外键的维护成本大于收益而且你答辩时完全可以说生产环境通常禁用物理外键以保证扩展性这反而是加分项。订单状态这块单独强调一下用int类型存状态码0待支付、1待上课、2已上课、3已完成、4已取消、5退款中。不要直接存字符串状态码配合常量类或者枚举类使用可读性照样高而且后续要统计所有退款订单这种数据的时候写SQL会舒服很多。3. 后端核心模块设计与实现3.1 基于JWT的登录认证与角色权限控制登录这块是整个系统的入口做得不好后面全崩。我的方案是登录接口接收手机号和密码校验通过后用JJWT库生成tokentoken的payload里塞userId和role字段1管理员、2家长、3老师然后返回给客户端。后续请求通过拦截器解析token把用户信息放到ThreadLocal里业务层随时能拿到当前操作人。角色权限控制用一个自定义注解RequireRole配合Spring拦截器在handler执行前做校验。比如发布公告这个接口标注RequireRole(1)家教接单接口标注RequireRole(3)家长下单接口标注RequireRole(2)。代码看起来是这样PostMapping(/order/create) RequireRole(2) public ResultString createOrder(RequestBody OrderCreateRequest request) { // 业务逻辑... }拦截器里先解析token再检查当前用户角色是否匹配注解要求不匹配直接返回403。另外密码存储必须用BCrypt加密spring-security-crypto这个依赖单独拎出来用就行不需要引入整套Spring Security。BCrypt有个特点每次加密同一个密码得到的密文都不一样因为内部带了随机盐这比MD5那种固定哈希值安全一个数量级。3.2 家教检索的核心算法与实现家长端最核心的功能就是搜索家教这决定了平台的使用体验。我的实现逻辑是按科目id 区域 价格区间 综合评分做组合筛选分页返回教师列表。综合评分的计算是(科目匹配分数×0.4 教龄分数×0.2 评价分数×0.4)每个维度都归一化到0-5分用这个算出来的分数做排序。这个算法的关键在于打分的规则要讲得清楚答辩的时候这是重点展示环节。你在代码里封装一个ScoreCalculator类从teacher_subject表里取科目匹配度从teacher_info里取教龄从review表里AVG出评价分然后按权重加总。排序整合在SQL里做也行但如果在Java层计算你就必须注意N1查询的问题——每个老师都要查一次评价表的话10个老师就是11次查询。我当时是先把教师列表一次性查出再按id批量查相关数据内存里做匹配性能至少快3倍。3.3 订单状态机与排课冲突校验订单是整个平台的主线我用一个简单的状态机来管理待支付0→ 待上课1→ 已完成2待支付超过30分钟自动取消家长可以主动取消待支付和待上课状态的订单上课完成后双方确认订单进入已完成状态此时家长才能评价。每次创建订单前必须要做排课冲突校验这是很多粗制滥造系统会漏掉的地方。校验逻辑是查询老师在该时间段开始时间到结束时间是否存在时间重叠的已接订单或已排课记录存在一律拒绝创建订单。SQL这样写SELECT COUNT(*) FROM order WHERE teacher_id #{teacherId} AND status IN (1, 2) AND #{endTime} start_time AND #{startTime} end_time这个重叠判断条件很经典两个区间[a,b]和[c,d]存在交集只要满足c b且a d即可。我在第一次实现时写成了start_time BETWEEN #{startTime} AND #{endTime}结果漏掉了订单完全包含已有排课的情况后来才发现这种写法只覆盖了一部分重叠场景。改成交集条件后各种边界情况全部覆盖了。3.4 评价系统与教师评分动态更新评价表的设计要精细一点id、order_id一个订单只能评价一次所以这个字段加唯一索引、rating1-5分、content、create_time。家长提交评价后transaction里要同时做两件事插入评价记录、更新老师的综合评分。评分字段放在teacher_info表里冗余存储这样列表页展示老师评分就只需要查教师表不需要每次都聚合review表。但这里有个体验细节容易忽略评价必须要在订单完成后7天内提交超过时间就锁定不能再评。这个限制一方面防止恶意刷评价另一方面也督促家长及时反馈。在代码上就用一个update语句配合时间条件来控制写起来很轻量。4. Android端核心模块与实现4.1 项目架构与Navigation底部导航设计Android端我遵循单Activity多Fragment的设计主界面一个MainActivity底部三个Tab首页找家教、订单我的订单、我的个人中心。Fragment之间的切换用FragmentManager FragmentTransaction不需要引入Navigation组件——那个对毕设来说配置太繁琐而且你现在不熟的话踩坑成本太高。底部导航栏用BottomNavigationView菜单资源里定义三个item每个item对应一个Fragment的tag切换时show/hide而不是replace。为什么这么做因为replace每次都会重新走一遍Fragment的生命周期导致网络请求重新执行用户翻个Tab回来数据全部刷新一遍体验非常差。show/hide的方式能保留Fragment的状态实测滑动列表位置不会被重置。4.2 Retrofit网络层封装与响应统一解析Android端网络层是整个项目最容易写乱的地方。我的做法是定义ApiService接口用注解声明后端所有接口然后用Retrofit.Builder创建实例配合GsonConverterFactory做JSON转换。统一的响应体Result 在Android端也用对应结构体映射解析完判断code是否为200不是就直接toast提示后端返回的消息。网络请求的异步处理用Retrofit的Callback机制就好不要因为图新鲜去引入RxJava。那会让数据流变得复杂而且你如果之前没接触过响应式编程光理解Observable和Observer的关系都要花不少时间。Callback虽然写起来显得啰嗦但逻辑清晰——onResponse处理成功、onFailure处理失败很适合这个项目。两三年前我帮人排查过一个bug用户上传头像后图片一直没显示查了半天发现是Android 10对文件访问权限收紧直接用file://协议打开相册选中的URI会崩溃。解决方案是用ContentResolver把URI拷贝到应用私有目录再交给Glide加载。这个坑新手必踩毕设里做头像上传功能时一定要提前处理。4.3 教师列表展示与筛选交互设计教师列表页用RecyclerView CardView的组合每个item展示老师的头像、昵称、主教科目、教龄、综合评分和价格。筛选条件用BottomSheetDialog弹出面板里面放科目、区域、价格范围等选项点击确定后重新请求列表接口。滑动加载更多用RecyclerView的OnScrollListener实现监听最后一个可见item的位置是否接近总数是就加载下一页。这里有个细节需要加一个isLoading标志位防止重复请求否则用户快速滑动时可能同时触发多次分页请求数据顺序就乱套了。每页我设20条一屏刚好放5个卡片滑动两三屏才触发一次加载交互节奏刚刚好。5. 数据库设计实战与核心建表语句5.1 核心表结构全解析把完整的建表SQL都贴出来不现实挑几张核心表说。用户表是最基础的字段包括id、phone、password、role、nickname、avatar、status、create_time。这里phone要加唯一索引platform登录直接绑定手机号不搞邮箱注册那套复杂流程。订单表的字段设计直接决定业务逻辑好不好写CREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, parent_id bigint(20) NOT NULL COMMENT 家长用户ID, teacher_id bigint(20) NOT NULL COMMENT 老师用户ID, subject_id bigint(20) NOT NULL COMMENT 科目ID, start_time datetime NOT NULL COMMENT 上课开始时间, end_time datetime NOT NULL COMMENT 上课结束时间, price decimal(10,2) NOT NULL COMMENT 订单金额, status int(11) NOT NULL DEFAULT 0 COMMENT 订单状态, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_teacher_time (teacher_id,start_time,end_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;order_no用yyyyMMddHHmmss 3位随机数生成这是最简单不会重复的方式。索引设计上联合索引teacher_id, start_time, end_time能极大加快排课冲突校验的查询速度这个索引在真实场景中就是量级上的性能差异。5.2 一对多与多对多关系的处理策略教师和科目之间是多对多关系需要一张关联表teacher_subject来维系字段就三个id、teacher_id、subject_id。科目表本身在系统里基本就是一个静态字典数学、英语、物理、化学、语文、生物、历史、地理、政治、钢琴、绘画、编程。毕设阶段直接在SQL初始化脚本里INSERT进去就行不用专门做科目管理功能。老师详情表teacher_info和用户表是一对一关系存放老师专属的信息教龄、学历、学校/机构、教学风格、每小时价格、可教区域等。为什么不分一张表全塞进user里因为家长端的用户根本不需要这些属性分表后逻辑更清晰而且这也能向老师展示你掌握了垂直分表的设计思路。6. 核心业务流程与代码实现6.1 下单流程的完整时序下单是整个系统里横跨前后端最多的业务建议先从时序层面理清楚家长在教师详情页点击预约试听→ 选择上课时间和时长 → 后端校验老师是否空闲 → 创建订单状态为待支付→ 家长确认支付 → 模拟支付成功回调 → 订单状态变为待上课。考虑到毕设没办法接真实支付渠道我用的方案是做一个模拟支付页面点击确认支付后直接跳转一个模拟支付成功的回调接口接口把订单状态更新为待上课。这个方案虽然是模拟的但业务闭环是完整的答辩时说明实际生产可替换为微信/支付宝官方SDK就够了。6.2 接口定义与Android端调用对齐前后端接口对齐的关键在字段命名。后端返回的JSON字段统一用驼峰命名法和Java属性保持一致这样Gson解析时不需要额外写SerializedName注解。日期格式统一为yyyy-MM-dd HH:mm:ss直接作为字符串传输Android端用SimpleDateFormat解析出Date对象再格式化展示。我列几个核心接口路径POST /api/auth/login登录、GET /api/teacher/list教师列表、GET /api/teacher/detail/{id}教师详情、POST /api/order/create创建订单、GET /api/order/my我的订单、POST /api/review/submit提交评价。这些接口路径在设计阶段就要定好写进接口文档里前后端各自照着文档开发能少吵很多架。6.3 教师端接单与日程管理老师端的核心场景是接单和排课。在我的日程页面老师可以看到自己所有时间段的排课情况支持手动添加和删除排课。排课数据存在course_schedule表里字段包含teacher_id、start_time、end_time、type1空闲、2已预约、3不可约。对老师来说这条时间轴就是他的可售卖资源。比较有意思的是推荐算法在这里的应用当家长浏览教师列表时我调了一个活跃推荐排序因子近期有排课活动的老师权重升高。这个功能看着不起眼但能体现你对业务的理解深度——平台需要鼓励老师保持活跃而不是注册完就消失。7. 前端关键页面与交互实现7.1 教师详情页的信息层级设计教师详情页直接决定家长会不会下单。我按这样的信息层级排布最顶部是大图头像和名字下面一排展示教龄、学历、评分三个标签再往下是ta的可教科目和价格区间继续往下是个人介绍和教学风格最后是评价列表。整个页面用NestedScrollView包裹评价列表嵌套RecyclerView时要注意设置setNestedScrollingEnabled(false)否则会出现滑动冲突。页面底部固定一个预约试听按钮颜色用平台主色点击后弹BottomSheetDialog选择上课时间。这个按钮要一直悬浮在页面底部用户浏览完所有信息后最自然的动作就是点击它。7.2 下拉刷新和加载状态的细节处理页面加载状态我用三种视图管理加载中显示居中ProgressBar加载失败显示带重试按钮的提示视图加载成功显示内容。用ViewStub按需inflate这三种状态视图比动态addView效率更高也避免了视图层级过深的问题。下拉刷新用SwipeRefreshLayout在onRefresh回调里重新请求第一页数据请求完成后调用setRefreshing(false)结束动画。这里有个很多人会忽略的坑如果刷新请求失败一定要结束刷新动画否则用户会看到转圈圈停不下来的诡异状态。正确做法是在finally代码块里调用setRefreshing(false)。8. 系统优化点与进阶提升方向8.1 服务端性能优化三板斧毕设如果能展示出性能优化意识答辩老师通常会高看一眼。我做了三件事第一教师列表接口开启了Spring Cache缓存key为teacherList:page:{page}:size:{size}缓存过期时间60秒有效降低数据库压力第二热门科目和评价数据用Redis缓存你就算只写几行RedisTemplate的get/set代码也足够展示你对缓存技术的理解第三SQL层面尽量覆盖索引避免在查询条件中使用函数导致索引失效。这里说个实际的缓存一致性经验我在写评价和更新教师评分的事务里手动删除对应教师的缓存key这样下次请求时就能拿到最新的评分数据。这种写操作删缓存的玩法虽然是Cache Aside Pattern的基础操作但在毕设里能自己悟出来并写出来说明你确实理解了缓存的核心逻辑。8.2 Android端体验优化细节Android端可以做很多小而美的优化图片加载用Glide配置占位图和错误图列表页的item布局用ConstraintLayout减少布局嵌套层级提升渲染速度大列表加setHasFixedSize(true)告诉RecyclerView尺寸不变跳过重新测量布局的过程。另外建议在项目里加一个BaseActivity和BaseFragment把网络请求的Loading对话框和错误Toast统一封装。这样每个页面的代码会清爽很多而且这种框架思维是导师喜欢的风格。8.3 功能扩展的想象空间做完全部功能后可以想想还有哪些地方能扩展增加消息推送功能的话可以用WebSocket实现站内聊天增加后台数据分析的话可以在管理员端加订单统计报表按天/周/月维度展示GMV增长曲线增加推荐系统的话可以基于用户行为记录做猜你喜欢的教师推荐。这些扩展方向在论文的未来展望章节里写出来既能体现你思考的深度又不会给自己增加实际工作量。我当年就是这么干的老师看完后特意在答辩时问了一圈扩展方案的技术实现思路。9. 常见问题与排查技巧实录9.1 跨域问题与Android请求失败的区分前后端联调时最容易碰到的就是请求失败。如果你用浏览器调试接口发现一切正常但Android端请求总是走onFailure大概率是网络请求被拒绝。排查方法先在AndroidManifest.xml确认加了INTERNET权限——这个问题出现频率高到令人发指再看是不是用了http明文请求Android 9.0之后默认禁止明文流量需要在manifest里配置usesCleartextTraffictrue或者在networkSecurityConfig里配置域名白名单。如果你是后端接口在浏览器里直接访问出现跨域报错记得加一个CorsFilter或者用CrossOrigin注解解决。这在前后端分离项目里是必踩的坑提前处理能省一晚上时间。9.2 时间参数时区和格式不一致问题Java后端默认的日期解析格式是ISO标准的yyyy-MM-ddTHH:mm:ss.SSSZ但前端传来的可能是yyyy-MM-dd HH:mm:ss直接用RequestBody接收会导致解析失败。解决方案是用JsonFormat注解标注时间字段的格式同时指定timezone为GMT8避免时区偏移导致时间差8小时的问题。这个坑我第一次做项目时踩过排查了整整一个晚上最后发现是Jackson反序列化默认不带解析自定义格式导致的。后来我在所有LocalDateTime字段上都加了JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)从此再没为时间格式头疼过。9.3 Android内存泄漏的几个典型场景Android端的内存泄漏问题可以从源头避免Activity里持有静态Context引用、Handler匿名内部类持有Activity引用、网络请求回调在Activity销毁后仍然执行、Bitmap没有及时回收。我的建议是网络请求用ApplicationContext起步回调回来后判断Activity是否已经isFinishing是就直接return不再更新UI。实际项目里我用IntentService处理头像上传的任务这样Activity销毁了任务也能继续执行上传完成后再通过EventBus通知刷新。虽然EventBus现在有点被嫌弃但毕设里用起来非常顺手而且这套模式在真实项目中也很常见。10. 部署发布与环境配置经验10.1 后端打包部署的完整流程后端部署我用的是阿里云的一台2核4G的轻量应用服务器操作系统Ubuntu 22.04安装JDK 17和MySQL 8.0。打包时用mvn clean package -DskipTests生成jar包通过scp命令传到服务器 /home/app 目录下用nohup java -jar xxx.jar app.log 21 启动。生产环境和本地环境用不同的application-xxx.yml配置文件通过启动参数--spring.profiles.activeprod指定。数据库连接、Redis地址这些敏感配置不要写死在代码里通过环境变量注入。这样代码仓库里的配置都是脱敏的安全习惯从毕设就开始养成。10.2 Android签名打包与真机调试Android端调试时强烈建议直接连真机调试不要用模拟器。模拟器虽然看起来方便但冷启动慢、GPS模拟麻烦、相机权限需要额外配置这些限制都会影响家教App这种真实业务App的调试体验。我用的是小米手机开USB调试Android Studio直接识别设备一键run到手机上看到效果的速度比模拟器快三倍。正式签名打包时在build.gradle里配置好签名证书生成release APK放到服务器上提供下载。这里有个加分项可以做一张二维码用Android的Scan QR Code功能扫码下载安装包演示的时候非常炫酷而且让老师感觉到这个系统真的是可交付的。11. 项目答辩指南与亮点包装11.1 演示流程图与核心卖点提炼答辩演示的时候按这条主线讲故事从家长搜索家教开始 → 查看老师详情和评价 → 选择时段预约试听 → 支付创建订单 → 老师端确认接单 → 排课日程更新 → 上课完成后评价 → 评分动态更新到列表页。这条链路一气呵成能向老师展示整个系统的完整度和业务闭环。核心卖点提炼三个词全栈前端Android后端Spring Boot数据库MySQL、闭环订单状态从创建到完成全流程管理、体验教师筛选、评分算法、排课冲突校验这些功能细节。这三个词在汇报开场就抛出来定好基调后面演示的时候不断呼应。11.2 常见答辩问题应对策略老师最爱问的问题基本集中在几个方向为什么选这个技术栈订单状态是怎么管理的并发场景下有没有考虑超卖问题你作为毕设项目怎么防止一个老师的同一时间段被多个家长同时预约超卖问题这个值得提前做准备。我在下单接口里用数据库层面的条件更新来保证原子性UPDATE teacher_schedule SET status 2 WHERE id #{id} AND status 1如果返回影响行数为0说明已经被抢了这一点在并发场景下能保证不会出现同一位老师同一时段被两个人约走的情况。把这条SQL的逻辑在答辩时讲出来老师就能看出来你确实思考过并发问题。还有老师会问JWT和传统Session有什么区别为什么不用OAuth2.0你的回答思路是JWT无状态适合移动端和分布式场景OAuth2.0更适合开放平台给第三方授权登录的场景我们这个系统自己管理用户体系JWT方案更简洁高效。最后再说说做这个项目我个人的心态变化。刚开始写订单模块的时候我以为最难的是Android界面怎么画得好看但真正做下来才发现数据库表怎么设计、接口怎么定义、状态怎么流转才是核心难点。前端界面反而是在后端逻辑理清楚之后水到渠成的事情。所以如果你也在准备做一个类似的系统我真心建议你先花三天时间把表结构和接口设计文档写透再动手写代码。你会发现后面的开发速度快到超乎想象而且这种先设计再编码的做事习惯到实际工作中比掌握某个具体框架值钱得多。 
长河君 · 2026/10/5 18:39:34 · 阅读 1.2k 基于Spring Boot与Android的家教服务平台全栈设计与实现
1. 项目背景与整体设计思路这个选题我第一眼看到就想拍大腿典型的技术栈好看业务能落地型毕设题目。Spring Boot做后端接口Android做前端移动端中间再配上MySQL存数据一套完整的家教服务平台就出来了。你说它是管理系统其实本质上是一个双向匹配的在线平台——家长端找家教、家教端接单子中间夹杂订单、评价、排课、结算这一条完整的业务链。先聊聊为什么这个题适合做毕业设计因为它的复杂度刚好卡在能把你和其他人区分开的位置。你要是只做一个普通的CRUD管理系统老师一眼就能看穿但加上订单状态机、教师等级认证、家长评价体系之后整个系统的业务完整性立刻不一样了。而且Spring Boot Android这个组合本身就自带话题性答辩的时候老师问什么你都能接得上话。再说说场景怎么拆。一个合格的家教平台至少要覆盖三类角色管理员、家长、家教老师。家长端要能浏览老师列表、按科目筛选、看评分、下单预约家教老师要能上传资质、管理自己的课程时间、接受或拒绝订单管理员则要负责审核老师资质、处理投诉、统计平台数据。这三条线合在一起才是完整的家教管理系统缺了任何一条线都只是半成品。从技术演进的角度看其实现在很多人会纠结要不要用小程序替代Android端我的看法是毕设直接用Android原生就行原因后面工具选型部分详细说。这里先明确一个共识——做这个项目的核心目标不是真的上线运营而是通过一个完整的全栈项目展示你对前端交互后端接口数据库设计的整合能力。2. 技术选型与核心原理2.1 Spring Boot 3.x MyBatis Plus 的组合逻辑后端我推荐直接用Spring Boot 3.x配合MyBatis Plus这是目前Java系毕设里的主流搭配。Spring Boot负责把整个Web服务的骨架搭起来内嵌Tomcat一行代码都不用配就能跑起来这对时间紧张的毕业生来说太友好了。MyBatis Plus相比纯MyBatis的优势在于单表CRUD根本不用写SQLBaseMapper里那些insert、selectById、updateById直接拿来用省下来的时间都够你把订单状态机多写两个状态了。不过我要提醒一句MyBatis Plus不是万能药多表关联查询老老实实自己写XML里的SQL别硬套它那个Wrapper很多时候查出来的字段对不上会让你排查到怀疑人生。接口设计上走RESTful风格统一返回Result对象code message dataAndroid端拿到这个结构体再解析协作效率会高很多。权限认证用JWT登录成功后颁发一个有效期为24小时的tokenAndroid端保存到SharedPreferences里每次请求带上Authorization头就行。为什么不用SessionAndroid端不像浏览器会自动管理Cookie用JWT免去了很多会话同步的麻烦而且天然支持无状态扩展这点在答辩的时候可以拿出来说。2.2 Android原生开发到底选Java还是Kotlin现在去搜Android开发相关内容铺天盖地都是Kotlin但我不建议毕设一上来就啃Kotlin除非你之前已经用Kotlin写过项目。原因是大部分学校的Android课程还是用Java教的你需要在短时间内同时搞明白Activity生命周期、RecyclerView适配器、网络请求回调这几个硬骨头没必要再叠加一门新语言的认知负担。当然你完全可以最后冲刺阶段把代码重构成Kotlin这属于锦上添花。但核心逻辑用Java写完并且能跑通比什么都强。Android端架构上我建议MVP就够了Activity当View层Presenter负责业务逻辑Model管数据。MVVM也行但LiveData ViewModel这套组合对于毕设来说有点over-engineering你还要处理生命周期绑定的细节时间不划算。网络框架用OkHttp Retrofit。Retrofit的注解式接口定义方式非常适合这种前后端分离的协作模式后端接口一定义好Android端照着接口文档写interface就行自动把JSON解析成Java对象。JSON解析就用Gson简单直接都是Java系的东西配合格外顺畅。2.3 数据库选型和表结构设计的第一性原理MySQL 8.0是标配这没什么好纠结的。关键在于表结构怎么设计——这决定了你的业务逻辑是清晰还是混乱。我见过太多人做毕设时随手下两张表就开始写代码结果到后面订单状态一复杂整个系统直接崩盘。一个家教平台的核心表我建议至少包含这些用户表user、老师详情表teacher_info、科目表subject、老师科目关联表teacher_subject、订单表order、排课表course_schedule、评价表review、收藏表favorite、公告表notice。这些表之间的外键关系要不要物理外键我建议不要逻辑外键就够了。毕业设计阶段物理外键的维护成本大于收益而且你答辩时完全可以说生产环境通常禁用物理外键以保证扩展性这反而是加分项。订单状态这块单独强调一下用int类型存状态码0待支付、1待上课、2已上课、3已完成、4已取消、5退款中。不要直接存字符串状态码配合常量类或者枚举类使用可读性照样高而且后续要统计所有退款订单这种数据的时候写SQL会舒服很多。3. 后端核心模块设计与实现3.1 基于JWT的登录认证与角色权限控制登录这块是整个系统的入口做得不好后面全崩。我的方案是登录接口接收手机号和密码校验通过后用JJWT库生成tokentoken的payload里塞userId和role字段1管理员、2家长、3老师然后返回给客户端。后续请求通过拦截器解析token把用户信息放到ThreadLocal里业务层随时能拿到当前操作人。角色权限控制用一个自定义注解RequireRole配合Spring拦截器在handler执行前做校验。比如发布公告这个接口标注RequireRole(1)家教接单接口标注RequireRole(3)家长下单接口标注RequireRole(2)。代码看起来是这样PostMapping(/order/create) RequireRole(2) public ResultString createOrder(RequestBody OrderCreateRequest request) { // 业务逻辑... }拦截器里先解析token再检查当前用户角色是否匹配注解要求不匹配直接返回403。另外密码存储必须用BCrypt加密spring-security-crypto这个依赖单独拎出来用就行不需要引入整套Spring Security。BCrypt有个特点每次加密同一个密码得到的密文都不一样因为内部带了随机盐这比MD5那种固定哈希值安全一个数量级。3.2 家教检索的核心算法与实现家长端最核心的功能就是搜索家教这决定了平台的使用体验。我的实现逻辑是按科目id 区域 价格区间 综合评分做组合筛选分页返回教师列表。综合评分的计算是(科目匹配分数×0.4 教龄分数×0.2 评价分数×0.4)每个维度都归一化到0-5分用这个算出来的分数做排序。这个算法的关键在于打分的规则要讲得清楚答辩的时候这是重点展示环节。你在代码里封装一个ScoreCalculator类从teacher_subject表里取科目匹配度从teacher_info里取教龄从review表里AVG出评价分然后按权重加总。排序整合在SQL里做也行但如果在Java层计算你就必须注意N1查询的问题——每个老师都要查一次评价表的话10个老师就是11次查询。我当时是先把教师列表一次性查出再按id批量查相关数据内存里做匹配性能至少快3倍。3.3 订单状态机与排课冲突校验订单是整个平台的主线我用一个简单的状态机来管理待支付0→ 待上课1→ 已完成2待支付超过30分钟自动取消家长可以主动取消待支付和待上课状态的订单上课完成后双方确认订单进入已完成状态此时家长才能评价。每次创建订单前必须要做排课冲突校验这是很多粗制滥造系统会漏掉的地方。校验逻辑是查询老师在该时间段开始时间到结束时间是否存在时间重叠的已接订单或已排课记录存在一律拒绝创建订单。SQL这样写SELECT COUNT(*) FROM order WHERE teacher_id #{teacherId} AND status IN (1, 2) AND #{endTime} start_time AND #{startTime} end_time这个重叠判断条件很经典两个区间[a,b]和[c,d]存在交集只要满足c b且a d即可。我在第一次实现时写成了start_time BETWEEN #{startTime} AND #{endTime}结果漏掉了订单完全包含已有排课的情况后来才发现这种写法只覆盖了一部分重叠场景。改成交集条件后各种边界情况全部覆盖了。3.4 评价系统与教师评分动态更新评价表的设计要精细一点id、order_id一个订单只能评价一次所以这个字段加唯一索引、rating1-5分、content、create_time。家长提交评价后transaction里要同时做两件事插入评价记录、更新老师的综合评分。评分字段放在teacher_info表里冗余存储这样列表页展示老师评分就只需要查教师表不需要每次都聚合review表。但这里有个体验细节容易忽略评价必须要在订单完成后7天内提交超过时间就锁定不能再评。这个限制一方面防止恶意刷评价另一方面也督促家长及时反馈。在代码上就用一个update语句配合时间条件来控制写起来很轻量。4. Android端核心模块与实现4.1 项目架构与Navigation底部导航设计Android端我遵循单Activity多Fragment的设计主界面一个MainActivity底部三个Tab首页找家教、订单我的订单、我的个人中心。Fragment之间的切换用FragmentManager FragmentTransaction不需要引入Navigation组件——那个对毕设来说配置太繁琐而且你现在不熟的话踩坑成本太高。底部导航栏用BottomNavigationView菜单资源里定义三个item每个item对应一个Fragment的tag切换时show/hide而不是replace。为什么这么做因为replace每次都会重新走一遍Fragment的生命周期导致网络请求重新执行用户翻个Tab回来数据全部刷新一遍体验非常差。show/hide的方式能保留Fragment的状态实测滑动列表位置不会被重置。4.2 Retrofit网络层封装与响应统一解析Android端网络层是整个项目最容易写乱的地方。我的做法是定义ApiService接口用注解声明后端所有接口然后用Retrofit.Builder创建实例配合GsonConverterFactory做JSON转换。统一的响应体Result 在Android端也用对应结构体映射解析完判断code是否为200不是就直接toast提示后端返回的消息。网络请求的异步处理用Retrofit的Callback机制就好不要因为图新鲜去引入RxJava。那会让数据流变得复杂而且你如果之前没接触过响应式编程光理解Observable和Observer的关系都要花不少时间。Callback虽然写起来显得啰嗦但逻辑清晰——onResponse处理成功、onFailure处理失败很适合这个项目。两三年前我帮人排查过一个bug用户上传头像后图片一直没显示查了半天发现是Android 10对文件访问权限收紧直接用file://协议打开相册选中的URI会崩溃。解决方案是用ContentResolver把URI拷贝到应用私有目录再交给Glide加载。这个坑新手必踩毕设里做头像上传功能时一定要提前处理。4.3 教师列表展示与筛选交互设计教师列表页用RecyclerView CardView的组合每个item展示老师的头像、昵称、主教科目、教龄、综合评分和价格。筛选条件用BottomSheetDialog弹出面板里面放科目、区域、价格范围等选项点击确定后重新请求列表接口。滑动加载更多用RecyclerView的OnScrollListener实现监听最后一个可见item的位置是否接近总数是就加载下一页。这里有个细节需要加一个isLoading标志位防止重复请求否则用户快速滑动时可能同时触发多次分页请求数据顺序就乱套了。每页我设20条一屏刚好放5个卡片滑动两三屏才触发一次加载交互节奏刚刚好。5. 数据库设计实战与核心建表语句5.1 核心表结构全解析把完整的建表SQL都贴出来不现实挑几张核心表说。用户表是最基础的字段包括id、phone、password、role、nickname、avatar、status、create_time。这里phone要加唯一索引platform登录直接绑定手机号不搞邮箱注册那套复杂流程。订单表的字段设计直接决定业务逻辑好不好写CREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, parent_id bigint(20) NOT NULL COMMENT 家长用户ID, teacher_id bigint(20) NOT NULL COMMENT 老师用户ID, subject_id bigint(20) NOT NULL COMMENT 科目ID, start_time datetime NOT NULL COMMENT 上课开始时间, end_time datetime NOT NULL COMMENT 上课结束时间, price decimal(10,2) NOT NULL COMMENT 订单金额, status int(11) NOT NULL DEFAULT 0 COMMENT 订单状态, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_teacher_time (teacher_id,start_time,end_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;order_no用yyyyMMddHHmmss 3位随机数生成这是最简单不会重复的方式。索引设计上联合索引teacher_id, start_time, end_time能极大加快排课冲突校验的查询速度这个索引在真实场景中就是量级上的性能差异。5.2 一对多与多对多关系的处理策略教师和科目之间是多对多关系需要一张关联表teacher_subject来维系字段就三个id、teacher_id、subject_id。科目表本身在系统里基本就是一个静态字典数学、英语、物理、化学、语文、生物、历史、地理、政治、钢琴、绘画、编程。毕设阶段直接在SQL初始化脚本里INSERT进去就行不用专门做科目管理功能。老师详情表teacher_info和用户表是一对一关系存放老师专属的信息教龄、学历、学校/机构、教学风格、每小时价格、可教区域等。为什么不分一张表全塞进user里因为家长端的用户根本不需要这些属性分表后逻辑更清晰而且这也能向老师展示你掌握了垂直分表的设计思路。6. 核心业务流程与代码实现6.1 下单流程的完整时序下单是整个系统里横跨前后端最多的业务建议先从时序层面理清楚家长在教师详情页点击预约试听→ 选择上课时间和时长 → 后端校验老师是否空闲 → 创建订单状态为待支付→ 家长确认支付 → 模拟支付成功回调 → 订单状态变为待上课。考虑到毕设没办法接真实支付渠道我用的方案是做一个模拟支付页面点击确认支付后直接跳转一个模拟支付成功的回调接口接口把订单状态更新为待上课。这个方案虽然是模拟的但业务闭环是完整的答辩时说明实际生产可替换为微信/支付宝官方SDK就够了。6.2 接口定义与Android端调用对齐前后端接口对齐的关键在字段命名。后端返回的JSON字段统一用驼峰命名法和Java属性保持一致这样Gson解析时不需要额外写SerializedName注解。日期格式统一为yyyy-MM-dd HH:mm:ss直接作为字符串传输Android端用SimpleDateFormat解析出Date对象再格式化展示。我列几个核心接口路径POST /api/auth/login登录、GET /api/teacher/list教师列表、GET /api/teacher/detail/{id}教师详情、POST /api/order/create创建订单、GET /api/order/my我的订单、POST /api/review/submit提交评价。这些接口路径在设计阶段就要定好写进接口文档里前后端各自照着文档开发能少吵很多架。6.3 教师端接单与日程管理老师端的核心场景是接单和排课。在我的日程页面老师可以看到自己所有时间段的排课情况支持手动添加和删除排课。排课数据存在course_schedule表里字段包含teacher_id、start_time、end_time、type1空闲、2已预约、3不可约。对老师来说这条时间轴就是他的可售卖资源。比较有意思的是推荐算法在这里的应用当家长浏览教师列表时我调了一个活跃推荐排序因子近期有排课活动的老师权重升高。这个功能看着不起眼但能体现你对业务的理解深度——平台需要鼓励老师保持活跃而不是注册完就消失。7. 前端关键页面与交互实现7.1 教师详情页的信息层级设计教师详情页直接决定家长会不会下单。我按这样的信息层级排布最顶部是大图头像和名字下面一排展示教龄、学历、评分三个标签再往下是ta的可教科目和价格区间继续往下是个人介绍和教学风格最后是评价列表。整个页面用NestedScrollView包裹评价列表嵌套RecyclerView时要注意设置setNestedScrollingEnabled(false)否则会出现滑动冲突。页面底部固定一个预约试听按钮颜色用平台主色点击后弹BottomSheetDialog选择上课时间。这个按钮要一直悬浮在页面底部用户浏览完所有信息后最自然的动作就是点击它。7.2 下拉刷新和加载状态的细节处理页面加载状态我用三种视图管理加载中显示居中ProgressBar加载失败显示带重试按钮的提示视图加载成功显示内容。用ViewStub按需inflate这三种状态视图比动态addView效率更高也避免了视图层级过深的问题。下拉刷新用SwipeRefreshLayout在onRefresh回调里重新请求第一页数据请求完成后调用setRefreshing(false)结束动画。这里有个很多人会忽略的坑如果刷新请求失败一定要结束刷新动画否则用户会看到转圈圈停不下来的诡异状态。正确做法是在finally代码块里调用setRefreshing(false)。8. 系统优化点与进阶提升方向8.1 服务端性能优化三板斧毕设如果能展示出性能优化意识答辩老师通常会高看一眼。我做了三件事第一教师列表接口开启了Spring Cache缓存key为teacherList:page:{page}:size:{size}缓存过期时间60秒有效降低数据库压力第二热门科目和评价数据用Redis缓存你就算只写几行RedisTemplate的get/set代码也足够展示你对缓存技术的理解第三SQL层面尽量覆盖索引避免在查询条件中使用函数导致索引失效。这里说个实际的缓存一致性经验我在写评价和更新教师评分的事务里手动删除对应教师的缓存key这样下次请求时就能拿到最新的评分数据。这种写操作删缓存的玩法虽然是Cache Aside Pattern的基础操作但在毕设里能自己悟出来并写出来说明你确实理解了缓存的核心逻辑。8.2 Android端体验优化细节Android端可以做很多小而美的优化图片加载用Glide配置占位图和错误图列表页的item布局用ConstraintLayout减少布局嵌套层级提升渲染速度大列表加setHasFixedSize(true)告诉RecyclerView尺寸不变跳过重新测量布局的过程。另外建议在项目里加一个BaseActivity和BaseFragment把网络请求的Loading对话框和错误Toast统一封装。这样每个页面的代码会清爽很多而且这种框架思维是导师喜欢的风格。8.3 功能扩展的想象空间做完全部功能后可以想想还有哪些地方能扩展增加消息推送功能的话可以用WebSocket实现站内聊天增加后台数据分析的话可以在管理员端加订单统计报表按天/周/月维度展示GMV增长曲线增加推荐系统的话可以基于用户行为记录做猜你喜欢的教师推荐。这些扩展方向在论文的未来展望章节里写出来既能体现你思考的深度又不会给自己增加实际工作量。我当年就是这么干的老师看完后特意在答辩时问了一圈扩展方案的技术实现思路。9. 常见问题与排查技巧实录9.1 跨域问题与Android请求失败的区分前后端联调时最容易碰到的就是请求失败。如果你用浏览器调试接口发现一切正常但Android端请求总是走onFailure大概率是网络请求被拒绝。排查方法先在AndroidManifest.xml确认加了INTERNET权限——这个问题出现频率高到令人发指再看是不是用了http明文请求Android 9.0之后默认禁止明文流量需要在manifest里配置usesCleartextTraffictrue或者在networkSecurityConfig里配置域名白名单。如果你是后端接口在浏览器里直接访问出现跨域报错记得加一个CorsFilter或者用CrossOrigin注解解决。这在前后端分离项目里是必踩的坑提前处理能省一晚上时间。9.2 时间参数时区和格式不一致问题Java后端默认的日期解析格式是ISO标准的yyyy-MM-ddTHH:mm:ss.SSSZ但前端传来的可能是yyyy-MM-dd HH:mm:ss直接用RequestBody接收会导致解析失败。解决方案是用JsonFormat注解标注时间字段的格式同时指定timezone为GMT8避免时区偏移导致时间差8小时的问题。这个坑我第一次做项目时踩过排查了整整一个晚上最后发现是Jackson反序列化默认不带解析自定义格式导致的。后来我在所有LocalDateTime字段上都加了JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)从此再没为时间格式头疼过。9.3 Android内存泄漏的几个典型场景Android端的内存泄漏问题可以从源头避免Activity里持有静态Context引用、Handler匿名内部类持有Activity引用、网络请求回调在Activity销毁后仍然执行、Bitmap没有及时回收。我的建议是网络请求用ApplicationContext起步回调回来后判断Activity是否已经isFinishing是就直接return不再更新UI。实际项目里我用IntentService处理头像上传的任务这样Activity销毁了任务也能继续执行上传完成后再通过EventBus通知刷新。虽然EventBus现在有点被嫌弃但毕设里用起来非常顺手而且这套模式在真实项目中也很常见。10. 部署发布与环境配置经验10.1 后端打包部署的完整流程后端部署我用的是阿里云的一台2核4G的轻量应用服务器操作系统Ubuntu 22.04安装JDK 17和MySQL 8.0。打包时用mvn clean package -DskipTests生成jar包通过scp命令传到服务器 /home/app 目录下用nohup java -jar xxx.jar app.log 21 启动。生产环境和本地环境用不同的application-xxx.yml配置文件通过启动参数--spring.profiles.activeprod指定。数据库连接、Redis地址这些敏感配置不要写死在代码里通过环境变量注入。这样代码仓库里的配置都是脱敏的安全习惯从毕设就开始养成。10.2 Android签名打包与真机调试Android端调试时强烈建议直接连真机调试不要用模拟器。模拟器虽然看起来方便但冷启动慢、GPS模拟麻烦、相机权限需要额外配置这些限制都会影响家教App这种真实业务App的调试体验。我用的是小米手机开USB调试Android Studio直接识别设备一键run到手机上看到效果的速度比模拟器快三倍。正式签名打包时在build.gradle里配置好签名证书生成release APK放到服务器上提供下载。这里有个加分项可以做一张二维码用Android的Scan QR Code功能扫码下载安装包演示的时候非常炫酷而且让老师感觉到这个系统真的是可交付的。11. 项目答辩指南与亮点包装11.1 演示流程图与核心卖点提炼答辩演示的时候按这条主线讲故事从家长搜索家教开始 → 查看老师详情和评价 → 选择时段预约试听 → 支付创建订单 → 老师端确认接单 → 排课日程更新 → 上课完成后评价 → 评分动态更新到列表页。这条链路一气呵成能向老师展示整个系统的完整度和业务闭环。核心卖点提炼三个词全栈前端Android后端Spring Boot数据库MySQL、闭环订单状态从创建到完成全流程管理、体验教师筛选、评分算法、排课冲突校验这些功能细节。这三个词在汇报开场就抛出来定好基调后面演示的时候不断呼应。11.2 常见答辩问题应对策略老师最爱问的问题基本集中在几个方向为什么选这个技术栈订单状态是怎么管理的并发场景下有没有考虑超卖问题你作为毕设项目怎么防止一个老师的同一时间段被多个家长同时预约超卖问题这个值得提前做准备。我在下单接口里用数据库层面的条件更新来保证原子性UPDATE teacher_schedule SET status 2 WHERE id #{id} AND status 1如果返回影响行数为0说明已经被抢了这一点在并发场景下能保证不会出现同一位老师同一时段被两个人约走的情况。把这条SQL的逻辑在答辩时讲出来老师就能看出来你确实思考过并发问题。还有老师会问JWT和传统Session有什么区别为什么不用OAuth2.0你的回答思路是JWT无状态适合移动端和分布式场景OAuth2.0更适合开放平台给第三方授权登录的场景我们这个系统自己管理用户体系JWT方案更简洁高效。最后再说说做这个项目我个人的心态变化。刚开始写订单模块的时候我以为最难的是Android界面怎么画得好看但真正做下来才发现数据库表怎么设计、接口怎么定义、状态怎么流转才是核心难点。前端界面反而是在后端逻辑理清楚之后水到渠成的事情。所以如果你也在准备做一个类似的系统我真心建议你先花三天时间把表结构和接口设计文档写透再动手写代码。你会发现后面的开发速度快到超乎想象而且这种先设计再编码的做事习惯到实际工作中比掌握某个具体框架值钱得多。