企业官网建设流程全解析

做课程资源在线销售系统这类毕设，大多数同学最容易踩的坑不是写不出来代码，而是把毕业设计做成了一个“记账本”：用户、课程、订单三张表一套CRUD，演示的时候鼠标点一圈，答辩老师问两个问题就露馅。课程资源销售和普通商品销售最不一样的地方，在于“卖的东西是一堆文件”，而文件从上传、加密存储、下载鉴权到防盗链，每一步都有文章可做。这篇内容围绕Spring Boot课程资源在线销售系统的完整设计思路、技术选型、核心实现和答辩加分点展开，基本照着走能把系统的深度和完整度拉高一个档次。

1. 需求拆解：课程资源销售系统到底在卖什么

1.1 表面是课程，本质是“文件资产”

打开任意一个课程售卖平台，你看到的是课程封面、标题、价格、销量，但作为毕业设计，真正要处理的核心数据其实是课程资源文件本身。视频、文档、压缩包、音频，这些文件大小从几MB到几个GB不等，它们的存储位置、访问权限、下载方式，直接决定了系统的整体架构设计。

这也是“课程资源在线销售”和“图书在线销售”的本质区别。图书销售处理的是库存和物流逻辑，课程资源销售处理的是数字文件的权限和交付逻辑。明确这一点，系统设计才不会跑偏。

1.2 三方角色和核心业务闭环

一个能通过答辩的课程销售系统，至少要包含三种角色：

• 游客：浏览课程、查看详情、搜索筛选，不能下单。
• 用户（买过课的）：下单购买、查看订单、下载已购课程资源。
• 管理员：维护课程分类、上传课程资源、管理订单、处理用户反馈。

业务闭环上，最小可用的链路是：用户注册登录 → 浏览课程详情 → 加入购物车 → 生成订单 → 模拟支付 → 订单状态变更为已支付 → 解锁课程资源下载入口 → 用户下载文件。把这个闭环跑通，系统的主干就已经很完整了。详情页要展示讲师介绍、课程大纲、资源文件列表、价格、销量和评价，这部分是界面展示的主要工作量。

1.3 一个容易被忽略的隐藏角色

很多同学的ER图里只画了用户、课程、订单、分类表，其实还缺一张角色表或菜单权限表。如果用了Spring Security或Sa-Token这类安全框架，权限模型必须落到角色上。更合理的做法是放在资源权限控制里，严格控制已购买了课程的用户的下载权限。哪怕不把后台权限做得特别复杂，也至少要保证“普通用户不能访问管理接口”这条底线，很多答辩翻车案例都是因为用一个普通账号直接调出了后台订单数据。

2. 技术选型为什么是Spring Boot为主干，周边组件怎么配

2.1 Spring Boot + MyBatis Plus是毕设最稳的组合

课程资源销售系统的正文一般不会涉及特别复杂的多表关联查询，主要操作是单表条件查询、分页列表、订单状态流转。MyBatis Plus的Wrapper机制对这类场景非常顺手，写起来比原生MyBatis的XML简单很多，比如筛选上架状态的课程：

LambdaQueryWrapper<Course> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Course::getStatus, 1) .like(StringUtils.hasText(keyword), Course::getTitle, keyword) .orderByDesc(Course::getSalesCount); Page<Course> page = courseMapper.selectPage(new Page<>(current, size), wrapper);

2.2 新版语法写起来更直观，Java 8的兼容性也更稳定

Java 8配合Spring Boot 2.5或2.6，是大量线上项目的经典稳定组合。如果你非要用Spring Boot 3.x，JDK 17跑起来没问题，但注意javax包名要改Jakarta。很多教程里用的还是javax.servlet的写法，版本对不上，代码复制过来编译直接报错。

2.3 文件存储：本地磁盘优先，MinIO做加分项

文件存储有三个层次的方案选择：

• 纯本地磁盘存储：课程上传后存到本机目录，配置一个资源映射路径，最新的Spring Boot版本注意配置路径问题。适合毕业设计快速跑通，缺点是无法扩展，答辩时容易被追问大并发场景下的极限问题。
• OSS云存储：校园本地环境依赖外网，上传速度不稳定，而且需要实名认证、充值和API密钥配置，重点其实是安全策略。适合截图演示，但本地开发调试不太顺手。
• MinIO私有化对象存储：开源、界面直观、支持分片上传和断点续传，演示时可以直接展示一个完整的上传下载流程和访问控制策略。这是推荐方案，数据可控，数字资源属于敏感内容，答辩时能讲的深度更多。

2.4 前端选型的分寸感

有不少同学选纯模板引擎渲染，用Thymeleaf拼页面。这个方式在纯单一项目里跑得动，但课程详情、购物车、订单列表这类交互多的页面，就会写得很难受，前后端耦合严重。另一个极端是独立Vue项目+跨域联调，工作量大，部署也更麻烦。

比较均衡的做法是：用Vue写前端，npm run build构建完静态资源之后复制到resources/static目录下，和Spring Boot打包成一个jar，同端口部署。这样既保留了前后端分离的开发体验，又不用处理跨域问题。整个前后端和应用服务器组合成的jar包，演示时一个命令就能启动。构建完成再启动，接口统一走/core前缀，测试起来干净利落。

3. 核心功能实现：从登录鉴权到课程结算的完整链路

3.1 JWT登录态和Sa-Token，哪个更适合这个场景

登录鉴权是销售系统的关键入口，方案通常有三种。

Session方案最传统，但前后端分离后需要处理Cookie跨域，且CSRF防护也要额外配置，体验不顺畅。

Spring Security + JWT是面试高频组合，但学习成本高，配置复杂，毕业设计时间紧不划算。

Sa-Token方案中文文档丰富，API设计直白，默认集成Redis可以实现单点登录，且自带权限校验注解，对权限要求明确的场景是更顺手的方案。如果你的项目里管理员操作接口比较多，用Sa-Token标注权限会省很多事：

@SaCheckPermission("course:add") @PostMapping("/api/course") public Result addCourse(@RequestBody Course course) { courseService.save(course); return Result.ok(); }

3.2 课程资源文件怎么存储才安全

文件上传是最容易在演示阶段翻车的环节，要做的主要是权限校验、类型限制、大小检查和路径规划。

文件大小限制建议按文件类型区分处理。视频类大文件用独立接口并返回上传id，避免长耗时请求凑在一起放大超时风险。建议将max-file-size和max-request-size统一调高到比如1024MB，否则Spring Boot默认的1MB限制会静默拦截大文件上传，前端收到异常后用户以为卡住了。

存储路径建议按文件类型和时间分目录，比如：

course/{courseId}/{yyyyMMdd}/{uuid}.{ext}

从业务逻辑上防止了单目录文件过多的问题，而且相同课程的资源天然组织在一起，方便管理备份。上传后不要把完整路径存进一张公开表，而应该同时记录文件的相对路径和加密存储状态，详情页只返回文件的标题和大小，真正能访问的URL必须通过专用接口鉴权后生成，用带token的临时链接访问。

3.3 订单状态机设计的常见错误

订单模块很容易被做成“提交订单 → 状态改成已支付 → 完事”，这种思路后续处理售后和支付回调时漏洞很多。基础状态也应该按流程图中的环节逐步推进：CREATE状态对应待付款，PAID状态对应已支付，COMPLETED状态对应已完成，CANCELED和REFUNDED做售后流转。

推荐维护一张订单状态变更记录表，这也是答辩时加分的一项，写明某个用户在某个时间点把订单从什么状态改成了什么状态。支付网关都要做幂等控制，状态变化不被重复处理；数据库里给订单号加唯一索引也是避免数据重复的关键设计。

3.4 模拟支付怎么设计才容易被追问

课程销售系统不接真实支付渠道，通常用模拟支付代替。最简单的实现是订单详情页里做个“确认支付”按钮，点击后直接调支付回调接口，把订单状态从待付款改成已支付。但答辩时老师很可能会问：如果支付成功了通知没送到怎么办？更稳妥的做法是保证扩展类和接口分离，模拟支付模块有自己的支付回调处理类，积分与权益入口都从这里统一安排。

定时任务可以扫描超过30分钟未支付的订单，做自动取消和库存回滚，这是把Java定时任务和订单一致性兜底能力结合起来展示的亮点。

4. 实际集成中的坑：版本冲突、文件下载和Vue打包细节

4.1 版本“太新”反而问题多

毕设中经常会碰到来自网上最新的代码片段，直接把Spring Boot版本拉得很高。结果引入某个依赖时版本冲突，耗费大量时间排查。比如用MinIO的Java SDK版本和Spring Boot版本不匹配会导致依赖冲突。稳妥做法是确定一个已知稳定的Spring Boot版本（2.5/2.6），所有组件版本以Maven中央仓库中标注兼容的版本为准，不要超过已知组合的上限。上线前再按实际版本统一调整，时间成本最低。

4.2 上传文件超时，先看链路而不是只调参数

如果你配置了很大的文件上传限制，上传大文件时却总是服务器没有响应，排查顺序别乱：

第一步看Nginx，如果是本地直接启动Spring Boot，就只有两边可能出问题。如果部署中带了Nginx反向代理，第一嫌疑就是它的client_max_body_size默认1M忘改了，应改成和Spring Boot配置一致的上限。

第二步看Spring Boot的配置，multipart大小和Tomcat的max-swallow-size配合调整，max-request-size也要覆盖整个请求大小。只要这三处配置有一条漏了，大文件就会中途断掉。

第三步看监控后台的超时日志，定位是传输卡住还是后端处理慢，再针对性处理。

4.3 Vue打包进Spring Boot后的白屏和路由404

前端构建完后，文件放进resources/static后启动，可能出现首页白屏、刷新页面404这些问题。白屏大概率是静态资源路径问题，Vue默认的base路径是/，放到Spring Boot后所有资源都在/static下，调整Vue配置文件里publicPath为相对路径就可以解决。刷新页面404是路由模式引起的，改成hash模式能快速规避刷新问题：

const router = new VueRouter({ mode: process.env.NODE_ENV === 'production' ? 'hash' : 'history', routes });

4.4 接口返回的时间字段和金额字段处理

课程价格如果直接用double存，结算时会出现小数误差，数据库订单金额精度还会不一致。价格应考虑用分存储，展示层再做转换。金额字段建议用Long或BigDecimal，入库用分单位，既符合主流电商的数据模型，也利于答辩时展示你是认真考虑过字段设计的。时间字段建议用timestamp，数据库层面避免时区错乱问题。

5. 答辩和论文的拔高策略：不只让系统能跑

5.1 给缓存和搜索留出扩展位

课程首页高并发场景下，热点课程的详情数据和封面图地址每次都查MySQL，性能瓶颈很明显。建议在本地使用Spring Cache配合Caffeine，做一个简单的进程内缓存，简单又容易演示。缓存击穿、雪崩这类问题哪怕不深入实现，把处理方案写在论文里也能体现设计意识。搜素场景不引入Elasticsearch也是合理的，课程数量量级不大的场景下MySQL的LIKE查询足够应付；但论文里要主动说明这个取舍，并设计商品ES同步接口的扩展位，答辩时就能讲清楚。

5.2 设计文档和解说流利度，决定上限

演示时老师大概率不会只看功能，通常抓住设计思路和后端逻辑提问。讲系统的思路比打开系统点鼠标更关键。建议提前准备一张后台事务时序图，把用户从加购到支付再到资源下载的完整时序讲清楚，QPS量级、数据量级、部署形态这几个问题做到随口能答。

另外，项目里的报错提示、接口返回格式、敏感词汇校验、订单异常兜底这几个非功能点，往往比功能点更能说明问题。

5.3 项目命名和模块切分，尽量避免“大杂烩”

课程资源在线销售系统的模块切分需要清晰：

• controller层只管参数接收、调用和结果包装
• service层解耦业务逻辑组合与底层能力编排
• mapper层聚焦数据库操作
• resources目录下按静态资源、配置文件和数据库脚本清晰隔离

上课和视频资源的类型判断，可以在Service里抽出独立的资源分类处理器。论文里对“课程资源存储与权限控制模块”单独描述，应付“为什么用这个技术”的追问就游刃有余。

6. 一个完整的开发路径建议

6.1 分阶段推进，每阶段都能演示

毕设容易被反复返工的核心原因是“想一步到位的程度太大”。更好的方法是拆成四个阶段推进，每个阶段结束后都有可运行版本：

第一阶段完成用户注册登录和后台课程分类管理，把权限框架串起来。

第二阶段完成课程列表和详情展示，接上文件上传下载，形成核心数据流。

第三阶段完成购物车、订单和模拟支付闭环，让整个业务流程循环跑通。

第四阶段做样式打磨、异常提示完善、定时任务收尾，以及文档准备。

6.2 开发前定好的统一约定

接口前缀建议统一为/api，管理端为/admin，前后端共用一个端口，命名空间清晰，省去大量不必要的联调定位时间。返回结果统一用Result对象封装，包含code、message、data三要素，前端可以在axios的响应拦截器里统一处理错误状态：

service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { Message.error(res.message); return Promise.reject(new Error(res.message)); } return res; }, error => { Message.error(error.message); return Promise.reject(error); } );

这种统一约定能减少非常多的冗余代码，也让整份代码的规范性明显提升。答辩时老师翻代码看到这种结构，给出的印象分会自然高不少。

6.3 从演示到上线，有一件事提前做更安全

很多同学的演示环境是笔记本电脑，Wi-Fi网络不稳定。建议提前准备可脱离网络的演示环境，把所有依赖弄清楚，避免现场装依赖翻车。数据库脚本、本地存储目录、上传文件目录都放到项目内相对固定位置，演示时减少路径相关的意外。如果能控制可变参数的数量，演示的整体稳定度就越高。

课程资源在线销售这个方向，技术上覆盖了Web开发中最常被面试问到的模块：权限认证、文件操作、订单状态流转、定时任务、缓存设计。把这些点都做扎实，论文有内容可写，答辩有细节可讲，技术上也真正是能力提升。我最后一条体会是：这类系统的价值和复杂度不在“卖”这个动作，而在资源和订单的流转管理。把文件资源管好、把订单状态管清楚，这个毕设无论拿到哪个标准下评价，都不会弱。