企业官网建设流程全解析

又到一年毕业设计选题季，在线教育系统几乎是Java方向每年都会出现的“常青树”选题。我这两年带过不少做这个题目的同学，自己也完整地把它从零到一写过一遍：基于SSM框架的在线教育系统，前台是课程展示、登录注册、选课下单，后台是用户管理、课程维护、订单统计。这套东西能解决的问题非常具体——它把用户、课程、订单、学习记录这些核心业务串成了一条完整链路，特别适合用来体现你对Spring、SpringMVC、MyBatis这套主流Java Web技术的掌握程度。

这篇内容，我打算完全站在“过来人”的角度来讲：这个系统到底该做哪些模块、数据库表怎么设计、代码分层怎么组织、哪些坑是十个项目里有九个都会踩的。适合谁看？准备做这个选题的应届毕业生、刚入门想找项目练手的Java学习者，还有那些正在帮学生选型、过方案的老师。我会把能直接抄作业的配置、表结构和常见问题排查都放出来，尽量让你少走弯路。

1. 需求拆解与技术选型：这个题目为什么能做、该做到什么程度

1.1 在线教育题目背后的“考察点”

选毕设题目其实有个隐藏逻辑：老师看的不是“多炫酷”，而是“能不能把学过的东西串起来”。在线教育系统在这一点上非常占便宜。它的业务闭环足够完整：用户注册登录后可以浏览课程，选择课程后生成订单，订单支付后就能观看课程视频，看完之后可以留言评价。整个过程天然包含用户、课程、订单、评论四类核心实体，能考察出一张数据库表设计得好不好，也能考察出事务、拦截器、关联查询这些常用技术点。

很多同学一看到“在线教育”就想着做直播、做推荐算法、做自动批卷，我劝你先冷静。毕设的时间、精力、答辩难度都是有限的，核心看的是稳定性和完整度。你完全可以把范围收敛成“录播课程 + 后台管理 + 订单流程”这个主线，先把闭环跑通，再去想花活。我见过太多人一开始就把架构铺得特别大，最后交付的时候连订单流程都是写死的假数据，这种反而容易被老师一问就露馅。

一个合格的在线教育毕设，我建议至少包含这样几块核心功能：

• 前台：注册登录、课程分类、课程列表与详情、加入学习、课程评论、个人中心
• 后台：课程管理、章节管理、视频地址维护、订单管理、用户管理、公告管理
• 公共能力：图片上传、分页查询、登录状态拦截、角色权限区分

这套功能做完，技术考察点基本全覆盖，答辩的时候也能讲清楚“每个功能背后的原理是什么”。

1.2 SSM框架为什么依然值得选

现在市面上Spring Boot已经成了主流，很多同学纠结：既然Boot更简单，为什么毕设还写SSM？如果你的题目明确写了“基于SSM”，那答案很简单——按题目来。SSM本身并没有过时，它在“理解框架原理”这件事上反而更有教学价值：Spring的IoC和AOP在SSM里需要显式写配置，SpringMVC的请求流转过程在SSM里能一行一行看到，MyBatis的SqlSession和Mapper代理机制在SSM里也暴露得更清楚。

说句实在话，用SSM做毕设，工作量确实比Spring Boot大一点，但这也同时意味着“可讲的东西”变多了。答辩老师问你“Spring Boot自动配置做了什么”，你可能答不清；但问他“SpringMVC从请求进来到返回视图经历了什么”，只要是老老实实写着SSM的同学基本都能说出HandlerMapping、Controller、ViewResolver这条链路。框架用的老一点没关系，原理吃透了反而更稳。

至于为什么不用Servlet原生开发？也不是不行，只是到了大四这个阶段，Servlet做CRUD已经很难体现工程能力了。SSM的定位正好是“工程化但不失原理”，它让你多了配置文件、事务切面、动态代理这些可说的点，又不至于像Spring Boot那样自动到你无话可讲。

1.3 功能边界要敢于“做减法”

很多同学的毕设需求分析写满了三页纸，实际做出来的系统才五个页面。这种落差往往不是因为懒惰，而是因为一开始就没分清“必须做”和“值得做”。

在我这儿，一个能顺利通过答辩的在线教育系统，功能表是这样收敛的：

这张表背后的原则是：每个功能要做到闭环，而不是数量堆叠。比如支付这块，“模拟支付”就够了——你创建订单后点一个“确认支付”，把它当作用户模拟支付成功的动作，订单状态从待支付变成已完成，流程就完整了。对接真实支付通道既涉及资质，也牵扯到答辩现场没法演示的问题，没必要。

2. 数据库设计：先把表结构想清楚，代码才有地方放

2.1 核心数据表与字段设计

在线教育系统的表设计没有太多玄学，关键是要围绕“用户 - 课程 - 订单”这条业务线把关系理清。我用的表结构清单如下，基本是毕设项目的标准版本：

• user：用户表。字段包含主键、用户名、密码、昵称、手机号、头像、角色、注册时间。
• category：课程分类表。主键、分类名称、排序、状态。
• course：课程表。主键、课程名称、封面图、简介、价格、教师ID、分类ID、状态、创建时间。
• section：课程章节表。主键、课程ID、章节标题、排序。
• video：课程视频表。主键、章节ID、视频标题、视频地址、时长、排序。
• course_order：订单表。主键、订单编号、用户ID、课程ID、支付金额、订单状态、支付时间、创建时间。
• comment：评论表。主键、用户ID、课程ID、评论内容、评分、创建时间。
• notice：公告表。主键、标题、内容、创建时间。

下面我把字段细节用表格展示一下，这张表你直接给导师看也没有问题：

2.2 关键设计思路：订单状态、外键与索引

订单表单独建表是这类系统的传统做法，因为订单不能直接写在课程表上——一个用户买多门课，一门课被多个用户买，这是典型的多对多关系。用订单表把这种关系拆开之后，后面的对账、统计、权限判断都会清晰很多。我在订单表里专门放了order_no唯一编号，目的就是模拟真实订单的不可重复性，答辩时老师如果问“怎么避免重复下单”，你可以回答“在生成订单前先查用户和课程是否存在有效订单”，这一句话就能体现出你对业务细节的思考。

外键这里我建议加上。虽然很多互联网项目为了扩展性会刻意去掉外键，但作为毕设，你没有那么高的并发诉求，外键反而能保证数据的完整性，防止出现“订单指向一个已删除课程”这种脏数据。加外键还有一个实际好处：MyBatis做联表查询的时候，IDE和外键约束都能帮你验证模型设计得对不对。

索引不需要建太多，但要建在“查询频繁的字段”上：比如订单表的user_id、课程表的category_id和status。我见过有人在每个字段上都加索引，结果是插入变慢、没什么实际意义。建索引的原则是：哪些字段出现在where和order by里，就优先给哪些字段建。

2.3 预置数据的重要性

毕设跟真实项目最大的区别是：毕设要给人“演示”。而演示最忌讳的就是现场录数据。我强烈建议你在写完建表SQL之后，就跟着写一份初始化数据SQL，至少包含：

• 1个管理员账号：admin / 123456
• 1个教师账号：teacher / 123456
• 1个学生账号：student / 123456
• 3到5个课程分类：比如Java开发、前端开发、数据库
• 每类下2门课程，课程里挂上章节和视频地址
• 几条订单记录和评论记录

密码这里要提醒一下，千万不要明文存储。你用MD5加盐的方式把密码存进去，初始化数据也要先算好加密后的值再插入。我在开发中就遇到过同学图省事直接写入明文，结果登录模块的逻辑校验根本对不上，查了半天才发现是数据问题。这个问题放到下一节详细讲。

3. 工程搭建与核心功能实现：从配置文件到业务闭环

3.1 环境版本与工程结构

做SSM老项目，环境版本别乱选。我推荐一套经过大量验证的组合：

工程结构建议用标准的Maven Web项目，按包名划分好责任边界：

• controller：接收请求，调用service，返回视图或数据
• service：业务逻辑，事务边界在这里控制
• mapper：MyBatis的Mapper接口
• entity：实体类，对应数据表
• common：工具类、常量、统一返回结果

这套结构的好处是“一句话就能讲清楚架构”：控制层只负责接收参数，业务层只做逻辑，数据层只做SQL。对毕设答辩来说，清晰比“高级”更重要。

3.2 核心配置文件与MyBatis整合

SSM整合最容易出问题的地方，就是Spring和SpringMVC两份容器配置职责不清。我的做法是严格遵循一条原则：Spring容器管哪些内容，SpringMVC容器管哪些内容，必须分开。

• applicationContext.xml：扫描service和mapper，配置数据源、事务管理。
• spring-mvc.xml：扫描controller，配置视图解析器、静态资源放行、文件上传解析器。
• web.xml：配置ContextLoaderListener、DispatcherServlet、字符编码过滤器。

下面这段是我的Spring配置骨架，很多同学卡在“Mapper扫描不到”上，就是因为少了MapperScannerConfigurer这一节：

<context:component-scan base-package="com.example.service" /> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.example.mapper"/> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/> </bean>

MyBatis这边我用的是XML映射文件。原因很朴素：毕业设计的SQL稍微复杂一点，比如按条件分页统计，在XML里维护要比注解拼接字符串清晰得多。动态SQL就是MyBatis最值钱的东西，搜索课程这个功能我基本是靠一个动态where搞定的：

<select id="searchCourse" resultType="com.example.entity.Course"> SELECT * FROM course <where> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> AND status = 1 </where> </select>

3.3 登录鉴权、拦截器与角色控制

登录状态控制我用了SpringMVC的HandlerInterceptor。写一个LoginInterceptor，重写preHandle方法：判断session里有没有用户信息，没有就跳回登录页，有就放行。需要注意的细节是配置拦截器时要“排除登录页、注册页、课程展示页”，否则用户没登录连课程列表都看不了，这就违背了电商类系统“游客也能逛”的常规习惯。

角色控制在鉴权之上再加一层判断。管理员能访问/admin/**的后台管理页面，普通学生只能访问前台。我见过两种实现方式：第一种是在拦截器里判断角色字段；第二种是写一个简单的权限注解配合AOP。毕设用第一种就够了，代码少、容易解释。答辩时老师更关心的是“你能不能说明白为什么学生不能访问后台”，而不是你的权限框架多复杂。

关于密码处理，我再强调一次：不能明文存，也不能只做普通MD5。最少最少也要“MD5（明文 + 固定盐）”，比如把盐设计成用户名，这样即使两个用户密码相同，存储的密文也不同。生成的方式可以用工具类封装一层，Controller层注册时调用加密方法，登录时再同样加密比对。

3.4 选课下单流程：事务与状态流转

这套系统里最有技术含量的功能，其实是选课下单。我的流程这样设计：

1. 用户点击“加入学习”，Controller先判断是否登录。
2. 查询课程，把课程信息放到订单确认页。
3. 用户点击“确认支付”，Service层创建订单，状态为“已支付”。
4. 订单创建成功后跳转到“学习中心”，用户可以在该课程下看到所有章节和视频。

事务要放在Service层，方法上加@Transactional。为什么事务在这一步特别重要？因为创建订单这个动作如果只插入了一条订单记录，看起来并不需要事务，但如果你后续要同时更新课程的选课人数、清理购物车里的临时数据，这些操作就属于多个写操作。任何一步失败，都应该整体回滚，否则用户付了钱，课程状态没更新，对账就会出问题。

订单状态我这里设计成三态：

• 0：待支付
• 1：已支付
• 2：已取消

学到的一个实用技巧是：支付动作不要在Controller里直接改数据库，而是用一个OrderService.pay(orderId)方法把状态流转封装起来。这样后面即使你要加“支付回调”，也是在这个方法上做扩展，而不是把逻辑散落得到处都是。

视频播放这块，因为走的是录播课方向，我直接在前台用HTML5的video标签播放video表里存好的URL。视频文件本身不往数据库里放二进制，只存地址。毕设里用本地静态路径或者测试地址都行，关键是要提前准备好一个格式兼容的测试视频，MP4格式最稳。

3.5 文件上传与图片处理的细节

课程封面图上传是我遇到的另一个高频坑。SpringMVC里配置CommonsMultipartResolver不复杂，但真正容易翻车的是“文件上传到哪、上传后怎么访问”。

我的做法是在项目根目录建一个upload文件夹，配置成Tomcat可访问的静态路径。注意Windows和Linux的路径分隔符处理，界面上回显图片时，数据库里存的是相对路径，页面拼接的时候要用动态上下文，而不是硬编码localhost:8080——不然部署到别的机器上图片就全裂了。

上传文件校验也要提前做：限制后缀名（jpg、png、gif）、限制大小。很多同学文件类型校验只判断后缀，实际生产不够用，但对毕设已经够了，重点在于老师问的时候你能说出“我在上传前做了类型和大小双重校验”这句话。

4. 前端页面与交互细节：看起来像完整产品的关键

4.1 页面框架与复用方法

很多非科班出身的同学最怕写前端，实际上在线教育系统的前端难度并不高。我用的方案是：JSP页面 + Bootstrap 4 + JQuery。选择JSP不是因为技术老，而是因为和SpringMVC的视图解析器天然契合，不需要额外做跨域配置，也不用把返回JSON再从JS里拼页面，对毕设来说开发效率最高。

页面骨架我建议抽成公共文件：顶部导航、页脚、后台侧边栏，都用JSP的include指令抽出来。修改一次，全站生效。这个细节在代码审查时很加分，因为说明你懂得“复用”而不只是堆页面。

课程列表页用Bootstrap的卡片栅格布局，手机端能自适应。详情页用两栏布局，左边是视频播放区域，右边是课程章节列表和介绍。后台页面用简单的上下布局加左侧菜单，表格用Bootstrap Table类直接美化三角号，分页条用JQuery拼一个简易分页组件就够了。

4.2 分页搜索与状态联动

列表页必须做分页。做毕设之前很多人以为分页就是数据库查出来再截取，其实正经做法是“每次只查当前页的数据”。MyBatis里的做法是先用LIMIT offset, pageSize把SQL写出来，再单独写一条count查询获取总记录数。

如果你不想手动算offset，可以使用PageHelper。PageHelper用起来确实方便，PageHelper.startPage(pageNum, pageSize)之后执行普通查询，返回结果会被自动分页。但要注意一点：PageHelper是线程本地的，同一个线程里如果连续查询多条SQL，第二、第三条可能会被意外分页。解决办法是每次startPage后紧接着执行你要分页的那一条查询，不要中间夹其它SQL。

搜索和分类筛选也要做成“带参数分页”。搜索时把关键词放在请求参数里，翻页时携带并回显。这一步如果处理不好，经常会出现“点击第二页，搜索结果就变回全部课程”的问题。我在Controller里用一个查询参数对象接收分页参数和关键字字段，然后整体传给Service，这样搜索条件就不会丢。

4.3 后台管理的交互细节

后台管理界面的交互细节，决定了这个项目“像不像成品”。至少要做到：

• 课程上下架状态在列表里能直接点击切换，而不是只能靠编辑页面改状态。
• 订单列表按照时间倒序，并让待支付和已支付用不同样式标识。
• 删除操作要弹确认框，不能点了就没了。
• 后台表单要做基础校验：必填项、价格必须大于0、简介长度限制。

这些交互看起来细碎，却是我认为毕设拿高分的“性价比之王”。因为评审老师通常不会把所有代码逐行看完，但一定会在演示的时候点点按钮、翻翻页面。交互细节顺滑，整体印象分就会明显提升。

表单校验推荐用JQuery Validate插件，前端即时提示。后端Controller里再简单判断一次必填参数，两边都做，答辩才能说“前后端双重校验”。

5. 常见故障与排查实录：每个坑都是踩出来的

5.1 环境与部署：Artifacts、依赖冲突和版本

用IDEA跑SSM项目，最经典的问题是Tomcat启动成功但404，或者IDEA里根本没有“部署”标签。这通常是因为创建项目时没有选择Web骨架，或者没有正确生成Web Artifact。解决方式是在Project Structure里找到Artifacts，添加Web Application: Exploded，再把它关联到Tomcat的Deployment。

另一个高频问题是Maven依赖版本冲突。典型场景是Spring各模块版本不一致，导致启动时报NoSuchMethodError。我的处理经验是：统一用Spring 5.1.x版本，SpringMVC、Spring-jdbc、Spring-tx全部使用同一个版本号，不要分开写。如果你用的连接池是Druid，还要检查Druid的版本和MySQL驱动版本是否匹配。

MySQL驱动这块特别提醒一下：MySQL 8.x需要驱动com.mysql.cj.jdbc.Driver，并且URL里要加时区参数serverTimezone=GMT%2B8，否则连数据库就报时区错误。

5.2 中文乱码：一条龙配置检查

中文乱码是SSM项目里最折磨人的问题，但它通常不是单一原因，而是“请求、响应、数据库、页面”四层中某一层出了问题。

• 页面乱码：JSP文件头部设置<%@ page contentType="text/html;charset=UTF-8" language="java" %>。
• 请求乱码：web.xml里配置CharacterEncodingFilter，encoding=UTF-8，并设置forceEncoding=true。
• 数据库乱码：建库时指定CREATE DATABASE xxx DEFAULT CHARACTER SET utf8mb4，连接URL加characterEncoding=utf8。
• 返回JSON乱码：SpringMVC的RequestMapping上加produces="application/json;charset=UTF-8"。

一个通用排查思路是：先在浏览器F12里看响应头有没有charset=utf-8，再用数据库客户端查看存的字段是否正常，从而缩小范围。千万不要只看页面说乱码就开始乱改，要定位到是哪一层断的。

5.3 MyBatis与SpringMVC的经典问题

Mapper扫描不到的问题，我遇到太多次了。最常见的原因是：@MapperScan注解没加，或者XML文件没有放在Mapper接口对应的路径下，导致启动报Invalid bound statement。简单粗暴的方法是在applicationContext.xml里配置MapperScannerConfigurer，同时检查resources目录下有没有把mapper/*.xml包含进来。

Spring声明式事务失效的问题也很经典。如果你用@Transactional修饰了一个Service方法，但在同一个类内部直接调用另一个带事务的方法，事务是不生效的。因为Spring的事务基于动态代理，内部调用走的是this本类，没有经过代理对象。规范的做法是：一个事务方法放在一个Service实现类里，外部Controller调用它，不要把事务方法自调用。

静态资源被DispatcherServlet拦截的问题同样高频。SpringMVC默认会拦截所有请求，如果你没有放行CSS、JS、图片，页面就会干干净净。解决方式是在spring-mvc.xml里增加：

<mvc:annotation-driven /> <mvc:default-servlet-handler />

这个配置的意思是：请求先被SpringMVC处理器匹配，匹配不到的交由Tomcat默认Servlet兜底处理静态资源。加上之后前端样式再也不会莫名消失。

5.4 答辩演示时容易翻车的细节

辛辛苦苦写完系统，答辩演示时翻车是最亏的。我这里列几个我亲眼见过的现场事故和预防方式：

• 现场网络不好，视频播放卡顿：提前把视频文件下载到本机，用本地地址播放，不要赌教室的网络。
• 刷新页面后登录状态丢失：检查Session超时时间，并确认拦截器放行了自己需要展示的页面路径。
• 后台新增课程后图片不显示：多半是上传的绝对路径里带了你本机的盘符路径。保存时只存相对路径，页面用contextPath拼接。
• 数据库连不上：确认MySQL服务和端口是通的，连接URL里的数据库名和实际一致。这一段建议写成一个演示清单，答辩前从头到尾点一遍。

根据我自己的习惯，演到“下单”这个功能前，一定会先把已有的订单清空几条，然后重新走一遍：登录、选课、确认订单、模拟支付、在我的课程里看到视频。整个流程一气呵成，老师的注意力会被吸引到业务闭环上，而不是纠结某个细节为什么没通。

最后再分享一个小技巧：这个项目做完之后，别急着删数据库的初始化脚本。把建表SQL、初始化数据SQL、完整配置说明都整理成一个开发文档，放到项目里。这既是答辩时的加分材料，也是以后自己回顾项目时最省心的资料。在线教育系统这个题目本身并不难，难的是把每个环节做得干净、完整、能讲出理由。你按照用户、课程、订单这条主线把数据库设计清楚，再按SSM分层把代码组织好，答辩时心态放平，老师问什么你都能从分层设计、事务控制、状态流转这几个角度回答上来，这个项目就算真正拿捏住了。