企业官网建设流程全解析

每年到了这个时间点，微信里问得最多的一类问题就是"学长，毕设题目是'基于Spring Boot的计算机精品课程学习系统'，到底该先做哪一头？"说实话，这个题目在计算机毕设里的出场率非常高，因为它的技术栈几乎覆盖了大四学生应该展示的全部能力：后端用Spring Boot做接口，前端可以是安卓APP也可以是微信小程序，还有人两个端都做，再加上MySQL数据库设计、视频播放、用户鉴权、进度管理这些功能点，一套下来，从数据库到移动端到部署上线，链路非常完整。

这篇内容我想以这个题目为例子，从一个带毕设的老学长的角度，把这个项目从头到尾拆一遍。你拿到的"完整源码+LW+部署说明+演示视频"只是结果，真正值钱的是你知不知道每一步为什么这么做、踩过哪些坑。我会把选题背后的考核点、技术选型逻辑、核心功能实现思路、部署排查方法、交付物整理整个串起来讲，不管你是刚拿到这个题目还没头绪，还是已经写了一半在硬着头皮调Bug，这篇都能帮上忙。

1. 选题拆解：这门毕设到底在考什么

1.1 一个题目背后藏着的完整技能栈

先别急着写代码。拿到题目第一件事，是把这里面的每个关键词拆开看它对应学校想考察的能力。

"基于Spring Boot"这句话，对应的是Java Web后端开发的整套东西：Spring IoC/DI、Spring MVC请求处理、MyBatis或MyBatis-Plus操作数据库、Maven依赖管理、application.yml配置、JWT或Session鉴权、接口的RESTful设计。这一块是老师重点看的地方，因为它是整个系统的地基。

"Android APP"对应的是原生移动端开发能力：Activity/Fragment生命周期、ListView/RecyclerView列表、Adapter绑定数据、Retrofit/OkHttp网络请求、Glide加载图片、SharedPreferences或SQLite做本地缓存、AndroidManifest权限配置。这部分如果你做过课设，基本就是把这些常规组件组合起来。

"微信小程序"对应的是小程序原生开发能力：WXML/WXSS页面结构、生命周期函数、wx.request网络请求、本地storage存储、自定义导航栏适配、上线发布流程。现在很多学校允许Android和小程序二选一，也有老师要求两个端都出，原因是一个能体现原生功底，一个能体现工程化意识，能在同一个项目里同时看到两种端的实现思路，对答辩来说是很加分的。

至于"精品课程学习系统"，它是一个非常典型的"信息管理+在线学习"混合型业务。和纯成绩管理这类系统比起来，它多了一个"视频播放""学习进度记录"的动态维度，但这个复杂度又刚好控制在毕设能按时完成的范围里。选这个题目的学生通常不会在业务理解上栽跟头，因为它就是我们每天在用的网课App的简化版。

1.2 "精品课程学习系统"的业务闭环

学习系统听起来抽象，说白了就是三个角色在一个闭环里转：

• 学生端：注册登录→浏览课程列表和分类→进入课程详情→观看章节视频→系统记录学习进度→收藏课程、发表评论→在个人中心查看学习记录。
• 管理端：管理员登录后台→管理课程分类→发布/编辑/下架课程→上传章节视频→管理学生账号→查看基础数据统计。

这个闭环最妙的地方在于，它把"数据流向"理清楚了以后，数据库的表结构、后端的接口清单、前端每个页面该做什么，全都跟着出来了。我一般让学生拿到需求后先别写代码，就画这个闭环，画完基本就知道要哪些表、要哪些接口了。

1.3 为什么这套选型经久不衰

你可能好奇，为什么每年毕设题目里都有这种"精品课程学习系统""在线教育平台""智慧课堂"？因为这类题目的性价比实在太高了。难度上，它比纯电商系统简单，比图书管理系统有含量；复杂度上，它有完整的用户体系、内容管理、学习行为记录，足够写成一篇像样的毕业论文；可扩展性上，答辩被问到"还能加什么功能"时，你可以说在线考试、支付、消息推送、学习数据分析，这些都是成熟的方向，老师一听就知道你有思考。

而且这个项目还有一个隐藏优势：资料非常多。遇到报错的时候，你几乎能在任何技术社区找到对应的解决方案，这对毕设党来说比什么都重要。做毕设最怕的不是难，是卡住没人救，选一个生态成熟的组合，本身就是一种风险管理。

2. 技术选型与架构设计：先把地基打好

2.1 Spring Boot 版本到底怎么选

这是我在看项目时第一个会问的问题。现在网上的教程和毕设源码大多数还在用Spring Boot 2.x配JDK 8，而新一点的教程已经换到Spring Boot 3.x配JDK 17了。两个版本不是简单升个号的问题，javax.包换成jakarta.、Springfox换SpringDoc、MyBatis-Plus要3.5.3以上，这些都会让你在本该几行配置就能跑起来的地方折腾半天。

我的建议分两类：如果你拿到的源码本身就是2.x，那就老老实实用2.7.18这个2.x的最终维护版本，配套JDK 8，别手贱升级；如果你是新建工程或者学校明确要求新技术，那就直接3.2.x配JDK 17，一开始就把版本组合锁定，别混着用。最常见的翻车现场就是，学生拿了一个2.x的源码，自己电脑装的是JDK 17，一启动报错一堆，然后开始怀疑代码有问题，其实只是版本错配。下面是我推荐的稳定组合：

选好版本组合之后，第一个动作就是把依赖锁定，用Maven管理好，保证换一台机器也能mvn clean package直接过。很多毕设源码之所以"只有作者能跑"，就是因为依赖版本写在注释里没锁进pom.xml。

2.2 数据库模型设计的几个关键表

表设计是答辩时老师最可能细看的东西之一，因为它直接反映你懂不懂业务。以这套系统为例，核心表我建议控制在8张以内：

• user：用户表，字段包括id、username、password（BCrypt加密存储）、nickname、avatar、role（student/admin）、create_time。
• category：课程分类表，id、name、sort_order。
• course：课程表，id、category_id、title、cover、intro、teacher、status（上架/下架）、total_duration、view_count。
• chapter：章节课表，id、course_id、title、sort_order。
• video：视频表，id、chapter_id、course_id、title、url、duration、size。也可以把视频字段并进chapter表，看你的粒度。
• learning_progress：学习进度表，id、user_id、course_id、video_id、last_position、duration_watched、update_time。
• favorite：收藏表，id、user_id、course_id、create_time。
• comment：评论表，id、user_id、course_id、content、create_time。

为什么要有course表里的total_duration？因为课程列表页要显示"共X小时"，如果每次实时算会很麻烦，干脆在发布课程时汇总好。像这种"冗余字段为了查询效率"的设计，写进论文里就是加分点。

外键这块我建议用逻辑外键而不是物理外键，也就是说表之间不真正建FOREIGN KEY，只保留关联字段，用MyBatis-Plus查询时手动关联。原因很简单：逻辑外键在后期分页、联表、删数据时灵活得多，而且毕设数据量不大，根本不需要数据库层做完整性约束。

2.3 Android 端与小程序端的技术分工

当你要同时交付Android和小程序两个前端时，很多人会先慌，觉得工作量翻倍。其实不会，因为这两端页面结构是高度重合的，你的首页、课程列表、详情页、个人中心，在两端几乎是同一套交互逻辑。真正要分清的，是它们各自用什么姿势去实现。

Android端我推荐走最简单的MVP或者干脆Activity+Adapter的写法，网络层统一用Retrofit + OkHttp，图片加载用Glide，视频播放用JiaoZiVideoPlayer或者官方ExoPlayer。这里我要特别说一句：毕设不要为了炫技上复杂的架构，你能用RecyclerView+Adapter讲清楚列表的复用机制，比什么都有说服力。真放到工作里那是另说，但毕设的核心目标是稳定跑起来且你能讲明白。

小程序端相对更轻，页面用WXML/WXSS写，数据绑定方式本身就帮你省掉了Adapter这套东西，列表渲染直接用wx:for。网络请求统一封装一个request方法，把baseURL、token注入、错误提示都放在一起。如果你的小程序还涉及"登录获取手机号"，要明确这个是需要企业主体的小程序认证才能调的，个人主体只能用wx.login配合后端换取openid，或者用手机号快速验证组件绕开。

2.4 双端共用一个后端：接口约定与统一返回体

两个前端换着调同一个后端接口，最容易出现的灾难就是各调各的，字段命名不一样，返回结构不统一。所以第一步必须把所有接口的返回格式统一成下面这个样子：

public class Result<T> { private Integer code; // 200成功，500失败，401未登录 private String message; private T data; public static <T> Result<T> ok(T data) { ... } public static <T> Result<T> error(String message) { ... } }

这个类值得单独写出来，因为Android端和小程序端的网络层都要依赖它解析数据。有了这个统一结构，前端判断逻辑就只有一种：code等于200就渲染data，否则弹message。列表接口统一用pageNum和pageSize两个参数，返回体里放总条数和列表数据；时间字段统一用String的"yyyy-MM-dd HH:mm:ss"而不是时间戳，减少前端格式化的工作量。

接口路径也建议在Spring Boot里加一个统一前缀，比如/api/student/和/api/admin/，这样在拦截器里按前缀区分权限非常方便，管理员接口只允许role=admin的token通过。

3. 核心功能实现：用户、课程、进度三大主线

3.1 登录鉴权：JWT 方案从后端到客户端的完整链路

学习系统的每一条数据都跟用户有关，所以登录鉴权是第一关。很多毕设源码用的是Session + 拦截器，这在单体项目里其实能用，但移动端每次请求都要带Cookie，小程序用Session也不方便，所以我更推荐JWT方案。它最直观的好处是"无状态"：用户登录成功后，后端把用户ID和角色信息签进一个token里返回，客户端存起来，之后每个请求在header里带上，后端拦截器一验签就知道是谁。

后端实现逻辑其实就那么几步：

1. 登录接口接收username和password，校验通过后用jjwt生成token，payload里放userId和role，设置过期时间（一般7天）。
2. 写一个拦截器，对所有需要登录的接口先取header里的Authorization，去掉"Bearer "前缀再验签，验签通过就把userId塞进Request上下文的Attribute里，供Controller直接取。
3. 在WebMvcConfigurer里注册这个拦截器，配置排除登录、注册、课程列表这类公开接口。

我见过太多学生卡在第三步：拦截器把登录接口也给拦截了，导致死循环登录不上。这个坑的排查方法很简单，在拦截器preHandle里先判断当前路径是不是登录接口，是就直接放行。

Android端拿到token以后，我习惯存在SharedPreferences里，Retrofit的OkHttpClient上加一个Interceptor，每次请求自动往header里塞token。小程序端同理，token存到wx.setStorageSync，在封装好的request方法里统一注入。两端的代码完全可以对着写，这也就是双端项目有意思的地方。

这里还得提醒一个安全问题：密码存储必须用BCrypt加密，哪怕你是毕设也不要明文存密码，答辩老师问起来这是必死项。Spring Security里自带的BCryptPasswordEncoder类可以直接拿来用，不需要引入整套Security。

3.2 课程与视频内容管理

课程管理本质上就是一套标准的数据CRUD，管理员增删改查course表、category表、chapter表。真正有技术点的是视频文件怎么处理。毕设最合适也最稳的方案是：视频文件传到服务器某个固定目录下，比如/opt/edu/video/，然后用Nginx把这个目录映射成一个可访问的静态URL，数据库里只存相对路径。这样处理有两个好处：一是接口返回的是一个可以直接交给播放器的URL，二是视频文件不经过Spring Boot的JVM内存，不占用后端进程的资源。上传接口用一个MultipartFile接收文件，校验后缀名和大小，然后存储并返回URL，代码量很小。

这里有个常见的误解：有人觉得视频文件应该存MySQL的BLOB字段。千万别这么干，数据库存大文件，查询和备份都会拖垮系统，而且没有任何实际项目会这么设计。视频就是应该放在磁盘或对象存储里，数据库只存"它在哪"。

播放端Android用VideoView或者JiaoZiVideoPlayer，小程序用自带的video标签，给一个src就能播。你需要额外处理的只是播放进度的回调：视频组件都有onProgress/onPause/onCompletion这类监听，把当前播放秒数定时上报给后端就行。

3.3 学习进度记录：增量更新还是全量覆盖

学习进度是这个系统的灵魂功能，也是论文里最值得写的一段。业务上我们要支持：用户看到"上次学到第3章第2小节，还差5分钟看完"，以及课程卡片上显示"已学65%"。所以数据结构设计成(user_id, video_id)为唯一键，这样每个用户对每节视频只有一条进度记录。字段记录last_position秒数和已观看时长。

更新策略我推荐"前端定时上报+页面关闭时最终上报"的组合：播放过程中每10秒调一次接口，把当前播放位置传上去；退出页面时再传一次最终的观看秒数。后端收到后用"增量合并"而不是"全量覆盖"，也就是已观看时长取两者较大值，避免网络抖动把进度写小。计算一个课程的总体进度，就是把这个课程所有视频的已观看时长之和除以所有视频总时长，得到一个百分比。

这部分代码不难，但我要强调一个设计细节：接口要做幂等。用户播放同一个视频，5秒上报一次，后端不应该每次都产生一条新日志。用ON DUPLICATE KEY UPDATE或者先查再更新都可以，核心是最后只体现"最新位置"这一个状态。

3.4 管理端：课程上架与学生管理的常规套路

管理端我建议做在网页上而不是手机App里，因为后台管理的交互天然是"表格+表单"，网页实现又简单又好看。你可以用Spring Boot自带的后端渲染，也可以用Vue这类前端框架做前后端分离。如果拿到的交付源码里已经带了管理端，优先看它的权限控制是怎么做的——管理端接口必须在后端校验role，而不是只靠前端隐藏入口。这是答辩老师惯用的一刀。

数据统计可以做一个简单的看板：课程总数、学生总数、总播放量、热门课程Top5。SQL里就是COUNT和GROUP BY，但展示效果非常好，演示的时候往大屏上一投，观感直接拉满。

4. 部署实录：从 IDEA 到云服务器的完整流程

4.1 本地开发环境的搭建顺序

本地环境搭建我建议按"后端先跑通、再调前端"的顺序来，不然两边一起报错你会疯掉。具体步骤：

1. 装JDK和Maven，确认java -version和mvn -version对得上。
2. 装MySQL，建库，执行项目里的sql脚本初始化数据。
3. 配置application.yml里的数据库连接，重点检查三项：数据库IP端口、用户名密码、URL里的serverTimezone和useSSL参数。MySQL 8经常因为时区问题报错，URL写成jdbc:mysql://localhost:3306/edu?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false基本能避开。
4. 启动Spring Boot，看到"Tomcat started"之类的日志后再用Postman打一个接口验证。
5. 后端稳了再开Android Studio和小程序开发者工具分别联调。

很多人问为什么后端启动报"端口被占用"，其实9成是上次的进程没杀掉，Windows下面用netstat -ano | findstr 8080查到PID再杀掉就行，不是代码问题。

4.2 后端打包与服务器部署

交付时老师要看"能部署的线上系统"，所以你需要把后端以jar包形式部署到一台Linux服务器上。打包命令就一行：

mvn clean package -DskipTests

打出来的jar包在target目录下。上传到服务器后，最朴素的启动方式：

nohup java -jar edu-server.jar --spring.profiles.active=prod &

日志输出到nohup.out，方便排查。如果你希望系统挂了自动重启，可以用systemd写一个service文件，或者用宝塔面板的Supervisor。热词里有人搜"宝塔docker部署springboot"，如果你想用Docker也没问题，写一个基础Dockerfile把jar包打进去，但毕设场景里真的没必要为了Docker而Docker，能讲清楚nohup和systemd已经足够了。

服务器上的三个端口检查要提前做：后端端口要在防火墙和安全组里放行；Nginx的80或443要放行；MySQL不要暴露到公网，只让本机的后端连。这是我在检查部署时必看的三处，也是最容易因为粗心导致"本地好好的，线上死活不通"的地方。

4.3 Android 真机调试的几个必踩点

Android调试这儿我几乎每次都要帮人排查三类问题。第一类是模拟器和真机的地址不一样：Android Studio的模拟器里访问电脑本机用10.0.2.2，真机要把后端地址改成你电脑在局域网里的IP，比如192.168.x.x。这个写死在代码里要注意，发布前记得改成线上域名。

第二类是Android 9以上默认禁止明文HTTP流量。你本地调试用http://192.168.1.100:8080访问后端，如果不配置直接报Cleartext HTTP traffic not permitted。解法是在AndroidManifest.xml的application标签上加android:usesCleartextTraffic="true"，或者写一个networkSecurityConfig只对开发地址放行明文。这个小配置几乎人人会踩，提前写上能省一个晚上的时间。

第三类是图片和视频加载不出来先别怀疑代码。用Glide加载课程封面图、用VideoView播视频，不显示的时候先看URL在浏览器里打不打得开，如果打不开说明资源没放对目录或者Nginx映射没生效，这跟客户端代码一点关系都没有。

4.4 小程序联调与上线注意

小程序开发者工具里调试后端接口，第一件事是在"详情-本地设置"里勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"。这个选项只是开发期的豁免，一旦要发布上线，所有请求域名必须是备案过的HTTPS域名，而且要在小程序管理后台把域名加进request合法域名列表。很多学生做完开发以为万事大吉，一提交审核就报"域名不合法"，提前配好能省一整天。

小程序里还有一个很多新手会忽略的适配问题：顶部导航栏高度。安卓和iOS状态栏高度不一样，iPhone的刘海屏和别的机型也不一样。如果你自定义导航栏，不要写死高度，要用wx.getSystemInfoSync()拿statusBarHeight，用wx.getMenuButtonBoundingClientRect()拿胶囊按钮位置，动态计算导航栏高度。这个适配写得对，真机预览和模拟器的显示才会一致。

关于"登录获取手机号"这个功能，我必须提前泼个冷水：个人主体的小程序是不能调用手机号快速验证组件的，必须是企业主体且在小程序后台开通。如果是毕设，最稳的做法是账号密码登录，或者用wx.login拿到code换取openid实现微信静默登录，别把需求写死在手机号上，否则审核环节会卡住。

5. 常见问题与排查技巧实录

5.1 版本兼容类问题速查

这一类问题占了调试时间的一大半，我把高频的整理成一张表，遇到直接对照：

这类问题最大的特点就是"报错信息看不懂"，但只要是版本兼容类的问题，先把依赖版本组合捋一遍，比硬读报错效率高得多。

5.2 Android 高版本适配问题

如果你下载的源码是前两年的，拿现在的Android Studio一跑，经常会遇到targetSdk太高或太低导致的编译问题。新版本SDK对权限收紧得厉害，再强调一遍几个高频点：访问外部存储要申请READ_MEDIA_VIDEO或READ_EXTERNAL_STORAGE权限；targetSdk 33及以上用通知栏要先请求POST_NOTIFICATIONS；文件下载如果写到了应用外部目录，需要处理运行时权限拒绝的回调。

有的源码喜欢把视频下载到/storage/emulated/0/Android/data/包名/files/这类目录，这类目录在Android 11以后即使有权限也可能被系统隔离，换个思路把视频文件存到getExternalFilesDir()这个属于应用自己的目录里，反而简单不易出错。记住一个原则：毕设演示视频文件，优先存应用专属目录，别跟公共目录死磕。

5.3 网络请求与接口联调问题

前后端联调是最容易"扯皮"的环节。我给自己定的流程是：先在Postman里把所有接口调通，确认返回结构和预期一致，再让前端按这个结构写解析代码。如果小程序或App里报解析失败，先看返回的JSON长什么样，90%是字段对不上或者数据是null。

还有一个高频问题：报CORS跨域错误。前后端分离部署时后端的接口和前端页面不在同一个域名下，浏览器会拦截。后端的解法是写一个CorsFilter或者在WebMvcConfigurer里配置addCorsMappings，允许的origin按需配置，别图省事设置成"*"还带上Authorization头，那是配了也白配——携带凭证的跨域请求不允许通配符。

5.4 小程序审核与兼容问题

小程序提审这个环节，内容合规是第一关，尤其做教育类目，类目要选"教育-在线教育"，如果有视频内容，还要在隐私协议里写明收集哪些用户信息。再提醒一次：不要在非企业主体的小程序里依赖手机号授权，这个是硬性门槛，不是写代码能绕过去的。

兼容性方面，video组件在部分安卓机型上偶尔会出现"同层渲染"导致的黑屏，实际开发中可以降级用cover-view配合，或者强制开启同层渲染开关。这类问题你没有真机很难复现，所以建议在微信开发者工具的设备模拟里多切几个机型看，再用自己的手机真机预览一次。

6. 交付那些事：源码、文档、部署说明怎么整理

6.1 完整交付物清单

"完整源码+LW+部署说明+演示视频"不是四个压缩包丢给你就完了，你自己将来答辩、或者以后接这类单子给别人交付，都要按下面的清单自查：

我特别想强调部署说明的重要性。一份好的部署说明应该能让一个从没碰过这个项目的人，拿到源码后30分钟内跑起来。默认账号、数据库配置改成什么、端口冲突怎么处理，都要写清楚。好多毕设翻车就是翻在"作者自己忘了默认密码是什么"这种低级问题上。

6.2 时间规划与答辩准备

如果你的时间还剩6到8周，我建议这样切：第1周画需求图、设计数据库、确定接口清单；第2-3周把后端的登录、课程CRUD、视频上传、进度接口做出来，用Postman全部调通；第4-5周做Android端，把核心页面和学习流程跑通；第6周做小程序端，因为接口都是现成的，工作量主要在页面；第7周整体联调、处理兼容性、写部署说明；第8周写论文和做演示视频。这个节奏是针对双端都做的，如果只做一个前端，能再省出两周用来打磨论文。

答辩准备有两个要点。第一是场景先行：准备一个5分钟的演示脚本，按"学生登录-选课-看视频-记录进度-收藏评论-管理员上架课程"的顺序走，每一屏画面配合一句要讲的重点。第二是准备好回答"为什么"：为什么用JWT不用Session、为什么视频放Nginx不放数据库、为什么表之间不用物理外键，把这三个为什么想透了，答辩基本稳。

我个人这几年帮人看这个题目的最大感受是，毕设考验的从来不是谁代码写得花哨，而是谁能把一套完整的东西讲清楚、跑起来。技术选型、架构设计、核心逻辑这些你如果能用自己的话解释明白，哪怕功能简单一些，老师也会给你不错的评价。反过来，功能堆再多，一问你"这个进度百分比怎么算的"就支支吾吾，那才是最扣分的地方。

最后再贡献一个实际经验：交付前一定做一次"从零搭建"的完整测试，另找一台干净的电脑，按你的部署说明从头到尾跑一遍。这一遍你会发现无数你以为"不用写"的细节——MySQL少了个字符集配置、Nginx的路径少了个斜杠、Android里忘了开明文流量，全都是这一遍抓出来的。这个习惯我保持了四五年，带过的每一个项目交付前都会做，从来没有在客户或老师眼皮底下出过岔子。