想搞清楚一个课程学习平台的核心链路最有用的办法不是直接堆代码而是先把业务的毛巾拧干。课程学习平台表面上是“上架课程、用户观看”实际上背后牵涉的是一整套体系用户注册登录、课程管理、视频存储、学习进度记录、评论互动、订单支付、后台统计。只有当这些模块都串起来了平台才算真的能落地。结合Spring Boot来做这套系统是当前后端开发里成本最低、迭代最快、坑最少的路线之一。Spring Boot的自动配置、起步依赖和生态成熟度让开发者可以集中精力去梳理业务逻辑而不是把时间耗在框架整合的琐碎细节上。这篇文章我就用实际操盘的视角把基于Spring Boot的课程学习平台从设计到实现、从监控到部署的完整链路拆开讲一遍包括我在开发中踩过的坑和一些常规文档不会写的东西。1. 项目背景与整体设计思路1.1 课程学习平台的核心需求拆解任何项目动手写代码之前先得回答一个问题这个平台到底给谁用解决什么问题。课程学习平台的关键角色通常有三类学生、讲师、管理员。围绕这三类角色需求可以拆成下面这几块学生端注册登录、浏览课程列表、查看课程详情、加入学习、记录学习进度、收藏课程、发表评论、购买付费课程。讲师端创建课程、上传视频、维护课程章节、查看自己课程的学习数据。管理端用户管理、课程审核、分类维护、订单管理、数据统计、系统配置。从技术角度再看这些需求会发现一个很重要的特征这个系统属于典型的“重业务、轻算法”的CRUD密集型系统。除了视频点播和进度记录有点特殊其他模块本质上都是对数据库的增删改查。这就决定了技术选型不需要堆砌重型中间件而是要选一个能快速支撑业务迭代、同时保证工程质量的东西。我在实际设计时把系统分成了课程模块、用户模块、订单模块、评论模块、统计模块五个核心域。每个域独立成包互相之间通过明确的接口调用避免后期业务复杂度上来之后代码乱成一锅粥。订单模块单独拆出来是因为支付涉及到第三方回调事务边界和状态流转必须独立这点在后面会细讲。1.2 为什么选择Spring Boot作为基础框架Spring Boot在Java后端生态里已经不是一个可选方案而是事实上的默认起点。它解决了Spring Framework时代最让人头疼的几件事大量的XML配置、依赖版本冲突、部署环节复杂。AutoConfiguration机制让大部分组件可以做到引入即用起步依赖把常用库的版本统一管理起来大大减少了配置时的心智负担。换个角度说课程学习平台这种项目有非常典型的特点业务需求变化频繁、需要快速上线迭代、团队里可能有不同水平的开发者。Spring Boot配合Maven或Gradle的多模块工程可以把工具类、数据层、业务层、接口层清晰地分离新同学拿到项目后通过约定的分层结构也能快速上手。这一点在项目维护周期里比什么都重要。另外Spring Boot庞大的社区意味着你在开发中遇到的绝大部分问题都已经有人踩过坑并且把答案写在了Stack Overflow或者GitHub的issue里。比如视频上传的并发控制、JWT过期刷新、分页查询的深度翻页优化这些通用问题全都能找到成熟的解决方案。2. 技术选型与核心依赖解析2.1 持久层方案MyBatis-Plus还是Spring Data JPA课程学习平台这类系统持久层方案的选择会在日常开发效率上拉开很大差距。我在实践里更倾向于MyBatis-Plus原因很简单它在MyBatis的基础上提供了非常舒服的单表CRUD封装同时又保留了手写复杂SQL的灵活性。Spring Data JPA学习的门槛其实更低英文命名的方法推导就能完成大部分单表查询。但课程平台的查询场景非常复杂尤其是课程搜索、学习统计、订单报表这类需求经常需要嵌套子查询、动态条件拼接、多表聚合JPA在处理这些复杂SQL时要么写JPQL要么搞Specification代码的可读性会迅速下降。MyBatis-Plus的优势正在这里。它的LambdaQueryWrapper让单表查询写起来非常简洁同时XML文件里依然可以写高度优化的复杂SQL。比如统计一个课程的总学习人数、累计播放时长、完课率这类统计SQL直接写在XML里性能可控、逻辑清晰。我给大家一个具体的依赖建议这些版本组合实测稳定parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency /dependencies2.2 Spring Boot版本选择2.7.x还是3.x今年用Spring Boot做新项目最先要拍板的事就是版本。Spring Boot 2.7.x是2.x系列的最后一个维护版本稳定可靠各种开源组件的兼容性也最好。Spring Boot 3.x要求JDK 17起步底层基于Jakarta EE规范性能上确实有提升但一些老牌组件还在适配期。课程学习平台属于业务密集型系统对框架层面的新特性依赖度并不高。我个人的建议是如果团队技术栈还停留在JDK 8或者需要接入大量第三方SDK比如老版本的阿里云OSS SDK、微信支付SDK优先选Spring Boot 2.7.18避免版本冲突带来的无谓踩坑。如果是全新团队、新项目JDK 17已经普及可以直接用Spring Boot 3.x这样未来几年的技术演进不用再做大版本迁移。内核版本定了之后业务代码层面要注意一个问题不同版本对配置项的处理方式有区别比如Spring Boot 2.7的路径匹配策略是AntPathMatcher3.x默认切换到了PathPatternParser。如果你的拦截器里写了/**这种通配路径3.x下需要对配置做相应调整。我见过不少项目升级3.x后权限拦截器突然不生效原因就在这。2.3 数据库表结构与核心实体设计数据库设计是课程学习平台的底盘这个设计不好后期每一个功能都会别扭。我直接分享一套经过实际项目验证的表结构基本能覆盖课程学习平台的绝大多数业务场景user用户表字段包括id、昵称、手机号、密码BCrypt加密、头像、角色学生/讲师/管理员、状态。course课程表字段包括id、讲师id、课程标题、简介、封面图URL、分类id、价格、状态草稿/上架/下架。course_section课程章节表字段包括id、课程id、章节标题、排序、视频URL、视频时长。user_course学习关系表记录用户购买了哪些课程或加入了哪些免费课程。study_progress学习进度表字段包括id、用户id、章节id、已观看时长、总时长、最后观看时间、是否完成。course_comment课程评价表字段包括id、课程id、用户id、评分、评论内容、创建时间。orders订单表字段包括id、订单号、用户id、课程id、金额、支付状态、支付时间、第三方流水号。category课程分类表。这套表结构有几个细节值得说明。学习进度表不要和课程表耦合在一起因为一个用户学习多个课程进度数据天然是独立增长的单独成表方便单独做性能优化。订单表必须独立因为订单状态变化频繁查询条件多样和课程表搅在一起会导致索引混乱。外键我建议一律不加物理外键用索引加逻辑关联就行。课程学习平台的数据有典型的写少读多特征物理外键在插入和更新时会带来额外的锁定开销在并发场景下容易成为性能瓶颈。业务层面的关联完整性由Service层去保证。3. 核心功能模块实操实现3.1 用户体系与JWT认证用户体系是课程学习平台的第一道门。我的习惯是Spring Security JWT的组合但不会把Spring Security的复杂度全部铺开只用到它的认证过滤器链。核心思路是用户登录成功后签发JWT之后每一个请求在过滤器里校验Token并把用户信息放入上下文。JWT的密钥管理是个容易翻车的地方。硬编码在代码里是最常见的坏味道正确做法是放到配置中心或者至少放到application.yml里通过外部环境变量注入。过期时间我建议设为2小时同时配合一个简单的Redis缓存来做刷新能力。这样既保证了无状态认证的扩展性又能在用户修改密码或被封禁时通过删除Redis键强制Token失效。Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Autowired private JwtTokenProvider jwtTokenProvider; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token resolveToken(request); if (token ! null jwtTokenProvider.validateToken(token)) { Long userId jwtTokenProvider.getUserId(token); UserContext.set(userId); } filterChain.doFilter(request, response); } private String resolveToken(HttpServletRequest request) { String bearerToken request.getHeader(Authorization); if (StringUtils.hasText(bearerToken) bearerToken.startsWith(Bearer )) { return bearerToken.substring(7); } return null; } }密码存储必须用BCrypt加密这是不可商量的安全底线。明文密码、MD5加盐这种老做法在课程平台上绝对不能出现因为一旦数据库泄露影响的是平台所有用户的账号安全。spring-security-crypto里的BCryptPasswordEncoder直接用就行。这里还要提醒一点同时使用Spring Security和自定义拦截器时要小心过滤器链的顺序问题。JWT过滤器要放在UsernamePasswordAuthenticationFilter之前Spring Security配置里要用addFilterBefore去注册否则你会看到自己的过滤器不执行排查到怀疑人生。3.2 课程管理与视频点播课程管理模块的核心是视频资源的上传和播放。这里有一个经典的架构决策视频文件放在哪里怎么播放。我推荐的方式是对象存储加CDN分发上传时先通过后端接口生成一个带签名的上传凭证前端直接把文件分片上传到对象存储避免大文件走应用服务器导致占用带宽和内存。在课程学习平台的场景下视频文件往往是GB级别的如果让Spring Boot应用去接收完整视频流一次并发上传就能把应用的可用连接数耗尽生产环境必然出事。应用服务器上只保存视频的元数据URL、时长、大小、编码格式播放时前端拿到视频URL直连对象存储。如果要做到防盗链和访问控制可以在生成课程章节信息时由后端签发一个带时效的播放凭证签名URL过期自动失效。这个方法在技术实现上不复杂但能有效避免视频资源被外部直接盗用。涉及视频存储时还有一个常被忽略的点不同格式的视频在不同终端上的兼容性差异。MP4格式是目前兼容性最好的选择但要注意H.264编码和AAC音频这个组合在网上课堂场景下能覆盖几乎所有浏览器和移动设备。如果有转码需求可以引入FFmpeg做服务端转码转码后的文件再上传到对象存储。3.3 学习进度追踪与断点续学学习进度是课程学习平台区别于普通视频网站的核心功能。要实现断点续学核心是定期上报并保存用户的观看位置。我采用的做法是前端播放器每15秒向后端上报一次当前播放进度后端收到上报后更新学习进度表。接口设计上要注意防抖。用户拖动进度条或者倍速播放时上报频率会突然增加如果每次上报都去更新数据库压力会成倍上涨。我的方案是后端在Redis里暂存进度每隔30秒或进度变化超过阈值时才批量写入数据库。这个方案实测下来能把数据库的写入压力降低90%以上。还有一个卡了很多人的坑计算完成状态不能简单看播放到结尾。我在项目里采用的计算逻辑是当观看时长超过视频总时长的90%时标记该章节为已完成这样既避免了用户拖进度条到结尾就瞬间算完成的白嫖行为也允许用户跳过片头片尾。一旦某个章节完成了还要触发一个级联动作更新用户课程维度的学习进度百分比。这个动作可以用Spring的事件监听机制去做ApplicationEventPublisher发布一个SectionCompletedEvent监听器里更新user_course表的进度字段。4. 关键环节的工程化落地4.1 统一返回体、异常处理与参数校验课程学习平台的前后端交互返回体必须统一。我在项目里定义了一个ApiResponseT泛型类包含code、message、data三个字段。code为0表示成功非0表示业务异常。所有Controller的返回值都包装成ApiResponse前端拿到后先判断code再取data逻辑高度一致。public class ApiResponseT { private int code; private String message; private T data; public static T ApiResponseT success(T data) { ApiResponseT response new ApiResponse(); response.code 0; response.message success; response.data data; return response; } public static T ApiResponseT error(int code, String message) { ApiResponseT response new ApiResponse(); response.code code; response.message message; return response; } }配合全局异常处理业务代码里就不用到处写try-catch了。我习惯定义一个BizException携带错误码和错误信息Service层检测到业务不满足条件时直接抛出。RestControllerAdvice里统一捕获BizException返回对应错误捕获参数校验异常返回参数错误信息捕获兜底的Exception返回系统繁忙。参数校验用javax.validation的注解NotBlank、NotNull、Size、Email等。实体类上标注好Controller接收参数前加Validated就能自动完成校验省去一坨一坨的手写判断。特别提醒分页参数和价格这类数字参数记得加上Min(1)这类边界校验否则会出现用户传负数把数据库查挂的惨剧。4.2 文件上传与对象存储接入课程平台不光有视频还有课程封面图、讲师头像、课程资料附件等资源。文件上传这块如果不做限制很快会被上传垃圾文件拖垮。我的策略是统一走对象存储按业务目录划分bucket或前缀。封面图片限制格式jpg/png/webp大小不超过5MB。视频文件限制mp4格式大小在分片上传前提下不做硬性限制。附件资料限制pdf/zip格式大小不超过100MB。上传流程是后端生成上传凭证前端直传OSS回调通知后端记录文件元信息。这样做的好处是文件不经过应用服务器后端只需要管理文件与业务的关联关系。如果用MinIO自建API和阿里云OSS高度兼容代码层面写一个StorageService接口做适配以后切换供应商只需要改配置。public interface StorageService { String upload(MultipartFile file, String bucket); String createUploadToken(String bucket, String objectName); void delete(String bucket, String objectName); }这里有一个我在长期实践中总结的经验存储路径不要用日期而是用业务ID加UUID。比如课程封面存储在cover/{courseId}/{uuid}.jpg这样定位文件、排查问题、清理垃圾时都会高效很多。如果路径里加日期最终会出现一个目录塞满几千个文件根本分不清属于哪些业务。4.3 第三方接口和内部模块接口怎么划分一个经常讨论的问题Spring Boot应用对外提供给第三方的接口应该单独部署一个服务还是放在现有服务里。我的答案是看调用方属性。如果第三方的调用模式是低频、独立域的业务数据交换那直接在当前系统里开一组独立的Controller路径前缀用/open/api/v1配合独立的鉴权机制比如AppIdAppSecret签名就行。这样做的好处是没有服务拆分带来的运维复杂度业务改动也不需要跨服务联调。但如果第三方的调用需求是高频的、核心链路上的比如开放平台、小程序端对接我建议单独拆一个服务。课程学习平台的核心是学生端学习链路外部系统的对接如果频繁触发事务、消耗数据库连接池会直接和主链路争抢资源。单独拆出接口服务后可以做独立的限流、独立的数据库连接池配置故障隔离效果立竿见影。在同一个系统里区分内部接口和第三方接口路径上是第一步更重要的是鉴权逻辑要分开。内部接口走JWT用户认证第三方接口走签名校验。这两者绝不能共用同一套校验逻辑否则会出现用户伪造请求访问第三方接口权限的漏洞。5. 监控、日志与生产环境部署5.1 Spring Boot Admin监控接入生产环境里一个很现实的问题用户说课程打不开到底是服务挂了还是数据库连接池满了还是内存不够了。没有监控你只能登录服务器一条一条命令去查效率极低。我的方案是给课程学习平台接入Spring Boot Admin。架构上我会拆成两个应用一个是监控服务端spring-boot-admin-server一个是业务服务端被监控的应用。业务应用只需要加依赖并配置暴露health、metrics、info、env这些端点监控服务端就能自动发现业务应用的运行状态。dependency groupIdde.codecentric/groupId artifactIdspring-boot-admin-starter-server/artifactId version2.7.10/version /dependency实际使用中Spring Boot Admin能直接看到JVM内存占用、线程池状态、HTTP接口调用耗时、数据库连接池使用情况。这些指标对课程学习平台来说都是救命级的。比如线上学员反映视频加载慢打开监控一看数据库连接池的活跃连接数已经飙到上限大概率是某个慢SQL把连接池拖垮了。有一点必须提前踩一下Spring Boot应用接入Admin后默认暴露的端点可能包含敏感信息比如env端点里的数据库密码。生产环境要在配置文件里限制暴露范围只开health、info、metrics这三个就行。5.2 自定义监控指标学习人数和订单数Spring Boot Admin自带的指标是JVM层面的业务层面的指标要自己埋点。监控业务指标很直观的价值在于运营同学问你今天新增了多少学习用户、完成了多少订单你能马上从监控页面上看到实时数据。我的做法是使用Micrometer的MeterRegistry在关键业务节点进行埋点Service public class EnrollmentService { private final MeterRegistry meterRegistry; public EnrollmentService(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } public void enroll(Long userId, Long courseId) { // 业务逻辑... meterRegistry.counter(course.enroll.total).increment(); meterRegistry.counter(course.enroll.course, Tags.of(courseId, String.valueOf(courseId))).increment(); } }把埋点数据上报到Prometheus再由Grafana展示。这套链路搭起来之后运营看板、实时监控、故障告警全部打通。对于一个基于Spring Boot的课程学习平台来说这几天的搭建投入换来的收益是几何级的因为你从用户说了我才知道变成了自己第一时间发现异常。5.3 生产部署方案与IDEA社区版的日常开发配置课程学习平台的部署方案我推荐用Docker Compose编排Spring Boot应用、MySQL、Redis、MinIO。Spring Boot应用打成jar包后构建镜像非常轻量。一台2核4G的云服务器完全带得动这套组合。FROM openjdk:8-jre-alpine COPY app.jar /app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app.jar, --spring.profiles.activeprod]不少同学用IntelliJ IDEA社区版做Spring Boot开发其实完全没问题。社区版虽然不像终极版那样自带Spring Initializr和Restful Web Service客户端但Spring Boot项目的创建用start.spring.io网页生成再用社区版打开开发体验几乎不输。日常编译运行、调试断点、Git操作这些核心能力社区版都完整支持。IDEA社区版里有一个实用配置值得分享配置application.yml的Profile切换。在Run/Debug Configuration里的Active Profiles填上对应的环境标识启动时就自动加载对应环境的配置避免每次手动改spring.profiles.active。6. 常见问题与避坑指南6.1 事务失效的经典场景课程学习平台里下单、报名、更新进度这些操作都涉及事务。我曾经踩过的一个典型的坑在同一个类里方法A调用方法BB上有Transactional注解但事务没有生效。这是Spring AOP代理机制导致的问题——this调用绕过了代理对象注解自然失效。解决办法有两个一个是通过ApplicationContext获取代理对象再调用另一个是把需要事务的方法拆到独立的Service里面。后者在可维护性上也更好。另一个常见的情况是Transactional只写在Controller上这只能算事务传递到Service的入口正常还是不生效的因为事务拦截器默认只对Spring管理的Bean有效。另外Transactional默认只对RuntimeException回滚。自定义的业务异常如果没有继承RuntimeException事务就不会回滚。一个稳妥的做法是让自定义BizException继承RuntimeException同时明确抛出即回滚。还有一个迷惑行为把Transactional加在private方法上。Spring的AOP对private方法完全无效注解会被静默忽略。排查事务问题时先检查方法是不是public、是不是从外部调用、异常类型是不是RuntimeException这三个问题几乎覆盖了90%的事务失效场景。6.2 视频加载慢和跨域问题视频加载慢是课程学习平台最容易被投诉的问题。一个容易被忽视的原因是后端接口里做了重定向或者代理导致视频流没有走CDN节点。我在实践中发现播放请求必须直接指向对象存储的CDN地址不要经过Spring Boot应用转发否则应用带宽会成为瓶颈。这里给一个生产环境可以直接借鉴的配置为视频文件单独建CDN加速域名对象存储配置好跨域规则允许来源域名携带凭证访问。Spring Boot应用在返回视频地址时签发一个带签名的URL来防盗链。跨域问题主要在开发环境最明显。前端跑在8080端口后端跑在8081端口直接请求就会出现CORS错误。解决方案是在Spring Boot里配置CorsFilter允许指定域名或者开发环境全放开。注意不要把allowedOriginPatterns配置成*去看正式环境否则任何网站都能调用你的接口安全风险极大。6.3 查询性能优化与缓存策略课程学习平台典型的性能瓶颈出现在课程列表页和课程详情页。大量用户同时访问首页时每次都从数据库查全量课程数据再排序分页数据库很快就会被压垮。我用两级缓存策略解决这个问题一级是Redis缓存课程列表的首页数据过期时间5分钟二级是本地缓存Caffeine缓存热门课程详情过期时间60秒。public ListCourseVO getHotCourses() { String cacheKey course:hot; ListCourseVO cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return cached; } ListCourseVO courses courseMapper.selectHotCourses(); redisTemplate.opsForValue().set(cacheKey, courses, 5, TimeUnit.MINUTES); return courses; }这个策略里有非常关键的一层逻辑缓存更新的时机不能只靠过期时间还要在课程上架、编辑、下架时主动删除相关缓存。否则运营改了课程标题用户端还要等5分钟才能看到更新。在Service层里维护一个缓存清理的公共方法每次课程变更后调用即可。对于课程搜索如果在数据量超过10万条的情况下直接用LIKE %关键词%的性能会非常难看。课程学习平台可以先加一个简单方案用MySQL全文索引ngram解析器扛过初期等数据量再上一个量级再迁移到Elasticsearch。初期过度设计反而是负担。6.4 订单支付回调的幂等处理订单模块在课程学习平台里是钱相关的高危区域。支付平台回调通知你支付成功时如果网络抖动导致回调重复发送你的接口收到了两次相同的回调这时候如果直接修改订单状态数据就乱了。解决方案是回调处理的幂等性。我的方案是回调请求处理前先去Redis查该订单号是否已处理如果已处理直接返回成功不重复更新。同时在数据库层面做一道兜底订单状态更新时加上where status PENDING条件只有待支付的订单才能更新为已支付这样就算Redis失效数据库自身也能挡住重复更新。回调接口还有一个容易被忽略的细节先校验请求签名再处理业务逻辑。第三方回调的签名校验必须放在最前面否则伪造的回调请求就能把订单改成已支付平台直接被薅羊毛。这一步绝不能省略。写在最后的几点实操心得课选学习平台这种项目真正难的不是某个技术点而是把一堆常规技术在一个真实的业务场景里稳定地组合起来。从我做的几个类似项目来看一个值得投入精力的地方是先理清楚业务状态流转再谈技术框架。比如订单状态从待支付到已支付再到已取消学习进度从未开始到学习中再到已完成这些状态机的定义直接决定了Service层代码的复杂度。另一个心得是监控要早做不要等到线上出问题才补。Spring Boot Admin和Micrometer这套东西一天就能搭完但它在你焦虑地排查线上问题时是那个最快的定位工具。如果后续要做扩展方向也很明确课程推荐算法、直播课堂、积分体系、移动端小程序。这些扩展在当前的模块化设计下都只需要在一个独立的垂直模块里开发不用动核心链路。这也是我坚持把系统拆分成独立模块的原因越到后期你对这种设计带来的好处体会越深。