企业官网建设流程全解析

每年到毕设选题季，SSM + Java + 某个主题 + 源码 + 论文这个组合几乎成了默认配置。很多同学拿着差不多的题目来问我：2026年还做SSM，会不会被答辩老师质疑“技术太老”？我的看法是，SSM本身从来不是问题，问题是你有没有把一个具体领域做透。这篇文章就以一个我非常看好的选题为例——基于SSM的青少年公共卫生教育平台，把从选题逻辑、数据库设计、核心功能实现、论文写作到避坑技巧的整个流程完整拆一遍。你如果正在选毕业设计题目，或者已经选了这个题但不知道从哪里下手，这篇可以直接当作落地参考。

1. 选题逻辑：为什么公共卫生教育平台适合做毕设

1.1 课题价值怎么向老师讲

毕业设计选题一向存在“既要安全又要出彩”的矛盾：太偏纯技术的题目容易缺乏业务深度，太业务化的题目又撑不起技术工作量。青少年公共卫生教育平台是少见的“两头都占”的题目。

背景上，青少年近视率、龋齿率、心理健康问题这几年受到的关注度越来越高，校园传染病防控、急救知识普及也是持续存在的现实需求。把这些内容数字化、常态化，比做一个泛泛的“资讯网站”有价值得多。从功能层面看，这类平台天然需要“用户管理→健康知识管理→在线学习→趣味测验→答题统计→健康建议”这样一个闭环业务，每个环节都能对应到SSM框架的一项核心能力，论文展开很容易，演示效果也很好。

作为毕设，它的角色设计也非常清晰：管理员负责发布健康知识、维护题库、查看数据；学生可以浏览内容、参加测验、查看个人报告；教师或校医可以查看班级整体学习情况。三个角色互相配合，整个系统的功能边界和工作量都很好控制，不会像电商平台那样陷入无穷尽的业务分支。对于需要在一学期内完成的毕设来说，这种“边界清楚、闭环完整”的选题是最理想的。

1.2 2026年还选SSM，到底值不值

我理解大家的顾虑：SpringBoot已经成了行业主流，毕业设计再用SSM，总担心被说“过时”。但这个问题要分两层看。

第一层，大多数高校的Java课程主线还是Spring、SpringMVC、MyBatis这三件套。答辩老师对SSM项目最熟悉，也最容易判断工作量和技术重点。你选择一个老师熟悉的框架，反而降低了答辩被问爆的风险，因为老师能清晰看到你“学会了什么”。第二层，SSM的三层分离原则和SpringBoot一脉相承。你在SSM里理解了IoC容器、AOP、DispatcherServlet的请求流转，迁移到SpringBoot基本是两三天的事。

所以我的结论是：2026年做SSM完全可行，但要在论述时把“为什么不用SpringBoot”这个问题准备好。标准答案是：课程体系围绕SSM展开，通过SSM能更直观地理解MVC分层和持久层映射的底层机制；同时项目的前后端交互方式也为后续迁移到SpringBoot保留了扩展能力。这个回答既展示了思考深度，又不会否定SpringBoot的主流地位，老师一般会满意。

1.3 技术储备与工作量评估

动手之前先对照检查一下自己的技术储备，别做到一半才发现某项基础技能是空缺。

时间规划上，我建议留出3到4个月。第1个月搭好项目骨架，完成所有表的增删改查；第2个月集中处理随机组卷、自动评分、成绩统计这些核心模块；第3个月做前端页面、前后端联调，并同步开始写论文初稿；第4个月用来测试、修Bug、录演示视频和打磨答辩PPT。这个节奏能保证最后一个月还有缓冲时间应对突发问题。

2. 整体架构与数据库设计

2.1 技术架构与分包策略

这个项目的经典架构就是标准的SSM三层：Controller接收请求、返回视图或JSON，Service处理业务逻辑并管理事务，DAO负责MyBatis的数据访问。为了避免代码越写越乱，包结构建议这样划分：

• cn.edu.project.controller：按角色拆，AdminController、StudentController
• cn.edu.project.service：UserService、ExamService、KnowledgeService
• cn.edu.project.dao：对应的Mapper接口
• cn.edu.project.entity：数据库实体类
• cn.edu.project.common：统一返回类Result、常量、工具类
• cn.edu.project.interceptor：登录拦截器、角色拦截器
• cn.edu.project.config：Spring配置文件与JavaConfig

前端方案有两条路线。一条是JSP + JSTL的传统方式，页面直接用JSP渲染，Session和模型数据直接用，工作量最小，也最贴近教程样板。另一条是SSM后端只返回JSON，前端用Vue或纯HTML页面渲染，项目看起来有“前后端分离”的质感，论文里也多个技术亮点。

我的建议是：只求稳过答辩且时间紧张，选JSP方案；想让项目之后能写进简历，选“后端JSON + 前端页面”的方案。两条路线的后端代码高度重合，Controller返回方式不同而已，项目中期切换也不会有太大代价。

2.2 核心数据表设计详解

数据库是项目的“地基”，这次我按业务场景拆成六个部分来讲。

第一，用户与档案。user表保存登录信息，字段包括id、username、password、role、status、create_time。student_profile表保存学生的学号、姓名、性别、年级、班级、身高、体重、视力、过敏史等信息，为个人健康档案和后续统计做准备。

第二，内容管理。health_knowledge表保存健康知识文章，字段包括id、title、category、content、cover_img、read_count、status、publish_time。category建议用分类字典，包括饮食营养、传染病防控、心理健康、急救技能、口腔卫生、近视防控这几类，覆盖青少年常见的健康需求。

第三，题库。question表字段包括id、knowledge_id、question_type（单选/多选/判断）、stem、options_json、answer、analysis、difficulty、category。options_json用JSON字符串存储选项，比固定四个选项字段灵活得多，解析也简单。

第四，答题业务。exam_paper表保存试卷基本信息；exam_record表记录学生每次考试的开始时间、交卷时间、得分和状态；answer_record表逐题保存学生答案与正确答案的比对结果。这三张表是整个答题模块的核心，对数据一致性要求最高。

第五，学习行为。study_log记录学生每次浏览文章或学习视频的时长，不仅能反映平台真实使用情况，也给统计模块提供了关键的数据源。

第六，反馈与公告。feedback表存学生提问，notice表存平台公告，两个表结构简单，按常规设计即可。

2.3 建表时的几个关键细节

很多同学的数据库表字段看着挺全，一遇到复杂查询就后悔。我总结出三条经验：

其一，所有核心表必须带create_time字段，datetime类型，默认值用CURRENT_TIMESTAMP。以后要做“近一个月新增用户数”“每日活跃人数”这类统计，没有创建时间字段基本无从查起。

其二，删除用逻辑删除而非物理删除。给需要留痕的表加deleted字段，默认0，删除操作改成UPDATE，避免误删之后数据彻底找不回来，也让统计口径更一致。

其三，高频查询字段要建索引。比如exam_record表的student_id字段、knowledge表的category字段。数据量几百条时间还不明显，题库上万条之后再跑无索引查询，页面响应时间会有明显感知。

与答题业务最直接相关的exam_record表，我的设计是这样：

CREATE TABLE exam_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, paper_id BIGINT NOT NULL, start_time DATETIME NOT NULL, submit_time DATETIME NULL, score INT NULL, status TINYINT DEFAULT 0, UNIQUE KEY uk_student_paper (student_id, paper_id), KEY idx_student_id (student_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

唯一键uk_student_paper是这个表最关键的设计，它从数据库层面兜底防止同一位学生对同一张试卷重复提交。这个细节在答辩时可以专门讲，老师一听就知道你考虑过并发和重复请求的问题。

3. 核心功能模块与实现细节

3.1 登录认证与权限拦截

这个项目涉及管理员、学生两类角色，我没有引入Spring Security，而是用SpringMVC拦截器实现认证与权限控制。理由很简单：毕设场景用拦截器完全够用，代码量更小、运行逻辑一目了然，答辩时还更容易把原理讲透彻。

实现逻辑是这样：登录成功之后，把用户对象放进Session。写一个LoginInterceptor，在preHandle方法里检查Session是否为空，为空就重定向到登录页。管理员接口再配一个AdminInterceptor，检查Session里用户角色是否等于管理员，不通过就返回403页面。

拦截器注册代码大约是这样：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/captcha", "/static/**", "/error"); registry.addInterceptor(new AdminInterceptor()) .addPathPatterns("/admin/**"); } }

注意：密码千万别存明文，也不要用简单的可逆加密。我的习惯是MD5加固定盐，虽然MD5在现代安全标准下不算强哈希，但对毕设场景足够，关键是答辩时能说清楚“密码不是明文入库”。想更稳妥，用BCrypt也行，只是要多引一个依赖。

相对Session方案，也有人会问为什么不直接用JWT。我的回答是：这个平台是传统的服务端渲染页面，Session天然有效，实现简单还能被拦截器统一管理；JWT更适合前后端完全分离的API场景。两种方案没有绝对优劣，关键是能说清为什么选你用的那套。

3.2 随机组卷与自动评分

在线健康知识测验是平台的“门面功能”，也是工作量最大的模块。题库按单选、多选、判断三种题型设计，每道题带难度等级。组卷时按分类和难度随机抽取题目，组成一张新试卷。

随机组卷的实现可以直接借助MyBatis动态SQL：

<select id="selectRandomQuestions" resultType="cn.edu.project.entity.Question"> SELECT * FROM question WHERE category = #{category} AND difficulty = #{difficulty} ORDER BY RAND() LIMIT #{limit} </select>

ORDER BY RAND()在题库几千条时完全没问题，到上万条以上性能会退化，但这个点可以写进论文的“优化方向”里，还能体现你注意到了性能边界。

评分逻辑按题型区分：单选和判断题直接比较答案字符串；多选题要求所选选项完全一致才算对，部分选对不给分。前端提交答案列表后，后端遍历每道题，逐题比对得分，整个过程放在一个事务方法中处理，同时写入考试记录、答题明细和总分。这里用@Transactional注解管理事务，可以避免“写入一半，异常中断，考试记录和答题明细对不上”的严重问题。

3.3 内容管理与数据统计

管理员端的内容管理本质就是标准CRUD：列表查询、新增、编辑、删除、图片上传。需要注意两个点：图片上传后要返回可访问的完整URL，在表单回显时直接用这个URL；删除文章时记得把封面文件也清理掉，防止服务器上堆积大量无用文件。

数据统计这块，很多同学只会显示“文章阅读次数”，其实稍微多做一步就能明显提升项目观感。我建议用ECharts做两张图：一张按知识分类统计访问量的柱状图，一张按年级统计参与测验人数的饼图。数据来源是SQL聚合查询：

SELECT k.category, COUNT(*) AS cnt FROM study_log l JOIN health_knowledge k ON l.knowledge_id = k.id GROUP BY k.category;

后端返回聚合结果的JSON，前端页面初始化时加载一次，渲染成图表。这一部分视觉效果好，论文截图漂亮，答辩时也很容易把“平台价值”讲清楚。

4. 实操：从零搭建项目的关键步骤

4.1 开发环境版本对照

SSM项目启动不起来，十有八九是JDK、Spring、Tomcat的版本配错了。我实测下来最稳定的一套组合是这样的：

如果你的电脑装的是JDK17，那么Spring至少用5.3以上、Tomcat换到9.x。不要把版本拉得太新，很多老教程在JDK17下会踩到模块访问限制的坑，排查起来非常折磨人，没必要给自己增加这种难度。

4.2 Maven依赖与核心配置

pom.xml里的核心依赖大致是下面这个清单：

<dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.3.39</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.16</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.1.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.23</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.34</version> <scope>provided</scope> </dependency> </dependencies>

有几个细节要提醒大家：mysql-connector-java这个坐标在新版本里改了groupId，如果拉取失败，检查一下仓库地址；Lombok的版本必须和JDK匹配，JDK11以上就尽量用1.18.30之后的版本，否则编译期报错很头疼。

Spring的配置我习惯用JavaConfig和XML混合，但授课老师有明确要求就用XML。spring-mvc.xml里主要配置组件扫描、视图解析器、注解驱动和静态资源放行。推荐直接沿用下载源码里的配置文件自己动手改，因为手写容易漏掉annotation-driven或者乱码过滤器。

4.3 初始化数据库与测试数据

项目源码里我一般会附带一份init.sql，除了建表语句之外，还包括管理员账号、几十篇健康知识文章、两百道左右的测试题和少量学生测试账号。测试数据的重要性常常被低估：没有数据的后台列表是空白的，页面截图很难看，联调也测不出真实效果。

造题库数据有个小技巧：用Excel辅助拼SQL。把题干、选项、答案、解析整理在Excel里，用公式拼出INSERT语句，粘到SQL文件里批量执行。这样手工造两百道题大概半小时就完成了，比在数据库中一条条插入快太多。

4.4 部署运行要点

传统SSM项目最常见的部署方式就是打成war包丢进Tomcat。在IDEA里配置Tomcat时，注意Deployment标签里要添加war包，而不是只添加源码路径；启动成功后，访问路径一般会带上项目名，所以首页跳转时要处理好相对路径和绝对路径，避免登录成功后跳到一个404地址。

如果选了前后端分离方案，后端打成war包部署在Tomcat，Vue前端打包生成的dist目录放到任意Web服务器即可。联调时注意接口地址不能写localhost，要写后端服务器的IP地址，否则换电脑就访问不到了。

5. 论文组织与答辩准备

5.1 论文的整体框架

论文不要等技术全做完才开始写，最好边做边写。这套项目我建议以下面这种结构来组织：

• 摘要：300到500字，概括“做了什么、用了什么技术、解决了什么问题”
• 绪论：背景意义、国内外现状、研究内容
• 相关技术介绍：SSM框架、MySQL、前端工具
• 系统分析：可行性分析、功能需求、用例图
• 系统设计：总体架构、功能模块设计、数据库设计
• 系统实现：按模块贴代码和页面截图
• 系统测试：功能测试用例、结果分析
• 总结与展望：总结工作，提一个可扩展方向

写相关技术介绍这一章时，一定要画一张请求流转时序图，用ProcessOn或Visio都行：浏览器发起请求→DispatcherServlet→HandlerMapping→Controller→Service→DAO→数据库→响应返回。这张图在答辩时几乎是必讲的，提前画好能省很多现场解释的口舌。

5.2 测试用例设计与验收

测试章节不能只写一句“测试结果全部通过”。正确姿势是设计一张测试用例表，按模块列出用例编号、测试功能、操作步骤、预期结果、实际结果：

每个用例都写“与预期一致”，再附两三张界面截图，系统的规范性自然就体现出来了。如果有时间，还可以用JMeter对登录接口做并发测试，比如50个线程同时登录，记录平均响应时间，这部分写进性能测试小节相当加分。

5.3 答辩高频问题应答思路

答辩时老师很大概率会问框架层面的问题，我提前整理几个方向供参考：

问“为什么用SSM不用SpringBoot”，就按第一章里讲的思路回答，强调课程教研要求与理解底层机制，同时说明项目保留了迁移扩展空间。

问“权限是怎么控制的”，就说登录拦截器加角色拦截器加Session用户存储，再补充密码加盐、Session超时设置等细节。

问“考试提交怎么防止失败或重复”，把唯一键约束、事务管理、前端按钮禁用一个不漏地讲清楚，逻辑自洽就足够了。

问“排行榜怎么实现”，直接说SQL聚合查询、按分数和提交时间排序，再加一句“同分时先交卷的排名在前”，这是很自然的处理。

答的时候不要背稿，关键是让每个回答都有具体的落点，老师追问时你能接得上。

6. 毕设期间必踩的坑与避坑技巧

6.1 环境与依赖：最容易卡住的三个地方

第一个坑是Lombok不生效，现象是实体类的getter和setter报“找不到符号”。原因通常是Lombok和JDK版本不匹配，或者IDEA里没有装Lombok插件。解决方法是升级到1.18.30以上的Lombok版本，并在Settings→Plugins里确认插件是启用状态。

第二个坑是Spring相关依赖版本冲突，现象是启动时报NoSuchMethodError。解决办法是用mvn dependency:tree查看依赖树，把重复的、冲突的版本统一到一个。Druid和Spring整合时还容易漏掉druid-spring包，没有它数据源配置会静默失效，一旦出现启动后连接不上MySQL，先检查这一步。

第三个坑是中文乱码。检查三处：所有文件统一UTF-8编码；Tomcat的server.xml里Connector配置URIEncoding="UTF-8"；web.xml里配置CharacterEncodingFilter强制请求编码。

6.2 业务层面：答题模块的三个隐患

答题提交最容易出现隐藏Bug，我实际遇到过这几类：

第一，学生双击提交按钮，生成两条考试记录。前端点击提交后立即禁用按钮，后端再用exam_record表的唯一键兜底，双保险缺一不可。

第二，多选题评分标准不一致。出题时在Excel里就要规定选项顺序，答案统一按ABCD顺序记录，否则代码比对时会出现明明选对了却判错的情况。

第三，试卷中的试题被管理员误删。学生打开试卷后提交时发现题目ID查不到，整个交卷流程报异常。解决方案是出卷时就把题目列表快照保存到一张中间表，考试期间不实时查询题库，即使题库发生变化也不影响已开始的考试。

6.3 让项目“更好看”的三个扩展点

如果核心功能做完还有富余时间，我建议按这三个方向锦上添花：

第一，数据可视化大屏。把用户总量、访问量、平均分、各分类热度集中放到一个页面，用ECharts展示，答辩老师看到大屏，往往会默认项目完整度很高。

第二，健康打卡功能。每天让用户做3到5道快速问答题，连续打卡攒积分，配一个排行榜。功能实现简单，但互动感很强，演示时很有感染力。

第三，导出报告功能。把学生的考试成绩、错题分析导出成PDF或Word报告，用POI或iText实现。这个点一旦写进论文，技术含量明显上一个档次，而且非常契合平台的教育属性。

提示：扩展功能要基于核心功能做增量，千万不要为了加亮点把最基本的增删改查弄得不稳定。答辩时，一个稳定运行的核心系统，永远比一个功能丰富但到处是Bug的Demo要强得多。

做这个项目时，我最大的体会是：SSM项目成不成熟不在框架本身，在于你是否认真做对了模块拆解。同一个“青少年公共卫生教育平台”题目，有人只做出一个基础管理后台，有人却能做成学习、测验、统计、报告闭环的完整系统，差距就在动手之前多花两天做业务设计。如果你现在正卡在选题目或搭框架的阶段，建议先把用户角色和业务流程用一条故事线写出来，再去建表，最后写代码，这个顺序一旦颠倒，后面九成要返工。等你把这个平台完整跑通，学到的东西迁移到SpringBoot上，基本就是两三天的事。