每年三四月份我接到的毕设咨询里有一大半都指向同一个题目基于springbootAndroid的计算机精品课程学习系统。这个题看起来是老面孔但把后端、移动端、数据库、文件存储、用户权限全部串在一起它的覆盖度在毕设里其实相当能打。这篇东西我想以一位反复和这类项目打交道的人的身份把这套系统从选型、数据表设计、后端接口、Android端实现、前后端联调一路讲到设计文档和答辩现场要怎么准备把能想到的坑提前摆到桌面上。很多同学拿到类似的题第一反应是上网找源码找到后跑起来就以为完事了。实际上一个能稳定演示、能回答老师追问、能通过查重的毕业设计靠的是把每一步都想清楚为什么这么做。下面我按实际开发顺序拆开来讲尽量少说空话多给可以直接抄的配置和思路。1. 选型复盘SpringBoot加Android这套组合为什么一直没人愿意换1.1 先把题目拆成要交付什么再谈代码拿到计算机精品课程学习系统这个题目第一件事不是开IDE而是把交付物列清楚。一般这类题目落到具体形态至少要包含三块内容管理端的课程维护能力、学生端的课程浏览与视频学习能力、以及记录学习行为的数据支撑。如果细化成功能点就是用户注册登录、课程列表与分类筛选、课程详情展示、视频播放、学习进度记录、收藏以及后台的课程和用户管理。把功能清单写在纸上之后你才能判断自己缺什么。很多同学跑起来的所谓完整源码其实只是前台展示后台管理、进度记录、权限控制全是空的等到演示阶段老师随便问一个用户学习到一半退出后进度怎么恢复场面就很尴尬。反过来你在动手前把模块拆清楚后面写代码的节奏会完全不一样。1.2 小程序和混合开发都没有成为首选原因在这也有同学问我现在移动端为什么不选小程序或者用跨平台框架做一个偏要写原生Android我用一个对比表说清楚方案开发效率移动端特性展示答辩深度风险点SpringBoot Android原生中等可讲的多生命周期、权限、组件深面试也可复用联调细节多SpringBoot 微信小程序快受限偏前端浅容易被追问兼容性注册审核、组件限制SpringBoot Uniapp快不好展开原生原理中等容易变成套壳SSM JSP较快无移动端比较常规技术栈偏旧从这个表能明显看出来原生Android虽然前期写起来麻烦但答辩时能展开的点和面试时能讲的项目经验都更扎实。毕设的首要目标是能讲清楚而不是写代码最省事。所以你问我为什么不推荐大家都去搞小程序答案很简单题目里顶着Android三个字你用跨平台方案遇到较真的老师会让你解释为什么要绕开Android原生开发那是给自己挖坑。1.3 开发环境的版本组合建议版本选择上我比较推荐一套稳定组合JDK 8加上Spring Boot 2.7.x配合MySQL 5.7或者8.0Android端用Android Studio配compileSdk 34、minSdk 24。为什么不用最新的Spring Boot 3.x因为3.x强制要求JDK 17不少第三方依赖和配置方式都变了你查资料时看到的大部分教程还是基于2.x遇到报错会浪费很多时间。Spring Boot 2.7.x这个版本的好处是生态非常成熟MyBatis Plus、JWT、文件上传这些常用的东西都有大量现成例子可以参考。Android端minSdk定在24能覆盖绝大多数真机又不至于因为适配老机型给自己找麻烦。targetSdk尽量用33或34因为太老的目标SDK在高版本手机上安装或访问网络会有各种奇怪限制。这些版本号看起来无关紧要但我在帮别人排查问题时遇到最多的情况就是版本错配用了JDK 17却跑Spring Boot 2.3或者Android的Gradle插件版本与SDK不匹配。建议本地环境按照上面的组合一口气装好后面几乎不会因为环境问题卡住。2. 从需求到数据库课程学习系统的实体划分与建表细节2.1 功能模块拆解数据库设计是整个系统最该花时间的地方。很多拿到现成代码的同学数据库表改都不改课程列表、学习进度、收藏这些模块各表之间根本没有关联跑起来几十条假数据看不出问题一交到自己手里要用的时候就崩溃。按照前面拆的需求我把这套系统的实体最基本地划成这么几个用户、课程、课程章节、视频资源、学习记录、收藏。如果还想加互动可以再加评论表但建议先评估自己的时间实在做不完可以先留出位置答辩时说成扩展功能。每个实体的职责要清楚。课程是用来描述一门精品课的基本信息章节是课程内部的组织单位视频资源挂在章节下面。学习记录最核心它记录的是某个用户在某个视频上看到了第几秒。如果不把这段关系理清后面写联表查询时会非常痛苦。2.2 核心表结构与字段设计下面给出我实际搭这类系统时会用的基础建表SQL字段名可以直接复用也可以按自己习惯微调CREATE TABLE user ( id int NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL, password varchar(100) NOT NULL, nickname varchar(50) DEFAULT NULL, avatar varchar(255) DEFAULT NULL, role tinyint DEFAULT 0 COMMENT 0-学生 1-管理员, status tinyint DEFAULT 1, create_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE course ( id int NOT NULL AUTO_INCREMENT, title varchar(100) NOT NULL, cover varchar(255) DEFAULT NULL COMMENT 封面图地址, category_id int DEFAULT NULL, profile text COMMENT 课程简介, teacher varchar(50) DEFAULT NULL, status tinyint DEFAULT 1 COMMENT 1-上架 0-下架, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE chapter ( id int NOT NULL AUTO_INCREMENT, course_id int NOT NULL, title varchar(100) NOT NULL, sort_no int DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE video ( id int NOT NULL AUTO_INCREMENT, chapter_id int NOT NULL, title varchar(100) DEFAULT NULL, video_url varchar(255) DEFAULT NULL, duration int DEFAULT 0 COMMENT 视频时长(秒), sort_no int DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE study_progress ( id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL, video_id int NOT NULL, progress int DEFAULT 0 COMMENT 观看进度(秒), course_id int DEFAULT 0, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_user_video (user_id, video_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE favorite ( id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL, course_id int NOT NULL, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段SQL里有两个细节值得说明。第一study_progress用了user_id和video_id的联合唯一约束目的是防止同一个人反复学习同一个视频时插入多条记录。后端的更新逻辑可以做成存在就更新不存在就插入这比每次都新增一条更符合实际场景。第二video表单独拆出来而不是直接塞在chapter里是因为一个章节下可能挂多个视频比如分上下两集拆开后扩展性更好。2.3 表关系和删除策略怎么定我建议不要在MySQL里加物理外键只用逻辑关联。道理其实很简单用物理外键时删除课程数据会因为关联记录卡住或者必须级联删除写起来束手束脚不用外键只需要在业务代码里控制好删除顺序。我一般用course_id这样的普通索引字段做关联查询时用JOIN或子查询这样表结构清爽也不影响性能。删除策略上推荐加一个status或者is_deleted字段做逻辑删除。比如课程下架不是直接DELETE而是把status改成0。这样做有两个好处一是用户收藏过的课程即使被下架历史记录还可以保留二是你不小心删错数据时恢复成本极低。很多同学刚写完就图省事用物理删除等管理工作做到一半就会发现收藏表和进度表还在引用那条已消失的课程数据。这类系统里数据之间是牵一发动全身的关系逻辑删除是对的。3. 后端接口不能含糊的三件事统一返回结构、鉴权、文件访问3.1 接口设计与统一返回结构后端接口设计直接影响Android端的开发难度。我见过最累的联调方式是前端定义一套返回格式后端又定义另一套两边对着接口文档互相迁就。我的做法很固定定义一个通用结果类public class ResultT { private Integer code; private String msg; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.msg success; r.data data; return r; } public static T ResultT error(Integer code, String msg) { ResultT r new Result(); r.code code; r.msg msg; return r; } }这样所有接口的返回值都是同一个结构Android端在解析时只需要写一次通用解析逻辑。接口路径建议统一前缀/api把用户、课程、进度相关接口分开。举个例子登录是POST /api/user/login课程列表是GET /api/course/list视频信息是GET /api/video/detail/{id}进度上报是POST /api/progress/update。写接口文档时把请求参数、返回示例、可能的错误码列成表格这份文档后面写设计说明书也能直接用一举两得。3.2 Token鉴权的落地方式用户登录后的身份识别是实现学习进度功能的前提。如果不做鉴权任何请求都能随便改别人的学习记录答辩时被问到安全性就很难看。我在这类系统里首选JWT方案因为不依赖额外的服务端Session存储闭包状态也能满足需求。生成token的核心逻辑是这样用户登录成功后把用户ID作为主体写进JWT同时设置一天或两天的过期时间用密钥签名后返回给客户端。Android端保存到SharedPreferences之后每次请求都在Header里带上Authorization: Bearer token。后端用一个拦截器统一解析这个Header解析成功就把用户信息放到请求上下文里解析失败直接返回401。密码存储也别用明文。Spring Security里附带了一个BCryptPasswordEncoder可以参考它的思路在项目里引入一个密码加密工具类。你可以直接用spring-security-crypto这个依赖里的实现不需要引入整个Spring Security这样既省配置又保持了安全。有一点提醒JWT的密钥千万不能硬编码在代码里直接暴露出来至少放到application.yml的配置项里。对于课程学习系统这种量级的项目做到密码加密加Token鉴权已经足够答辩了。如果老师追问怎么防止Token被伪造你可以从密钥管理和签名算法角度回答而不是一句我也不知道。3.3 图片视频的存储与访问配置精品课程系统的图片和视频属于典型的不适合直接存进MySQL的二进制大文件。我推荐先用本地磁盘路径存储把上传目录配置到application.yml代码里拿到上传的MultipartFile后写入这个目录文件名用UUID生成避免重名覆盖。关键点是访问路径。本地存储的文件默认不会通过Spring Boot暴露出去你需要加一个资源映射配置spring: servlet: multipart: max-file-size: 500MB max-request-size: 500MB myapp: upload-dir: D:/upload/course再写一个配置类加载WebMvcConfigurerConfiguration public class WebConfig implements WebMvcConfigurer { Value(${myapp.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/files/**) .addResourceLocations(file: uploadDir /); } }这样访问http://localhost:8080/files/course/xxxx.png就能拿到上传的文件。视频文件因为比较大上传时修改max-file-size部署到生产环境时再考虑对象存储这类方案毕设阶段本地磁盘加静态资源映射完全够用。4. Android端实现路线网络层、登录态与视频播放的取舍4.1 Android端架构怎么定不翻车Android端我看到过两类极端一类是只有一个Activity塞了几千行代码一类是照着企业级项目堆MVP、ViewModel、协程最后自己都讲不清楚。对毕设来说我建议在这两者之间取一个平衡按页面功能拆成若干个Activity公共逻辑抽到网络层和工具类界面用RecyclerView加Adapter实现列表不强行上MVVM。页面清单大概是这样登录注册页、主界面底部Tab切首页/分类/我的、课程列表页、课程详情页、播放页。底部Tab一般用Fragment实现也可以直接用四个Activity加底部导航栏看自己更擅长哪个。核心思路是让每个类的职责单一答辩时老师问这个页面是哪段代码处理的你能快速定位而不是打开一个类滚半天。4.2 网络层与登录态同步网络层是Android端最值得封装的部分。我推荐用Retrofit加OkHttp加Gson这套组合因为接口多的时候能省大量重复代码而且链式调用和注解风格比较容易读。定义一个ApiService接口把登录、课程列表、课程详情、进度上报都声明成方法再用Retrofit的Builder统一创建实例。登录态同步是最容易被忽略的点。App启动时先从SharedPreferences读token有token就跳到主界面没有就进登录页。发起业务请求时在OkHttp的拦截器里统一添加Header这样每个请求都不会漏token。服务端返回401时拦截器里可以直接清掉本地token并跳转回登录页。这里要特别提醒Android 9及以上默认禁止应用访问明文HTTP地址只有HTTPS才能直接用。本地开发你用的是http://10.0.2.2:8080必须在AndroidManifest.xml里给application标签加android:usesCleartextTraffictrue否则模拟器上所有请求都会报CLEARTEXT communication not permitted。这个问题极其常见但真到排查时很容易绕弯路。4.3 视频播放与学习进度记录视频播放可以采用系统自带的VideoView它自带简单的控制条支持常见的MP4格式代码量很少适合优先跑通整个流程。若想展示更强的能力可以换用MediaPlayer加SurfaceView再自己画一个进度条但这会带来不少代码量我建议作为进阶方案。进度记录是精品课程学习和普通播放器的核心区别。关键在实现从上次学习位置继续播放进入播放页时先请求后端拿到该视频的已学进度然后让播放器seekTo到对应位置播放过程中定期上报进度一般每5秒报一次就够了不需要每一秒都调接口。暂停和播放结束也要上报一次这样退出App之后数据是最新状态。上报接口的更新逻辑要配得上建表时的联合唯一约束。写成根据userId和videoId先查一遍查到了就更新进度字段查不到就插入即可。很多同学第一次做的时候只写了插入逻辑结果同一个视频产生几十条进度记录点击继续学习时根本不知道该用哪一条这种细节很容易被老师问到。5. 联调阶段没法绕开的三个坑时间格式、图片路径和真机网络5.1 时间格式化与前后端不一致前后端联调时最常见的报错是JSON解析失败根源往往在时间字段。Spring Boot的Jackson序列化LocalDateTime默认格式可能带个T类似2025-01-31T10:30:00。Android端拿到这个字符串后如果按空格分隔的格式去解析直接抛异常或者拿到null。处理办法是在后端的时间字段上加JsonFormat注解把格式固定成yyyy-MM-dd HH:mm:ss。也可以在application.yml里配全局Jackson格式。注意spring.jackson.date-format对java.util.Date有效但对LocalDateTime不一定生效最稳的方式还是字段注解。Android端解析时统一用SimpleDateFormat两边格式对齐问题就消失了。5.2 图片路径到底是塞相对路径还是完整URL后端返回数据时图片字段有两种存法一种是存完整路径http://192.168.1.100:8080/files/course/xxx.png另一种只存相对路径/files/course/xxx.png。我建议存相对路径由Android端在展示时拼上服务器的BaseUrl。原因很简单开发和演示时会频繁切换模拟器和真机服务器的IP端口可能会变把完整路径写死进数据库换台设备看课程封面就要重新改数据。相配套的Android端要有一个全局的BaseUrl配置。模拟器访问本机后端用http://10.0.2.2:8080真机访问同一个局域网下的电脑要用http://192.168.x.x:8080。每次切换环境只需要改一个常量而不是数据库。联调时先把后端的接口文档和BaseUrl确认好再决定App里怎样拼完整地址。5.3 模拟器与真机调试的差异再顺带说一个我反复遇到的现象代码在模拟器上一切正常打包到真机后视频播不了、图片加载不出来、登录报错。模拟器和真机的差别主要体现在三个方面。第一是网络环境模拟器里你固定用10.0.2.2访问宿主机真机要填局域网IP而且手机和电脑要在同一个WiFi下。第二是权限从Android 13开始部分存储权限在真机上会弹复杂选项模拟器可能直接通过。第三是视频硬解能力不同芯片对视频格式支持不同在模拟器上正常的视频真机可能黑屏。建议条件允许的话准备一台真机做主要验证设备模拟器只用来临时确认UI效果。6. 设计文档、演示和答辩把代码讲清楚比多写代码更重要6.1 设计说明书的结构怎么排很多同学代码写完了却在文档部分掉链子。毕设文档不是给老师看源码而是让老师快速理解你做了个什么系统、为什么这么设计、最后怎么验证的。我建议结构上按这样的主线展开绪论、需求分析、总体设计、详细设计、系统实现与测试、总结与展望。需求分析里要放用例图和用例描述至少覆盖登录、浏览课程、观看视频、记录进度、收藏这几个核心流程。总体设计里放系统架构图、功能模块图、数据库E-R图数据库E-R图画清楚再配合表结构说明。详细设计要有核心功能模块的流程图和关键类说明不需要贴每行代码但要把请求怎么走、数据怎么流讲明白。测试部分放测试用例表格每条用例对应一个功能点从输入、操作步骤到预期结果和实际结果都列清楚老师看完会觉得你的工程素养到位。这里有一个加分技巧文档里每个页面截图都要配一段简短的模块说明别只丢一堆图片然后什么都不写。你想想如果老师翻开文档看到的都是没注释的截图感受会差很多反过来图文并茂的文档哪怕功能简单一些整体观感完全不一样。6.2 演示Demo的脚本化流程到演示环节我建议先把操作步骤写一个脚本自己排练至少三遍。演示顺序很重要不要东点一下西点一下否则会显得对系统不熟。比较稳妥的流程是从注册或登录开始进入课程列表做一次分类筛选打开课程详情点开视频播放看到继续学习功能生效然后演示收藏和取消收藏最后切到管理端新增一门课程或修改课程信息再回到学生端刷新看到变化。整个过程控制在8分钟以内挑剔操作的老师可能会随时打断所以重要功能要先演示。比如退出播放再进入进度从上次位置继续这个功能一定是亮点要在演示初期就让它出现。若你先在那里翻列表翻了一分钟老师注意力早就开始涣散。6.3 答辩高频问题与扩展定制思路答辩问题基本绕不开这几类。第一类问数据库为什么这样设计你就从实体关系和业务约束角度回答讲清楚学习记录的联合唯一约束、逻辑删除保护数据的原因。第二类问安全怎么做回答密码加密、Token鉴权、参数校验三步。第三类问并发访问怎么办不要慌承认当前是单体架构再说明可以从加缓存、进度上报防抖、数据库索引优化这些方向改进思路比答案本身更重要。另外很多老师会现场提定制需求比如能不能加个评论功能能不能让老师也上传课程。这时候你不需要真的当场改代码但必须能够说出改动点。加评论功能就是新增评论表关联用户和课程后端补两个接口Android端课程详情页下方加评论列表和输入框。老师上传课程则要谈角色权限的扩展把教师角色加进来上传入口权限控制好。答辩前花一点时间把这些扩展点写在纸上远比临时硬编有底气。我的实际经验是这类扩展思路不仅是为了应付老师。很多同学做完一个毕设后简历上就写着开发过课程学习系统但被问到项目细节时答不上来。真正把每个模块的设计理由和扩展方式理清楚这些内容才会变成你面试时能讲的真实项目经验。在砖头一样的代码库里能够说出来为什么要加联合唯一约束、为什么要逻辑删除的人已经能甩开绝大多数只求跑通的同行了。最后再分享一个我每次都会用的自查手段正式提交前把手机上的App数据全部清除用一个新的账号从注册开始走一遍完整流程。这个动作几乎能暴露你之前没注意的缓存、登录态、进度恢复等所有问题。我帮别人复核毕设时一定会做这一步效果比反复检查代码好得多。课程学习系统这种前后端分离、数据闭环的项目最怕的就是只在自己熟悉的账号和本地环境下能跑换个环境就露馅。这套方法用下来你的项目才算真正落地了。
