你可能接过一个类似的需求做一个课程网站系统后端用 Java SpringBoot3前端用 Vue.js3数据库用 MySQL。听起来是一套非常经典的组合很多教程也按“Spring Boot 后端 Vue 前端 MySQL 存储”的方式一路讲下去好像只要把三个框架拼起来项目就能自然跑通。但真正进入开发之后你会发现最折磨人的往往不是某个框架不熟悉而是三端之间那些看不见的“边界”。前端拿不到想要的字段、后端报的日期格式对不上、数据库里的选课记录重复插入了、本地能跑但是部署到服务器后数据库连接不上……这些才是让一个课程网站开发进度停滞的主要原因。所以我对课程网站系统的核心判断是这个项目真正的难度不在 Java 代码也不在 Vue 组件而在于你如何设计业务模块、数据关系和前后端契约。只要这三件事在做第一行代码之前想清楚后面就是按部就班的实现如果这三件事不做后面每天都会在联调和返工中消耗时间。1. 先搞清楚课程网站系统的业务边界再写代码很多课程网站项目一开始就陷入“先建 Spring Boot 工程再搭 Vue 页面”的节奏里。这个顺序不能说错但很容易导致一个结果前端页面做了一堆后端接口却对不上真正的业务流程或者课程表里塞了很多字段却发现选课这个核心动作没有地方落库。1.1 从三类角色和两条业务主线开始梳理课程网站通常不是只有一个“看课页面”。只要你把系统拆开就会发现至少存在三类角色学生注册、登录、选课、学习课程、记录进度、做作业/考试。教师/讲师创建课程、管理课程章节与资料、查看选课学生、批改作业。管理员审核课程、管理用户、处理公告、查看统计报表。围绕这三类角色业务上有两条主线需要始终抓住课程发布与维护主线教师创建课程 → 编写章节 → 上传资料/视频 → 设置是否可免费试看 → 发布 → 管理员审核 → 学生可见。学生学习与选课主线学生浏览课程列表 → 查看课程详情 → 选课/报名 → 获得学习权限 → 记录学习进度 → 完成测试 → 获得成绩。很多新手写后端时只盯着“课程 CRUD”也就是课程表的增删改查结果把“选课关系”和“学习进度”当成边缘功能放到最后。实际上选课关系才是课程网站区别于普通内容管理系统的关键点。1.2 功能模块可以这样拆分如果你拿到的项目资料没有给出更细的功能清单可以参考下面这套通用模块划分方式作为起点模块用户端主要功能管理端主要功能用户模块注册、登录、个人资料用户列表、禁用/启用、角色分配课程模块课程列表、详情、检索创建课程、编辑章节、发布/下线选课模块选课、我的课程、取消选课查看选课名单、选课统计学习模块章节学习、进度记录查看进度、数据统计作业/考试模块在线答题、提交作业、查看成绩出题、批改、成绩管理内容/公告模块查看公告、通知发布公告拆完模块后你应该能回答一个问题我要不要做作业考试如果要考试结果表、答题记录表就会改变后端的数据模型如果不要就不要在课程表里预留一堆没用的字段。1.3 单体远优先不要一开始就上微服务课程网站系统用 SpringBoot3 Vue3 MySQL 的组合最常见的合理架构是单体应用也就是后端一个 Spring Boot 服务前端一个 Vue 单页应用数据库用 MySQL。不要因为工程目录里多放了几个模块就把项目拆成用户服务、课程服务、选课服务等微服务。课程网站的业务复杂度通常没有达到微服务的收益线如果强行拆分反而会带来服务间调用、分布式事务、接口鉴权联动等一大堆额外负担。在这个阶段更建议在后端用分层模块来保持边界controller 只负责接收参数和返回结果service 负责业务逻辑mapper 负责数据库访问。这种模块化比微服务更实际也更容易维护。2. Spring Boot 3 的坑不在业务代码而在版本迁移和接口契约Spring Boot 3 相对于 Spring Boot 2 有一批基础变化。如果你之前没有深入做过升级可能会在第一次启动时被各种“ClassNotFoundException”拦住。2.1 JDK 17 与 Jakarta 命名空间Spring Boot 3 的最低要求是 JDK 17。这不是让你把 pom.xml 里 Java version 改成 17 就行而是你本机的 JDK、Maven 编译器、IDE 都要对齐。另外Spring Boot 3 里最影响迁移的一点是原来的javax.servlet、javax.persistence等包名改成了jakarta.servlet、jakarta.persistence。这意味着网上很多 Spring Boot 2 的老代码不能直接复制过来。如果你在写登录拦截器、文件上传或 JPA 实体时看到“找不到 javax.servlet”大概率是版本迁移问题不是依赖缺失。具体用哪个 Spring Boot 3.x 小版本需要结合你的 JDK 和构建环境确认。不要在没有验证的情况下直接写死某个最新版本。2.2 从第一个接口开始就统一响应结构课程网站前后端分离后端不能把Map、Entity或null直接返回给前端。因为前端无法判断“返回了数据”和“请求失败”之间的区别。我一般会在后端定义一个统一响应结构。例如public record ResultT(int code, String message, T data) { public static T ResultT ok(T data) { return new Result(0, ok, data); } public static T ResultT fail(int code, String message) { return new Result(code, message, null); } }这里的code必须是全系统统一约定的业务状态码。比如 0 表示成功401 表示未登录403 表示无权限500 表示服务器异常。注意不要和 HTTP 状态码混为一谈。你可以让 HTTP 总是返回 200然后在业务体里用code区分也可以让 HTTP 状态码和业务状态码保持一致。关键是——后端和前端必须约定同一种规则不要一半接口返回 code一半接口直接抛异常给前端。2.3 Controller 层返回 DTO而不是数据库实体类课程网站里Course实体可能包含创建时间、更新时间、逻辑删除字段、教师的密码字段。如果直接把实体序列化返回给前端除了暴露不该暴露的信息还会让前端接到大量用不到的属性。合理做法是在 controller 和 service 之间使用 DTOData Transfer Object。例如课程详情页可以有一个CourseDetailDTO包含课程标题、封面、教师姓名、章节列表。这样接口的字段是稳定的即使后端表结构变化只要 DTO 不变前端就不需要跟着改。这样做会让前期代码量增加但到联调阶段收益非常大。否则你会在“前端要一个教师名称后端课程表里只有 teacherId”这种小事上反复沟通。2.4 事务不能乱加但写入流程必须加对于选课、创建课程、提交作业这些涉及多表写入的操作要用Transactional保证原子性。比如选课时既要往选课表插入记录又可能要更新课程的选课人数还要写入学习记录初始化数据。如果第二步失败而第一步成功用户就会遇到“显示没选上但数据库里已经有了记录”的脏数据。但也要注意事务不是越多越好。查询接口、单表插入、以及不需要多个写操作的场景没有必要加事务。长时间的 Transactional 会持有数据库连接影响并发处理能力。3. MySQL 表设计课程网站的核心是选课关系和学习记录数据库设计是课程网站最不能赶工的部分。很多表如果设计错了后面改起来会牵一发而动全身。3.1 先建用户、课程、选课三张核心表课程网站不是只有“课程表”一张表。至少需要这样一组表user用户表存放学生、教师、管理员。course课程表存放课程基本信息、所属教师、分类、上下架状态。course_selection选课关系表记录哪个学生选了哪门课。course_chapter课程章节表记录课程下有哪些章、哪些节、资源地址。learning_record学习记录表记录某个学生对某个章节的完成进度。一个简化的建表结构可以这样开始CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password_hash VARCHAR(100) NOT NULL, role TINYINT NOT NULL COMMENT 1-管理员 2-教师 3-学生, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, teacher_id BIGINT NOT NULL, category_id BIGINT, title VARCHAR(200) NOT NULL, cover_url VARCHAR(500), status TINYINT NOT NULL DEFAULT 0 COMMENT 0-草稿 1-已发布 2-下线, price DECIMAL(10,2) NOT NULL DEFAULT 0.00, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_teacher (teacher_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT课程表; CREATE TABLE course_selection ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, course_id BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_course (user_id, course_id), KEY idx_course (course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT选课关系表;这里要重点说明uk_user_course这个唯一约束。它的作用是同一个学生对同一门课不能重复选课。就算你的 Java 代码里做了“先查再插”的判断高并发下仍可能出现两请求同时查到不存在然后都插入成功。数据库唯一约束是最后一道防线。3.2 不要盲目使用物理外键很多课程设计里会在course_selection.user_id上设置外键关联到user.id。这在教学演示里没问题但在实际部署中物理外键会影响插入性能和删除灵活性。更常见的方式是只保留对应的业务字段用逻辑外键维护关联。也就是说Java 代码里通过 mapper 显式判断用户是否存在、课程是否存在而不是依靠数据库外键去约束。3.3 三个容易遗漏的字段status、sort_order、deleted课程表里建议加status用来控制草稿、发布、下线。前端列表只查已发布课程管理端可以查所有状态。课程章节表里建议加sort_order否则你很难控制“第一章、第二章”的排序。不要用创建时间排序来替代因为数据导入、批量编辑时创建时间可能相同。如果要做逻辑删除可以在表里加deleted字段。但要注意逻辑删除和唯一索引可能冲突。例如用户表中如果保留username唯一索引删除一个用户后同名的用户就无法再次注册。遇到这种情况要么用户名带上删除时间戳要么控制查询条件过滤deleted。3.4 学习进度不要直接塞在课程表里初学者常犯的另一个问题是把“学习人数”“课程进度”“最后学习时间”全部加到课程表。这在中后期会非常痛苦。更好的做法是单独建学习记录表例如CREATE TABLE learning_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, course_id BIGINT NOT NULL, chapter_id BIGINT NOT NULL, progress INT NOT NULL DEFAULT 0 COMMENT 0-100, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_chapter (user_id, chapter_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT学习记录表;这里用progress表示用户看到第几分钟或第几个知识点updated_at表示最近一次学习时间。展示“最近学习课程”时直接按updated_at倒序查即可。3.5 MySQL 环境配置注意点数据库连接时连接串里一般要指定编码和时区jdbc:mysql://localhost:3306/course_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueMySQL 8 默认字符集已经支持 utf8mb4但如果你在低版本 MySQL 上建表一定要在建库时指定DEFAULT CHARSETutf8mb4否则中文可能乱码。另外如果本地容器里使用 MySQL需要确认端口是否被占用、账户是否有远程访问权限以及服务器防火墙是否放行 3306 端口。很多“数据库连不上”的问题不是 Java 代码的问题而是 MySQL 服务没有启动或权限没有配好。4. Vue 3 Vite前端不只是页面组件还要管理好状态与请求Vue 3 提供的组合式 API 让组件逻辑比 Vue 2 时代清晰了不少但这不意味着前端部分只需要写.vue文件就行。课程网站是一个完整后台系统页面之间需要共享用户状态接口请求也需要统一处理。4.1 前端项目的最小推荐结构常见课程网站前端可以按功能拆成视图和公共模块src/ api/ course.js user.js selection.js assets/ components/ CourseCard.vue VideoPlayer.vue router/ index.js stores/ user.js views/ admin/ course/ user/ utils/ request.jsapi目录用来统一放置接口调用而不是在每个页面里直接写axios.get。stores用来放 Pinia 用户状态。utils/request.js封装 axios 实例和拦截器。这样做的好处是当接口地址变化或需要统一加 token 时你只需要改一个文件而不是满项目找请求代码。4.2 axios 拦截器要跟后端 Result 结构对齐我在前面强调过后端要统一返回体。到了前端axios 拦截器就要与这个结构对齐。一个常见的封装如下import axios from axios import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code 0) { return res.data } if (res.code 401) { router.push(/login) } return Promise.reject(new Error(res.message || 请求失败)) }, error { if (error.response error.response.status 401) { router.push(/login) } return Promise.reject(error) } ) export default request注意前端解析的code必须和后端Result里的code是同一个业务码。如果后端有的返回 0有的返回 200前端就不得不在每个页面里额外判断一次这会产生大量重复代码和漏判。4.3 路由守卫和角色权限课程网站的用户角色不同能看到的路由也不同。学生端看到“我的课程”教师端看到“课程管理”管理员端看到“用户管理”。可以给路由元信息加上角色要求{ path: /admin/courses, component: () import(/views/admin/CourseManage.vue), meta: { roles: [admin, teacher] } }然后在路由守卫里读取 Pinia 中保存的用户角色没有权限就跳转到 401 页或首页。这里要注意一点路由守卫只是前端体验的一部分真正的权限校验必须在后端接口完成。因为用户完全可以跳过前端路由直接手动调用接口。4.4 开发环境的跨域问题用代理解决课程网站前后端分离开发时最容易遇到的是跨域报错。最简单的方式不是在后端写复杂的 CORS 配置而是在 Vite 开发环境里配置代理// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端请求/api/course/list时Vite 会把请求转发到后端http://localhost:8080/api/course/list浏览器不会感知到跨域。后端可以暂不考虑 CORS等生产部署时再用 Nginx 做反向代理和同源转发。4.5 组件化拆分让课程展示更易维护课程列表页里如果每个页面都重复写课程卡片样式、价格标签、学习人数后续维护成本会很高。建议抽出CourseCard.vue接收课程对象只在内部展示信息。课程详情页再抽出ChapterList.vue、VideoPlayer.vue等更小粒度的组件。这样做还有一个好处后端返回的数据结构变化时你只需要在组件里做一次字段映射而不是在每个列表页改模板。5. 前后端联调比写代码更值得认真对待的是契约实际上课程网站系统大部分“卡住”的时间都发生在联调阶段。前端说“我把参数传过去了”后端说“我这边没收到”最后发现是字段名拼写不一致后端返回了LocalDateTime前端拿到后直接显示成2025-01-01T00:00:00这种带T的格式又得再处理一遍。5.1 接口定义要优先于代码实现不要等后端写完 Controller 再让前端去问接口结构。比较好的做法是团队先定义一份接口文档或者在项目中添加 OpenAPI/Swagger 依赖让后端启动后能生成接口文档前端再按文档联调。接口文档至少要写明请求路径和方法例如GET /api/courses请求参数是 query 参数、path 参数还是 JSON body返回结构字段名、类型、是否可空鉴权要求需不需要带 token分页规则page 从 0 还是 1 开始pageSize叫什么名字有些项目在接口文档上省时间最后在联调里花两三倍时间改代码。5.2 最容易出现不一致的五类问题类型常见问题建议日期时间LocalDateTime 序列化成 ISO 字符串后端统一配置yyyy-MM-dd HH:mm:ss前端不二次解析空值null 和空字符串混用约定 list 返回数组对象缺失返回 null不允许字符串表示空枚举/状态状态用 0/1/2前端不知道含义后端提供字典或接口注释前端不要硬编码魔法值分页参数page 从 1 开始还是从 0 开始全项目统一一个分页模型前后端保持一致错误码HTTP 200 但业务失败统一看Result.code不要在页面里逐个判断 HTTP status日期时间是最容易忽略的一环。Spring Boot 默认序列化LocalDateTime时会带上T如果不希望前端处理可以在配置文件中设置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai当然如果前后端都用时间戳也是一种约定。关键是不要一个项目里混用“字符串日期”和“时间戳”。5.3 先跑通一条主路径再覆盖分支功能联调时不要急着把所有接口都测一遍。课程网站系统可以先跑通这条主路径用户注册/登录。进入课程列表获取已发布课程。查看课程详情加载课程章节。学生选课此时课程出现在“我的课程”列表。打开某一章节上报学习进度。再刷新页面能够正确恢复进度。如果这条路能完整跑通说明用户、课程、选课、学习记录这四张核心表和对应接口已经工作可靠。然后你再去处理讲师上传、管理员审核、搜索过滤、分页排序这些外围功能就会轻松很多。5.4 排查问题要按层定位不要凭感觉改代码根据经验课程网站系统出现问题时大概率不会是框架本身的问题。更有效的排查顺序是先看请求到底发出去没有打开浏览器 Network看请求 URL、Method、请求头。再看请求参数是否符合后端期望字段名是否一致、参数是 JSON 还是 form、page 是否传了。看响应状态码404 先查路由和代理401/403 先查 token 和权限500 再看后端日志。看后端日志的异常栈是 SQL 报错、空指针还是参数转换出错。如果确认到数据库层再回 MySQL 手动执行 SQL验证表结构、数据、索引是否正常。不要一看到“跨域”就加一堆 CORS 配置先确认你是不是用了 Vite/Nginx 代理不要一看到“数据库连接失败”就怀疑 Spring Boot 配置先确认 MySQL 端口能不能连通。注意排查问题最忌讳跳过前几层直接改代码。你至少要能明确回答“请求到了哪一层”再动手修。6. 从“本地能跑”到“能够交付”补上工程化的最后几块拼图很多课程网站项目交上去时可以在本地 IDEA 里启动浏览器也能访问但换一台电脑或部署到服务器后就会出现各种问题。原因不是代码逻辑不对而是缺少工程化能力。6.1 本地环境与生产环境配置分离Spring Boot 项目里建议把数据库地址、Redis 地址、OSS 密钥放到不同 profile 的配置文件中application.yml application-dev.yml application-prod.yml开发环境连接本地数据库生产环境连接服务器数据库。密钥不要直接写在代码里。可以通过环境变量注入spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME} username: ${DB_USERNAME} password: ${DB_PASSWORD}这样做的好处是同一个 jar 包可以在不同环境下通过环境变量切换配置不需要重新打包。6.2 日志要能帮你还原问题现场课程网站上线后你不可能再靠 IDEA 控制台看日志。所以应用必须把日志写到文件里或者集中收集到日志平台。Spring Boot 默认使用 Logback你可以配置一个简单的滚动日志appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/course-system.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternlogs/course-system.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory30/maxHistory /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n/pattern /encoder /appender日志中至少应记录用户 ID、操作类型、请求路径、关键参数、异常摘要。但不要打印密码、完整的银行卡号等敏感信息。6.3 权限验证和数据安全要从后端做起课程网站的接口不能只靠前端隐藏按钮。学生在“我的课程”点击某个课程章节时后端必须判断这个学生是否真的选了这门课。你不能只依赖前端传来的课程 id就直接返回课程内容。后端的安全检查至少包括用户密码使用 BCrypt 加密存储不要用明文或 MD5。登录后使用 JWT 或 Session 保存登录态并设置过期时间。涉及资源访问时校验用户是否拥有该课程权限。管理端接口校验管理员角色不能只靠前端路由隐藏。越权漏洞是课程网站系统里最容易被忽略的问题。很多课程系统的权限只做了“登录后才能进入”但没有做“这个课程是否属于当前用户”。一旦被人绕过前端直接调接口就可能看到不属于自己的课程内容。6.4 部署方式可以简单但不能没有方案如果课程网站访问量不大一个最简部署方案可以是这样购买一台 Linux 服务器。服务器上安装 JDK 17、MySQL、Nginx。MySQL 创建数据库并导入表结构。后端打成 jar 包用java -jar启动。前端构建后把dist目录放到 Nginx 的 html 目录。Nginx 将/api请求转发到后端8080端口。如果以后需要环境隔离和快速重建可以使用 Docker Compose。一个最简的 compose 结构可以是services: mysql: image: mysql:8.0 restart: always environment: MYSQL_ROOT_PASSWORD: yourpassword MYSQL_DATABASE: course_system volumes: - ./mysql_data:/var/lib/mysql ports: - 3306:3306 backend: build: ./backend restart: always environment: SPRING_PROFILES_ACTIVE: prod DB_HOST: mysql DB_NAME: course_system DB_USERNAME: root DB_PASSWORD: yourpassword depends_on: - mysql frontend: build: ./frontend restart: always ports: - 80:80 depends_on: - backend这套方案依然属于中小规模课程网站。如果是面向全校、几千人同时在线并且包含大量视频播放那就需要把视频放到对象存储或 CDN 上将视频播放流量从应用服务器中剥离。Spring Boot 单体服务只负责业务接口不要再把视频文件放到本地磁盘或 MySQL 的 BLOB 字段里。6.5 课程网站系统真正的长期成本做课程网站开发只是第一步。课程内容会持续更新选课记录会不断增长用户角色会越来越多。长期维护时你会被这几类事情反复消耗责任划分。提前规划会好很多。另外一个很重要但容易被忽视的维度是是否真的要收费、是否要退课、是否要并发抢课。如果业务规则里没有明确提到就先用最简单版本如果以后需要再增加订单表和退款状态机。建议不要在第一版把所有可能性都提前做进表结构。尽量按照“最小可上线”来设计真正需要时再通过数据库迁移加表、加字段。先把主流程做稳定比堆功能更值得投入。课程网站系统不是你用了 SpringBoot3、Vue3、MySQL 就会自动成功。它能否顺利交付取决于你如何在项目早期把选课关系、接口结构、状态码、权限边界这些底层的“游戏规则”都定清楚。下一次刚接到课程网站项目时不要急着启动 IDE。先画一张角色和模块图列一份接口清单写出一版建表 SQL再开始敲代码。你会发现后面 80% 的联调问题都能提前消失。