先说个现象每年到了选题季总有同学问我类似“XXX系统”能不能做、好不好答辩、代码要写多少行。这套课程资源在线销售系统算是我见过最稳的一类选题——它不像纯电商平台那样业务面铺得太大又比普通的“图书管理”“新闻发布”多了一层虚拟商品交付逻辑。Spring Boot是当前企业里最常见的那套后端技术栈课程资源销售又天然带着权限控制、订单流转、文件上传下载这些硬核功能无论从代码量、业务复杂度还是答辩时能讲出来的东西都处在“够用但不超标”的位置很适合拿来当毕业设计。接下来我把这个项目的完整设计思路、核心业务拆解、关键代码落地和答辩避坑一次讲清楚。我默认你已经会一点点Spring Boot的基础用法如果完全没接触过建议先花三天把“Controller-Service-Mapper”这条链路跑通再动手后面的效率完全不同。1. 项目整体设计与技术选型1.1 这个课题好在哪里先搞清楚一件事毕业设计要的不只是一个“能跑的东西”而是你面对评委老师时能解释清楚“为什么这么做”。课程资源在线销售系统恰好把这个优势拉满了。先看业务属性它是电商系统的子集订单、购物车、支付这些流程全都有但比通用电商少了大促秒杀、多级分销、复杂的售后体系工作量可控。再看内容属性课程资源销售涉及图文课程、视频课程、源码压缩包这类虚拟商品这比卖实物商品多了一个核心环节——“交付”。实物商品走物流虚拟商品靠下载权限这个权限控制的实现方案就是你答辩时最值得讲的东西。再说技术栈的覆盖范围。做这个项目你会用到Spring Boot做接口开发MyBatis-Plus做数据库操作MySQL存业务数据Redis做缓存和令牌管理再配合JWT实现无状态登录前端至少也能摸一下Vue或模板渲染。这四年学的东西一个项目基本全串起来了。有些同学担心“网上这么多课程销售系统是不是没有创意”。创意不是毕业设计的核心完整性和原理清晰度才是。哪怕是同一个需求不同人的表设计、订单状态机、权限方案都可能是两套完全不同的实现这本身就是区分度。1.2 技术栈选型与理由我直接按最常见的搭配给出一套推荐组合后面所有的代码和思路都围绕它展开。技术/组件推荐版本理由JDK1.8 或 11教学资料最多排查问题的博客一搜一堆Spring Boot2.7.x稳定且兼容大多数第三方starter不推荐直接上3.xMyBatis-Plus3.5.x省去大量CRUD代码分页、逻辑删除、自动填充都有现成方案MySQL8.0性能够用8.0对JSON类型的支持也更顺手Redis任选稳定版存验证码、缓存课程列表、配合JWT黑名单控制登出JWTjjwt 0.9.x 或 0.11.x前后端分离的标准做法无状态答辩好讲前端Vue 3 Element Plus 或 Thymeleaf偏后端就选Thymeleaf想连前端一起展示就选Vue版本这块特别提一句Spring Boot我为什么推荐2.7而不是3.x。一方面3.x要求JDK17起步很多学校的毕业论文环境还停留在JDK8装环境就够折腾一天另一方面很多第三方starter比如某些老代码生成器和文件处理的依赖对3.x的适配多少有点滞后你花在“踩兼容性坑”上的时间绝对比省下的那点启动速度划算。1.3 角色划分与功能模块梳理这个系统的角色不用做得很复杂三张脸谱就够了游客可以浏览课程列表、查看课程详情但不能下单不能下载资源。注册用户可以登录、购买课程、下载已购课程资源、查看自己的订单和课程包。管理员在用户表上增加一个角色字段就行管理课程分类、课程上架和下架、课程资源上传、订单状态查询修改、用户列表管理。前台的功能点拆开看主要是用户注册登录、首页轮播图和课程推荐、课程分类导航、课程搜索与列表、课程详情展示、购物车管理、订单确认页、支付或模拟支付、订单列表、我的课程、资源下载。后台的功能点则是登录拦截、控制台概览、课程分类管理、课程管理增删改查、上下架、资源文件管理、订单管理、用户管理。功能清单列出来之后你会发现前台面向C端用户后台面向管理员两套页面共用一套后端接口核心服务层逻辑比如订单创建、权限校验是同一个不需要复制代码。这种“一条接口服务两端”的设计在答辩时可以主动提能显示你对系统架构有思考。1.4 数据库设计要点数据库是整个项目的地基地基歪了后面写啥都别扭。先给核心表清单字段我只列关键项t_user用户表id、username、password、nickname、avatar、phone、role、deleted、create_timet_category课程分类表id、name、sort、create_timet_course课程表id、category_id、title、subtitle、cover、price、teacher、description、sales、status0草稿1已上架2已下架、deleted、create_time、update_timet_course_resource课程资源表id、course_id、resource_name、resource_url、file_size、download_countt_orders订单表id、order_no、user_id、total_price、status0待支付1已支付2已取消3已关闭、pay_type、create_time、pay_timet_order_item订单明细表id、order_id、course_id、course_title、course_pricet_cart购物车表id、user_id、course_id、create_timet_banner首页轮播图表id、image、link_url、sort两个容易踩的坑我特别说明一下。第一个坑表名不要用order。order在MySQL里是保留字虽然加上反引号也能跑但每次写SQL都提心吊胆不如直接叫t_orders一劳永逸。第二个坑钱不要用double或float。课程价格你单独弄一个price DECIMAL(10,2)数据库层面就锁死精确度避免后面算订单总价的时候冒出一串0.9999999。这是电商类项目的基本共识答辩时提一嘴“为了规避浮点精度问题”印象分会起来。用户表加一个deleted字段配合MyBatis-Plus的TableLogic做逻辑删除好处是用户注销、课程删除都不丢历史数据。管理员看到的是“已删除”订单明细里关联的课程信息还能正常展示。这在真实项目里是常规操作一个字段换来的查询追溯能力非常值。2. 核心业务逻辑拆解不是所有功能都是CRUD很多同学把毕业设计做成“增删改查展示页”问题就出在没有抓住业务里的关键状态流转。这个项目真正值得深度思考的有四个点登录鉴权、资源权限、订单状态机、支付回调。每个都值得单独拿出来说。2.1 用户登录鉴权与JWT无状态方案先用你自己的话说服自己为什么不用SessionSpring Boot里用Session做一个登录态其实特别简单HttpSession存一下就行。但前后端分离场景下Session依赖CookieCookie有跨域限制而且后端集群部署时Session同步是个麻烦事。JWT的思路是“让令牌自己证明自己”服务器不存用户登录状态每次请求带上令牌后端验签通过就信任。具体流程是用户提交用户名和密码。后端用BCrypt校验密码BCrypt是不可逆哈希每次加密结果还带随机盐比MD5安全得多。校验通过后生成JWT把用户ID、用户名、角色塞进令牌里设置过期时间建议24小时。前端拿到令牌后存到localStorage或sessionStorage每次请求在请求头里带Authorization: Bearer xxx。后端写一个拦截器放行注册登录接口拦截其他接口解析令牌失败就返回401。JWT的字符串结构是Header.Payload.Signature三段式。Header里声明算法Payload里放业务数据Signature用密钥把前两段签名。密钥一定不要硬编码在业务代码里放到application.yml里配置答辩时有人问你“如果密钥泄露怎么办”你能答出“通过配置中心管理”这个深度就够了。登录后拿当前用户怎么拿用拦截器解析令牌得到一个LoginUser对象放进ThreadLocal里Service层随时可以从上下文取。有人会图省事每次从数据库查一遍用户多一次IO不说逻辑上也绕。用ThreadLocal存储请求级别状态请求结束就释放在并发环境下不会串数据。2.2 课程资源下载权限这套系统最关键的点课程资源在线销售和普通商品销售的本质差异在于用户付了钱得到的是虚拟商品的访问权而不是实物快递。所以你要保证一件事——只有下单并支付成功的用户才能下载这门课程的资源包。最直接的一套流程是这样课程详情页展示“立即下载”按钮。前端点击按钮时不是直接发一个GET请求去拿文件地址而是先请求后端接口/api/download/check?courseIdxxx。后端拿到当前登录用户ID和课程ID后去t_order_item联表查t_orders判断是否存在一条user_id当前用户且course_id该课程且status1已支付的订单记录。校验通过返回一个带时效的下载地址或临时令牌校验不通过返回402开头业务码和提示“请先购买课程”。前端收到合法地址后发起下载后端再把文件流写回给浏览器。这套方案的好处是资源地址不会直接暴露在前端源码里就算有人抓包也拿不到永久文件地址。页面里不要傻乎乎地在img srchttp://localhost:8080/upload/xxx.mp4这样的地址上挂远程文件应该全部走后端接口二次鉴权。如果你选择把资源放在MinIO或者云对象存储上流程会升级一步购买成功后后端生成一个“临时下载凭证”给前端前端拿凭证去对象存储取文件有效期比如10分钟。这里面的核心思路都一样——“先校验后取资源”你在答辩时把这个讲清楚老师基本不会觉得这是水项目。2.3 订单状态机与超时关单订单状态不要散着乱改先把状态定义清楚。我用五个状态0待支付、1已支付、2已取消、3已关闭。流转规则是创建订单后状态为待支付。用户如果在支付前主动取消变为已取消。用户如果在有效时间内未支付系统自动关单状态变为已关闭。用户支付成功状态变为已支付。已支付的订单不允许取消不提供退款流程毕业设计可不做。超时关单这个点实现方案有三条路定时任务扫表、延迟队列、Redis过期键监听。对于毕业设计我推荐最简单直接的SpringScheduled定时任务每30秒扫描一次t_orders查出“创建时间超过30分钟且状态为待支付”的订单批量把状态改成已关闭。这种方案有扫码数据库的压力但业务量不大完全够用。你在答辩时如果能主动说出“超时关单在量大的时候要改延迟队列或消息队列这里是简化方案”说明你真理解了瓶颈而不是只会照抄。真正容易出Bug的是支付回调更新状态那一步。回到上面状态机一个订单必须严格按“待支付 - 已支付”的方向流转不能出现“已关闭的订单又被支付成功”。所以更新的SQL要带上状态条件类似UPDATE t_orders SET status 1, pay_time NOW() WHERE order_no #{orderNo} AND status 0这样就避免了并发场景下旧请求把新状态覆盖掉的问题。划重点凡是涉及状态变更的更新必须在更新条件里写上当前状态这是线上项目非常基础的并发控制手法。2.4 支付模块的落地方案不接真实支付怎么演示毕业设计不太建议直接接真实支付网关商户资质和审核流程太繁琐。但完全不接支付又是职业生涯的遗憾所以我给三个级别的方案从简到繁。方案一是纯模拟支付。在订单确认页直接放一个“模拟支付”按钮后端接口直接调用订单状态流转逻辑把订单从未支付改成已支付然后开通课程权限。这是最简单的方案适合时间特别紧的同学但答辩的时候要有心理准备老师会问“如果这是真实支付你会怎么设计”。方案二是接入沙箱环境。某支付平台提供沙箱账号整套支付流程跟真实几乎一致下单时后端调用预下单接口拿到支付链接用户跳转到沙箱收银台登录测试账号密码后完成支付平台后台异步回调通知你的后端接口修改订单状态。这个方案比模拟支付强很多能演示真实的支付流程。方案三是做成账户余额充值。用户先充值一笔虚拟币进余额购买课程时从余额扣款加一个交易流水表t_transaction记录收支明细。这个方案避开了支付网关但多了一张流水表而且演示时你能展示“余额变动”这个动态功能视觉上比“点击直接支付成功”有说服力得多。无论选哪个方案后端都必须预留一个支付回调接口/notify结构上是支付平台把结果POST到你的回调地址你用订单号更新订单状态。回调两个关键词签名验证和幂等处理。签名验证是为了确认请求确实来自平台幂等是为了防止平台重复回调导致重复发货。哪怕你最终不做沙箱只要把这个接口空出来并在代码里写上注释答辩老师就会知道你对真实业务有认知。3. 实操过程与核心环节实现原理讲完进入动手环节。我按“搭骨架 - 登录注册 - 课程与上传 - 下单与权限”的顺序把关键实现和代码片段说透。3.1 项目骨架搭建与工程规范老规矩先用Spring Initializr建一个工程包名建议用com.example.coursesales仅示例。代码结构上我习惯按业务模块建包而不是按技术类型堆积common统一返回包装类ResultT、全局异常处理器、常量定义config配置类CORS、拦截器、MyBatis-Plus配置、文件映射security或者叫interceptorJWT工具类、拦截器、ThreadLocal上下文module/user用户Controller、Service、Mapper、实体类module/course课程相关模块module/order订单相关模块module/file文件上传下载模块工程规范上第一个要做的就是统一返回格式。所有接口返回ResultT结构是{ code: 200, message: success, data: ... }。返回格式统一前端拿数据时统一处理后端排查接口问题时响应结构也一眼可辨这点和大公司接口规范是同一个道理。配套的是全局异常处理。用RestControllerAdvice定义几个异常处理方法业务异常比如“请先购买课程”返回code 400参数校验异常返回code 400权限不足返回code 403系统异常返回code 500。这样就不会出现数据库异常栈直接抛到前端页面上的尴尬场面。代码很简单但很多毕设项目都没做显得很不专业。CORS跨域配置也放在启动阶段做。前端如果用的是Vue单独起一个8081端口访问后端8080端口JSON接口跨域请求就要处理。写一个WebMvcConfigurer配置全局CORS不要在每个Controller上面写CrossOrigin那是到处打补丁的做法。配置里指定允许的来源、请求头和方法allowCredentials设为true。3.2 注册登录模块落地注册流程加一个验证码环节老项目喜欢用算术验证码或者图形验证码现在主流是短信验证码。毕设用图形验证码就是最合适的生成逻辑是后端生成验证码图片写入Redis缓存同时返回给前端一个uuid标识前端提交注册时带uuid 验证码后端从Redis取出来比对。密码存储用BCryptPasswordEncoder。强调一次不要用MD5。MD5是摘要算法不是加密算法不设盐的情况下同一个密码哈希值完全相同撞库工具一撞一个准。Spring Security全家桶太大为了一个密码加密引进来没必要单独引入spring-security-crypto依赖或者直接用BCrypt类就够了。注册接口的逻辑顺序是校验验证码 - 校验用户名是否重复 - 密码BCrypt加密 - 插入用户表 - 返回成功。登录接口的顺序是用户名查用户 - 比对密码 - 生成JWT - 返回令牌和用户基本信息。JWT生成这里贴一段核心逻辑public String createToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(username, username) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }签名的密钥secretKey从配置类里读取不写在代码里。拦截器那边对需要登录的接口统一拦截解析Token失败时直接写401响应。拦截器白名单至少要放行注册、登录、课程列表、课程详情、首页轮播图以及静态资源路径。我见过一个常见Bug是前端页面能打开但图片和CSS全挂了多半是拦截器把静态资源也拦截了白名单里漏了/static/**或/upload/**。3.3 课程管理与文件上传下载课程模块看起来简单其实也有细节。课程表里的cover字段存的是课程封面的访问路径不是本地绝对路径。那路径从哪来文件上传接口先写到本地磁盘一个目录比如D:/uploads或者/usr/local/upload然后通过WebMvcConfigurer.addResourceHandlers加一个静态资源映射把/upload/**映射到物理路径上。请求进来后访问地址http://localhost:8080/upload/xxx.jpg就映射到了物理文件。上传代码用MultipartFile接收前端文件注意三件事。第一文件名不要用用户上传的原始名称用UUID重新生成防止文件名重复覆盖和中文乱码问题第二文件大小限制要在application.yml里配置spring.servlet.multipart.max-file-size100MB第三上传目录要做成可配置项放到配置中心或application.yml后台上传路径变了不用重新打包。课程资源文件的上传和封面图类似区别在于多一张t_course_resource表记录资源和课程的关联关系。资源文件审核关联在管理员上传课程资源那一侧普通用户是看不到的。用户下单成功后我的课程列表接口查出已购课程再查出对应资源下载时走前面说的权限校验。文件下载接口的实现如果文件不大用IOUtils.read读取流并写出就行如果文件较大用InputStreamResource配合响应头Content-Disposition让浏览器弹出下载框。给一个后端流式输出的思路File file new File(resourcePath); ResponseEntityResource responseEntity ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, attachment; filename encodedFileName) .contentType(MediaType.APPLICATION_OCTET_STREAM) .body(new FileSystemResource(file));核心还是一样接口的入口先做权限校验校验通过才把流输出。下载次数也可以顺手在资源表里做一次download_count 1的更新作为后台数据统计的一个指标。3.4 下单流程与购物车实现购物车不是必须的但没有购物车会显得功能单薄。购物车本质是(user_id, course_id)一条记录加购时查重重复加购就直接提示已在购物车。购物车列表要联表查出课程当前价格和封面图这里注意商品价格可能会调整所以购物车展示出来的价格只能作为参考真正下单时要以课程当前价格为准。下单这个动作是最容易出问题的环节。要保证“防重复提交”和“价格一致性”两个点。防重复提交最简单的方案订单号加上唯一索引同一个订单号插入多遍就会报错天然防重。创建订单的核心逻辑前端提交购物车选中的课程列表或直接购买的单个课程ID。后端循环计算总价总价要重新从数据库查价格不能用前端传过来的价格前端传价会被篡改。生成唯一订单号格式可以用yyyyMMddHHmmss加随机数。插入订单主表和订单明细表主表和明细表要放在同一个事务里用Transactional。返回订单号前端跳转支付页面。用户点击支付后后端把订单号、用户ID、待支付状态、应付金额提交给支付模块。支付成功后回调接口把订单状态更新为已支付。更新完成后还要自动在购物车表里删除对应课程记录这一步逻辑上就很通顺用户已经买了购物车里那件商品就没有存在意义了顺手清理。前端“我的课程”列表和后端接口就简单了联查订单、订单明细、课程表条件限定user_id 当前用户 and status 1返回去重后的课程集合展示“去学习”“下载资源”按钮。这里有个业务细节要注意一个用户可能分两个订单购买同一门课如果业务上不允许“重复购买”那在创建订单前要查一遍订单表和订单明细发现存在“已支付”状态的同课程订单直接提示“请勿重复购买”。这个校验放在创建订单的接口里不要在支付成功后才校验不然后果很被动。3.5 后台管理界面的核心页后台管理页面我一向不推荐做得比其他模块“简陋”。实际上答辩时老师对后台的关注度往往大于前台因为后台能直观呈现你的功能完整度。后台最值得做的页面是“订单管理”和“课程管理”。订单管理页要支持按订单号搜索、按状态筛选订单详情展示里把用户ID、课程明细、支付时间、支付类型全部列全。课程管理页要支持分页列表、按分类筛选、编辑课程信息、一键上下架。上下架的状态更新逻辑比CRUD多一点业务含义下架课程不能再被下单所以搜索接口里要加status 1上架条件这个细节做到位前端展示才不会出现“详情打开但无法下单”的跳空状态。管理员创建课程后课程表默认保存为草稿状态管理员编辑完资料再点击“上架”两个动作分开。好处是防止创建到一半的半成品暴露到前台用户浏览界面永远只看到完整信息。这种小细节在论文里也能写一笔“基于审核状态的内容发布流程”显得你有产品思维。后台的统计概览我建议做三张卡片总销售额、今日订单数、课程总数。用SQL聚合就能实现单表查询不需要写复杂join。课程销量排行可以做排行表直接用ORDER BY sales DESC LIMIT 10前端再用柱状图或列表展示。统计功能不用大而全三五个核心指标即可重点是把数据的计算逻辑写清楚。4. 常见问题与答辩经验4.1 开发过程中最容易踩的六个坑我先按踩坑概率从高到低排一下这些都是我实际盯着调试过的。一个是MyBatis-Plus分页不生效。很多人写了分页SQL结果返回的还是全量数据多半是忘了配置分页插件。MyBatis-Plus 3.x的分页插件要自己加一个MybatisPlusInterceptor的Bean不配置分页拦截器Page参数不加进去。这个Bean建议直接写在启动类旁边的config包里配完一劳永逸。一个是日期时间差8小时。MySQL和Spring Boot服务器的时区不一致数据库连接串里加上serverTimezoneAsia/Shanghai和useSSLfalse基本就解决了。另一个更底层的问题是你存进去的是本地时间但JDBC驱动按UTC处理了导致读写出现偏移这种情况配置完时区后重新启动就行。一个是上传文件后重启服务文件神秘消失。本地磁盘上传路径写了临时目录服务器重启临时目录被系统清理。解决思路是不要用默认临时目录把上传路径显式配置为稳定目录比如项目同级目录下的upload-files文件夹然后在重启脚本里保留这个路径。一个是前端请求报CORS跨域。多半是自定义拦截器把“跨域预检请求”给拦截了。浏览器跨域时先发一个OPTIONS请求你的拦截器如果把它拦下来返回401真实请求就会失败。规避方案很简单拦截器放行所有OPTIONS请求或者在CORS配置里把allowedMethods配全实测下来放行OPTIONS最省事。一个是课程表改了之后后台列表不更新。排查思路是看MyBatis的二级缓存开发环境下其实不建议开启二级缓存多一次非核心缓存反而让调试变麻烦。如果确实想用注意修改数据时要手动清对应缓存否则就会遇到“数据库有值但页面显示旧数据”的经典问题。一个是文件下载时文件名中文乱码。浏览器解析响应头里的Content-Disposition时对中文支持不太好要使用URLEncoder.encode把文件名编码成UTF-8后再放入响应头前端弹窗保存的文件名才是正常中文。这个坑不致命但演示的时候一旦触发观感差很多。4.2 答辩时最常被问的五个问题第一个就是“为什么用JWT不用Session”。正面回答毕业设计采用前后端分离结构JWT无状态天然适配多端服务器不用维护会话信息扩展性好令牌内可携带用户角色信息每次请求无需回查数据库。最后补一句“如果要做用户强制下线可以配合Redis黑名单一起用”这个回答闭环就很完整。第二个是“订单超时关闭怎么实现的”。直接贴定时任务扫描方案把SQL条件讲清楚创建时间小于NOW() - 30分钟 且 状态为待支付。如果能补充说明“在大规模场景下会引入消息中间件来优化这里采用简化的轮询方案”老师会认可你的边界意识。第三个是“支付回调怎么保证安全”。两个关键词验签和幂等。验签确保请求来源可信幂等确保重复回调不影响订单状态。把这个逻辑答上来说明你真做过这一层设计而不是停留在前端点击按钮跳转。第四个是“用户没购买能不能直接下载”。这是这个项目最核心的提问点直接回答“不能后端下载接口会校验订单状态”并把前面讲的权限校验流程从头到尾捋一遍。这一题的回答质量基本决定了你项目答辩的档次。第五个是“数据库为什么这么设计”。不用背理论就讲你的决策点订单表单独抽出来因为订单是核心业务表订单明细独立出来因为一单可以包含多个课程课程表加逻辑删除保证历史订单查询不出现空数据价格用DECIMAL避免浮点误差。每说一条都是一个设计决策比背三范式强太多。4.3 现场演示的流程脚本建议演示要提前排练别上了台才开始想先点哪里。我的建议是准备一份演示脚本流程大概是登录管理员账号先把后台课程管理、订单管理、用户管理都点开走一遍展示管理端能做的操作。然后退出登录回到前台用游客身份浏览首页、课程列表、课程详情记住在游客状态下尝试点“立即购买”这里会跳出登录提示这是一个很好的“权限控制”演示点。再切换成普通用户登录把购买流程走完整搜索课程、加入购物车、结算、模拟支付、查看订单、进入我的课程、点击下载资源。最后回到后台刷新订单列表确认刚才那笔订单的状态已经变成已支付。演示前准备一批带占位内容的测试数据至少铺二十个课程覆盖五六个分类有的课程价格为0有的有资源文件有的没有资源文件价格有零有整。这样你讲解的时候可以顺便演示“免费课程不需要购买即可下载”和“付费课程未下单会被拦截”两个相反分支展示逻辑的完备性。再给一个细节演示时如果把页面切换到用户端注意别让后台管理功能按钮出现在普通用户界面上。管理员账号看到的界面和普通用户账号看到的界面菜单要不一样这种角色差异用前端路由守卫或模板条件渲染实现属于“可见即可得”的权限控制。答辩时主动演示“我切到一个普通账号后后台入口彻底消失了”比用嘴解释权限设计直观得多。5. 一点实操之外的心得最后聊几句题外话。做这套系统跟着我前面的方案走代码写出来不会少但真正的学习价值不在这几千行代码里而在于你是否理解了每一个状态变更背后的业务约束。我个人体会最深的一点是不要追求把所有功能都做一遍比如你不需要抽奖、不需要优惠券、不需要秒杀。毕业设计最怕“看起来很多走进去全是坑”。把“课程资源权限控制”和“订单状态流转”这两条线做扎实、讲透彻整个项目的含金量就上来了。给一个压箱底的小技巧把项目的application.yml配置剥离得干净数据库连接、上传路径、JWT密钥全部外置加一个注释清晰的README.md说明项目启动步骤。答辩之前亲自从一台干净的电脑上从零clone代码、装依赖、跑通项目整个过程录制一个短视频存手机里——万一现场环境出问题你还有一手备选方案而且这个录屏本身也能当作项目演示材料用。