Spring Boot课程资源在线销售系统：从业务建模到Docker部署实战

做课程资源售卖这类毕业设计时，很多同学一开始都把它当成“仿淘宝”来写，结果做着做着就变成了纯增删改查。这个Spring Boot课程资源在线销售系统看似是一个电商项目，但你往深了想，它其实是“电商+内容分发”的混合体：用户购买的是一件虚拟数据资产，交付不是物流发货，而是账号权限。这个区别决定了技术选型、数据库设计乃至答辩讲解的侧重点都不一样。

这篇文章就围绕这个项目的完整落地过程展开，从业务建模、技术栈搭配、核心模块实现到Docker部署，把每个环节的设计理由和实操细节拆给你看。适合正在准备Java方向毕业设计的同学直接参考，也适合学完Spring Boot基础想做综合实战的新手，拿它当训练项目会学到很多单体业务系统的真实经验。里面用到的东西都是我实际验证过的，不是那种复制下来跑不起来的代码。

1. 项目设计思路与技术选型

1.1 先摸清业务：课程销售和卖实物商品有什么本质区别

在设计系统之前，先把业务搞明白。实物电商卖的是“物”，用户付款后走物流配送，系统重点关注库存、物流、退货这些链路。课程资源平台卖的是虚拟内容，付款后没有任何实物要发，核心问题变成了另外三件事：

第一，数据资产的访问控制。一个用户买了一份课程，他不能把下载链接随便转发给别人，系统里要有“用户-课程”的权益绑定关系，并且资源下载接口要校验这个关系。

第二，虚拟权益自动发放。用户支付成功的瞬间，平台要自动给这个账号开通资源访问权限，不需要人工介入。这就意味着“支付成功”和“权益开通”必须是可靠联动，不能出现钱扣了但课程看不了的情况。

第三，大文件的高效存取。一套课程视频动辄几个G，不可能存数据库里。要把课程文件独立出来，走对象存储服务，同时处理好上传下载的性能问题。

把这些需求想清楚，再看市面上那些课程销售系统的毕设代码，你就知道为什么很多只做普通CRUD的版本经不起问：订单表只有一张表没有明细，课程文件用本地磁盘路径存，支付成功只是把状态改成已支付，权限发放完全没有。这些看似“能跑”的地方，恰恰是答辩时最容易露怯的点。

基于这个业务判断，这个项目的核心模块应该拆成前台用户端、后台管理端、基础支撑服务三块。前台用户端包含注册登录、课程浏览与检索、课程详情、购物车、下单、模拟支付、已购课程与资源下载；后台管理端包含管理员登录、课程与分类管理、订单管理、退款审核、数据统计；基础支撑服务包含JWT认证、文件对象存储、Redis缓存、统一异常处理。

1.2 技术组合的选择：Spring Boot + MyBatis + Vue为什么最稳妥

技术选型这块，网上各说各话。有的建议上Spring Cloud微服务，有的建议用ElasticSearch做搜索。对于一个毕业设计项目，我更倾向于“主流、够用、自己能讲明白”的组合：后端Spring Boot，持久层MyBatis（时间紧就MyBatis Plus），前端Vue加Element Plus。完整搭配是Spring Boot 2.7.x + MyBatis Plus 3.5.x + MySQL 8.0 + Redis + MinIO + Vue 3，全程用Maven管理依赖。

你可能会问，同为Java后端框架，为什么不用Spring MVC或Spring Cloud。Spring MVC确实是Spring Boot的基础，但配置繁琐，适合学习不适合快速交付；Spring Cloud是为了应对分布式场景下的服务治理，单机即可演示的毕设项目引入微服务很容易让复杂度失控，万一到时候Eureka、Nacos、Feign之间版本出兼容问题，光是修依赖就要耗掉大量时间。

Spring Boot的优势在于自动装配机制：你把starter依赖引入后，框架自动配置好内嵌Tomcat、数据源、核心组件，只需要少量自定义配置就能快速启动项目。在毕业设计这个时间节点上，这种“开箱即用”的体验非常宝贵，可以把精力放在业务代码上而不是配置环境上。

前端选择Vue也比较稳妥。Vue的生态成熟，Element Plus组件库覆盖了表格、表单、弹窗、分页等几乎所有管理后台需要的场景，即便前端基础薄弱，靠复制示例代码也能快速拼出一套界面。前后端通过RESTful接口联调，接口风格和后端职责都很清晰。

至于MySQL、Redis、MinIO这三个基础组件，是一个完整课程平台最常用的配套：MySQL负责持久化核心业务数据，Redis负责缓存高频率读数据（比如课程分类、课程列表、在线用户会话），MinIO负责存放课程视频和文档文件。把这三个组件讲清楚，整个架构图一画，项目的完整度和工程化水平立刻就不一样了。

1.3 开发环境参数：版本、JDK和Maven配置一次到位

环境配置的细节直接影响开发体验，这里给一套我实测比较顺的版本组合：

• JDK：1.8或17二选一。如果选Spring Boot 2.7.x，用JDK 8完全够；如果选Spring Boot 3.2.x，就要用JDK 17，而且注意代码里javax.要改成jakarta.。
• IDE：IntelliJ IDEA。创建项目时直接用IDEA自带的Spring Initializr，勾选Web、MyBatis、MySQL驱动、Redis这几个依赖，省去手写pom的麻烦。
• Maven：配置阿里云镜像源，依赖下载速度会快好几倍。在settings.xml中加入mirror配置指向https://maven.aliyun.com/repository/public。
• 数据库：MySQL 8.0，字符集用utf8mb4，因为它能正常存储表情符号和一些特殊字符。
• 缓存：Redis 7.x本地安装或用Docker启动，默认端口6379。

一个容易忽略的细节是Spring Boot版本与MyBatis-plus版本的匹配关系。以MyBatis Plus 3.5.x为例，它的3.5.3版本以后经过测试，与Spring Boot 2.x和3.x都能兼容，但如果用老版本配合Spring Boot 3.x，启动时会报“Failed to process import candidates”之类的包扫描错误。建议在pom.xml中显式声明MyBatis Plus版本，不要用默认依赖传递。

注意：Spring Boot 3.x把javax命名空间替换成jakarta后，很多第三方库都需要对应升级版本。如果你的某个工具包没有提供jakarta版本，建议绕道Spring Boot 2.7.x，出现兼容问题的概率会小很多。

2. 数据库设计与业务建模

2.1 从业务链路出发设计数据表结构

课程资源销售系统的表设计要围绕三条业务线：用户生命周期、课程内容组织、订单支付状态。基于这个思路，我给出一个完整可用的表结构清单：

• user（用户表）：保存账号信息、昵称、头像、密码哈希值、角色标识。角色建议用字符串字段存ROLE_USER或ROLE_ADMIN。
• course_category（课程分类表）：分类ID、分类名称、父分类ID、排序号。支持二级分类，方便前台筛选。
• course（课程表）：课程分类ID、课程标题、讲师名称、课程简介、原价、售价、封面图URL、是否上架、销量统计、创建时间。
• course_resource（课程资源表）：课程ID、资源名称、资源类型（视频/文档/压缩包）、存储地址、文件大小、上传时间。一门课程对应多条资源记录。
• cart_item（购物车表）：用户ID、课程ID、价格快照、加入时间。
• orders（订单表）：订单编号、用户ID、订单总金额、优惠金额、实付金额、订单状态、支付状态、创建时间、支付时间。
• order_item（订单明细表）：订单ID、课程ID、课程标题、购买单价、数量。
• payment_info（支付记录表）：订单编号、支付方式、支付金额、支付状态、三方流水号、回调时间。
• user_course（已购课程表）：用户ID、课程ID、购买时间、过期时间。这张表是权益表，也是下载接口的核心鉴权依据。

有些设计会把购物车里的价格快照去掉，这个字段不能省。购物车本质上是一个临时清单，用户在购物车页面看到的金额要相对稳定，不能因为课程临时改价就跳动。更合理的是在商品加入购物车时缓存价格快照，真正下单结算时后端再拿订单价格校验一次，发现不一致就提示用户刷新价格。

2.2 订单状态如何设计才不会有对外暴露的风险

订单状态是虚拟商品系统的“中枢神经”，状态流转直接关系到支付回调、权限发放、退款联动。这里不建议用int字段存0、1、2，因为代码里写死数字的可读性极差，排查问题还要来回翻代码。用枚举常量配合字符串字段存储更合适。

订单建议设计为这些状态：待支付、已支付、已关闭、已退款。流程上，用户创建订单后是待支付；待支付状态下用户可以取消，变成已关闭；调用模拟支付成功后变为已支付；已支付后可被管理员退款，变为已退款。这里的“已支付”状态是整个系统的枢纽：一旦进入已支付，就要立刻触发用户权益开通动作。

订单编号生成也要稍微讲究一点。不要用自增主键直接当作订单号暴露给用户，这样既暴露平台规模，也容易被通过遍历订单号获取他人订单信息。推荐生成方案是用时间戳加随机数，例如用LocalDateTime的yyyyMMddHHmmss格式拼上4位随机数，再补上用户ID后两位，保证全局唯一且不容易被猜测。

数据库设计还有一个隐藏关卡：金额字段类型。价格和订单金额建议使用DECIMAL(10,2)，实体类中对应BigDecimal。很多初学项目会用double存价格，两个浮点数相加会出现0.1加0.2等于0.30000000000000004这种精度问题，虽然单机演示不致命，但涉及退款、统计时会产生莫名的小数误差。BigDecimal构造时要避免直接new BigDecimal(double)，否则精度问题依然存在，应该使用BigDecimal.valueOf(double)或new BigDecimal("9.9")这类字符串构造方式。

2.3 表关联关系里容易被忽视的细节

表关系设计有几个细节特别容易被忽视。第一，course和course_resource是一对多关系，课程表不直接存放文件路径，否则视频加个分P就无从存储。第二，orders和order_item是一对多关系，这也意味着订单主表中不要直接放课程ID，否则将来做“课程打包售卖”或“一套课程包含多个资源包”时就得改表。第三，user_course表里的课程ID和用户ID要建联合唯一索引，防止重复购买后权益记录被插入两条。

从页面检索的角度看，课程表还要有全文检索的意识。毕设不要求对接ElasticSearch，但索引必须建好：分类ID、是否上架、销量这些字段都是高频查询条件，加普通索引就能让列表查询响应速度明显提升。MySQL的索引设计在论文里也是一个可以展开写的亮点。

3. 核心模块实现细节

3.1 JWT认证鉴权：从登录到接口放行的完整链路

课程资源系统有两种角色，普通用户和管理员，接口要做隔离。认证选型上我推荐JWT而不是Session方案。JWT是无状态令牌，后端不用维护会话，很适合当前后端分离的架构。用户在Vue前端登录成功后，后端返回一个签名的JWT串，前端把它存到localStorage，在Axios请求拦截器里统一往请求头加“Authorization: Bearer token”。后端写一个OncePerRequestFilter或HandlerInterceptor，对每个请求做令牌解析校验。

JWT的核心逻辑并不复杂：载荷部分放入用户ID和角色，签名密钥放在application.yml中，过期时间设置为24小时。处理拦截器时要特别小心放行路径。登录接口、注册接口、课程列表和详情这类需要匿名访问的接口必须排除在拦截路径之外，否则用户连登录页都打不开。管理员接口建议单独加一层管理员角色判断，比如路径以/admin开头的请求必须校验“role=ADMIN”，否则拒绝访问。

如果时间允许，建议你在登录功能里加上“密码加密存储”这个亮点。不要用MD5，MD5加盐也容易碰撞，最少也要用BCryptPasswordEncoder，这是Spring Security默认支持的加密方式，在pom引入security-crypto依赖，单独使用不会牵动整个Security配置。

3.2 课程文件上传：Spring Boot集成MinIO的完整步骤

课程资源系统最核心的资产就是课程文件。用本地磁盘路径存文件的方式不能说不能跑，但一旦更换部署机器，或者文件越积越多，就会有各种路径问题。这里建议用MinIO做对象存储，它是开源软件，兼容Amazon S3接口协议，部署方便，社区中文文档较多，非常适合作为毕业设计的文件存储组件。

安装MinIO最常用的是Docker方式。启动命令大致是：映射9000端口给API、9001给控制台，指定数据存储目录和初始用户名密码。启动成功后访问控制台，可以手动创建一个名为course-resource的桶。

集成Spring Boot的过程分成三步。第一步，pom中添加MinIO的Java SDK依赖。第二步，application.yml中配置MinIO的endpoint、access-key、secret-key和bucket名称。第三步，创建一个MinioConfig配置类，把MinioClient构建成Spring容器中的Bean。然后在Service层写一个FileService，提供上传、下载、生成访问链接方法。

上传方法核心逻辑就是生成对象名、调用minioClient.putObject。注意文件名策略不要用用户上传的原始文件名，因为中文名和特殊字符会带来URL编码问题，建议用UUID或日期加随机串作为对象名，把原始文件名存进数据库作为显示名。下载权限上，把桶设为私有，然后生成带签名的临时URL，指定有效期比如7天，用户点开链接后才能下载。这样就算链接泄漏，也会过期失效，答辩时可以讲这是为了防止资源被无限转发。

上传接口还有一个体验问题：Spring Boot默认单个文件上传限制1MB，如果不改配置，传一个几十MB的课程视频直接报MultipartException。需要在配置里设置spring.servlet.multipart.max-file-size=1024MB和max-request-size=1024MB。如果是本地开发环境，这个配置足够用；如果考虑大视频，还可以做分片上传，但毕设做到“文件能传到MinIO并生成访问链接”这一层，已经能通过大部分老师对完工程度的考核。

3.3 购物车和下单：订单幂等设计与模拟支付闭环

购物车的实现不复杂，核心是购物车表存当前用户ID、课程ID、价格快照。前端页面展示购物车时有加号减号，结算时后端接收一个课程ID列表，重新计算总金额并创建订单。

创建订单接口要注意幂等性。用户在前端点了“提交订单”，如果因为网络原因重新提交，后端就有两张相同订单。最常见的方案是前端生成一个业务幂等号，后端用幂等号加唯一索引去重；也可以在后端做法上，用Redis的setnx锁把一个用户ID作为key，锁一段时间，防止并发重复提交。真正生产级的做法是两者结合，这里不过度展开，毕业设计引入“订单幂等”这个概念并用代码实现，就能体现出一定的专业性。

支付环节的真实对接需要商户资质，个人毕业设计很难申请。更现实的方案是做一个模拟支付：用户选择微信或支付宝后，前端弹出一个模拟收款页面，用户点击“我已支付”，后端把订单状态从待支付改为已支付，同时调用权益发放逻辑，把课程绑定到user_course表。这里有一个非常重要的地方：订单更新和权益发放必须放在同一个事务方法内。如果先改订单状态，再发权益时程序异常，就会出现订单显示已支付但用户的已购列表里为空的情况。

所以支付回调Service方法的代码结构大致是：第一步，校验订单编号存在，且当前状态是待支付；第二步，更新订单状态为已支付，写入支付记录；第三步，创建用户课程权益记录；第四步，把订单ID放入用于通知前端的消息结构里。整个过程用@Transactional包裹，任何一步异常都会回滚到初始状态。

订单关闭机制也可以做成一个亮点：用定时任务扫描超过30分钟未支付的待支付订单，自动改为已关闭。Spring Boot里实现定时任务很简单，启动类加@EnableScheduling，在方法上写@Scheduled(cron="0 0/5 * * * ?")，每5分钟执行一次扫描即可。这个机制在演示时容易被忽略，但答辩时老师问“用户不付款怎么办”，你就可以自然引出这个设计。

3.4 后台管理：课程维护、订单管理和数据可视化

管理后台在毕设里的功能定位是让系统看上去完整、可运营。管理端至少包含四个模块：首页报表、课程管理、订单管理、退款管理。

首页报表要放几张有信息量的图表：总销售额、今日新增订单、已上架课程数量、近7日销售额趋势折线图、销量前五课程排行。这些报表的数据都来自orders和order_item表，SQL里用GROUP BY按日期或者按课程聚合。用ECharts展示折线图时，前端只需要把后端的统计数据映射成x轴和y轴数组即可。

课程管理模块要支持课程的增删改查、上下架、分类归属、封面图和课程视频文件上传。上下架是一个值得强调的业务点：用户端课程列表接口的SQL查询条件里永远要带上“上架状态=1”，同时下单接口要做二次校验，防止用户通过构造请求直接购买已下架课程。这个细节如果不做，管理员下架课程后，用户在线上仍能通过链接购买，就是典型的业务漏洞。

订单管理模块要展示订单明细、支付状态、时间信息，并且提供两种操作：给“已支付”订单执行退款，给“待支付”订单执行关闭。退款操作要联动回收权益：更新订单状态为已退款，同时删除或标记user_course表中对应记录失效。这样用户点进已购课程列表时就看不到这块内容了。把正向购买和逆向退款两个流程都走通，PPT里的业务闭环就可以画得很完整。

4. 常见问题排查与部署实战

4.1 常见错误对照表：这几个坑几乎每个毕设都会踩一次

我整理了课程资源销售系统开发中最高频的几类报错和它们的排查思路，建议直接收藏成排查速查表。

跨域问题值得单独解释一下。前后端分离之后，前端Vue默认跑在5173端口，后端跑在8080端口，两者端口不同，浏览器的同源策略就会拦截请求。后端要配CORS，或者在部署阶段用Nginx把前端页面和后端接口都收敛到同一个端口下。如果用了Spring Security一起配合，要注意allowedOrigins("")不能与allowCredentials(true)同时使用，这是浏览器的安全限制，换成allowedOriginPatterns("")可以解决。

4.2 Docker Compose部署：一条命令拉起整套系统

部署环节很容易被忽视，但答辩现场稳定演示对于最终成绩很关键。我建议用Docker Compose把MySQL、Redis、MinIO、后端应用四个服务编排起来，在干净的机器上能快速启动整套环境。

后端Dockerfile按多阶段构建来处理：先用Maven镜像把项目打成jar包，再用JRE镜像把jar包拷进去运行。这样生成的镜像小，启动也快。依赖的中间件服务如MySQL、Redis、MinIO，都放到docker-compose.yml中，通过环境变量把数据库地址注入到后端容器中。

一个非常容易踩的坑是：application.yml里的数据库地址如果写的是localhost，那么放到Docker容器之后就连接不上，因为容器内的localhost指的是容器自身而不是宿主机。合理的做法是让数据库连接URL支持环境变量覆盖：本地开发时yml里写localhost，部署时通过Compose文件传入SPRING_DATASOURCE_URL环境变量。这样同一份代码，在本地IDEA里能跑，在Docker里也能跑。

前端项目部署相对简单：执行npm run build生成dist目录，用Nginx托管静态文件，并把后端接口的请求路径通过Nginx反代转发到应用容器。前端请求统一走相对路径/api，由Nginx把/api开头的请求转发给后端8080端口。这样浏览器里只有80端口一个入口，不会再有跨域问题。

4.3 答辩演示：三项准备工作提高展示成功率

答辩环节看的不仅是代码，更重要的是演示的连贯性和你对系统设计的表述能力。有三项准备工作值得提前做：

第一，准备一段“脚本化”的演示流程。顺序建议是：先用普通用户账号，演示“注册登录—浏览课程—加入购物车—下单—模拟支付—我的订单—点击下载资源”这条完整购买链路，每个动作之间预留一点时间让数据变化自然呈现；再切到管理员账号，演示课程上架、订单查询、点击退款，并现场展示前台用户端已购资源随之失效。这两个流程做完，业务闭环就非常完整了。

第二，提前创建一个演示账号并准备好数据。课程分类、课程信息、订单记录都提前录入，避免答辩现场边演示边输入课程标题导致打字耗时长。同时把需要下载的资源文件控制在一个大小合理的范围内，比如用一个几MB的PDF示例文件，下载速度会更快，展示效果更流畅。

第三，根据自己项目的实际情况画一张部署架构图。用PPT画清楚浏览器、Nginx、Vue前端、Spring Boot后端、MySQL、Redis、MinIO之间的关系。讲述时按请求顺序来：用户访问前端页面，前端向后端发起HTTP请求，后端读写MySQL数据，把高频访问数据缓存到Redis，课程文件存储到MinIO并通过签名链接提供下载。能把这条链路说清楚，和只是“把代码跑起来”是完全不同的两个面试档次。

论文写作方面，时序图建议画三个：购物流程时序图、支付回调与权益发放时序图、后台退款时序图。这三个图覆盖了系统的核心业务，也把技术难点可视化出来，评审老师看到图就能快速理解项目设计。

做这个Spring Boot课程资源在线销售系统，我最大的一个体会是：先理清业务流程，再谈技术实现，千万不要反过来。很多同学一上来就追求把系统做得复杂，加入各种技术组件，结果数据库关系都没理清。把用户、课程、订单、权益这四条核心数据链路先理顺了，后面加技术组件都是水到渠成的事。

另外再建议一个小习惯：每完成一个接口，就用Postman测一遍并截图留档。这些截图放进论文的系统测试章节，既显得内容扎实，答辩时也不用现场敲代码演示，直接投屏展示接口请求和响应结果，稳定又高效。课程销售这个题目的发挥空间不小，把权限自动发放、资源防盗用、订单幂等这几个关键点做出真实效果，这个项目就能从“及格线”升到“优秀档”。