企业官网建设流程全解析

1. 项目背景与系统目标

人才招聘系统绝对是计算机毕业设计里出镜率最高的题目之一，基本每个学校、每一届都能看到它的身影。原因很简单：业务场景贴近现实、功能边界清晰、技术栈覆盖面适中，既不会简单到看不出工作量，也不会复杂到学生做不完。Java搭配SSM框架实现的人才信息招聘系统，算是这类题目里的经典搭配。

这套系统主要解决两个角色的核心诉求：求职者需要快速找到匹配岗位、便捷投递简历、实时跟踪投递进度；企业端需要发布职位、筛选简历、管理招聘流程。再加上一个管理后台做全局把控，一个完整的招聘业务闭环就出来了。

很多同学拿到这个题目后容易犯一个毛病——上来就写代码。实际上招聘系统这种业务型项目，设计占七分，编码只占三分。业务规则想清楚了，表结构设计合理了，SSM框架的整合其实是个很成熟很套路化的过程。这篇文章会把整个项目从需求拆解、表结构设计到SSM整合、部署上线的完整链路走一遍，适合正在做毕设的在校生，也适合想用SSM框架练手写企业级业务的初级开发者。

2. 系统整体设计与技术选型思路

2.1 核心需求拆解

招聘系统本质上是一个信息撮合平台，核心是“人岗匹配”。拆开来看，系统必须处理三类信息流：求职者的个人信息与简历、企业发布的职位信息、以及两者之间的投递行为记录。

详细梳理下来，功能需求分为三个端：

• 求职者端：注册登录、个人中心、简历管理（在线编辑+附件上传）、职位搜索（按关键词、薪资、城市、学历要求筛选）、投递简历、查看投递状态、收藏职位。
• 企业端：注册登录、企业信息维护、职位发布与管理（上线/下线/删除）、收到的简历列表、简历筛选（通过/不通过/待定）、面试邀请通知。
• 管理后台：用户管理（禁用/启用）、企业认证审核、职位审核、数据统计（用户数、职位数、投递量）。

单看功能点会觉得东西不少，但归类后就能发现核心其实就两条线：用户→简历→投递；企业→职位→简历筛选。管理端只是在这两条线之上加了一层审核和管控。设计时围绕这两天主线建表，后续扩展就不会乱。

2.2 为什么选SSM而不是Spring Boot

现在Spring Boot已经是主流，很多新项目直接Boot起步，但SSM框架在这个题目里依然有它的价值。

用SSM做毕设最大的好处是“看得见配置”。SSM的三层框架各自分工明确：Spring管对象和事务，SpringMVC管请求分发，MyBatis管数据库操作。每一条请求从前端页面到Controller、Service、Mapper的完整流转路径都是显式配置出来的，这非常有利于在毕业答辩时讲清楚项目架构。Spring Boot自动配置确实省事，但很多学生用Boot做完项目，被问到底层原理时说不出所以然，答辩很容易翻车。

另外，SSM框架的项目结构天然就是按照三层架构划分的，包结构清晰，代码阅读成本低，这些对需要展示源码的毕设项目来说都是加分项。所以我的建议是：如果目标是快速实现功能、不纠结原理，Boot更快；如果目标是拿一个好成绩且能把框架讲明白，SSM反而是更稳的选择。

2.3 系统整体架构

系统采用经典B/S架构，浏览器作为客户端，服务器端按三层架构组织：

• 表现层（Controller）：接收前端请求、参数校验、调用业务层接口、返回视图或JSON数据。
• 业务层（Service）：承载核心业务逻辑，包括登录验证、投递状态流转、数据统计等，事务边界在这里控制。
• 持久层（Mapper）：基于MyBatis操作MySQL数据库，只负责数据读写，不掺杂业务逻辑。

前端页面采用JSP加JSTL渲染，配合少量JavaScript和Ajax做异步交互。这种组合虽说不算新潮，但胜在稳定、资料多、报错信息好查。实际开发时我把用户端页面和企业端页面分成了两个目录，方便做权限控制时进行路径拦截。

3. 数据库设计与核心表结构

3.1 表设计的基本原则

表结构设计的好坏直接决定后续开发的效率，招聘系统的核心表我梳理为六张：用户表、企业表、职位表、简历表、投递记录表、收藏记录表，另外加一张管理员表。

设计时需要遵循三个原则：一是角色数据分离，求职者和企业不能混在一张表里，否则字段差异太大，后期查询麻烦；二是状态字段必须预留，比如职位要有上下线状态、投递要有流程状态，这些状态字段是业务流转的基础；三是时间字段必须有，创建时间、更新时间在统计功能和问题排查时都极其重要。

3.2 核心表结构详解

用户表（t_user）：用户ID、用户名、密码（MD5加密后存储）、手机号、邮箱、用户类型（区分求职者/企业管理员）、注册时间、状态（正常/禁用）。

企业表（t_company）：企业ID、用户ID（外键关联）、企业名称、企业规模、所在城市、详细地址、融资阶段、企业简介、营业执照图片路径、认证状态（待审核/通过/未通过）。

职位表（t_position）：职位ID、企业ID（外键）、职位名称、职位类别、薪资范围（最低薪资/最高薪资）、工作城市、经验要求、学历要求、职位描述、招聘人数、发布时间、上线下线状态、审核状态。

简历表（t_resume）：简历ID、用户ID（外键）、真实姓名、性别、出生年份、最高学历、毕业院校、工作年限、联系电话、期望城市、期望薪资、技能标签、工作经历、项目经历、自我介绍、附件简历路径、更新时间。

这里有一个容易忽略的细节：简历表很多字段允许为空。因为用户可能是第一次填简历，也可能填了一半就保存。所以建表时这些字段全部设为NULLABLE，并且前端要配合做空值判断，避免页面渲染时空指针。

投递记录表（t_deliver）：投递ID、简历ID、职位ID、用户ID、企业ID、投递时间、状态（待查看/已查看/通过初筛/不合适/待面试/已录用/已拒绝）。这里关联字段比较多，但每个字段都有实际用处，比如企业ID可以直接按企业维度查收到的简历，避免每次都做三表联查。

管理员表（t_admin）：管理员ID、账号、密码、角色（超级管理员/普通管理员）、最后登录时间。

3.3 外键与索引的设计取舍

课程里教外键约束必须加，实际企业开发大多不用外键，保留关联字段但由业务层保证数据一致性。毕设项目要在“规范”和“实用”之间拿捏好度，我的做法是不加物理外键，但所有关联字段都建普通索引。

索引方面重点建三个：职位表的发布时间索引（用于排序）、投递记录表的用户ID和企业ID联合索引（用户查自己的投递记录、企业查收到的简历都是高频操作）、职位表的城市加薪资复合索引（筛选场景常用）。加上索引后，数据量在几十万条以内查询性能完全没问题。

4. SSM框架整合与核心业务流程实现

4.1 SSM整合的关键配置

SSM整合最让人头疼的就是那一堆XML配置。我用的是Spring 5.1.x加MyBatis 3.4.x的经典组合，Maven管理依赖。核心配置分为四个文件：applicationContext.xml（Spring主配置）、spring-mvc.xml（SpringMVC配置）、mybatis-config.xml（MyBatis配置）、jdbc.properties（数据库连接参数）。

applicationContext.xml要做的核心工作有三件：组件扫描（排除Controller）、配置数据源、配置事务管理器并开启注解事务。

配置数据源时推荐用阿里巴巴的Druid连接池，它自带监控页面和连接泄漏检测。使用时会有一个实际开发中非常常见的坑：数据库密码直接写在jdbc.properties明文里，代码能跑，但走到答辩环节很容易被问“生产环境密码安全怎么处理”。这个问题用Druid的ConfigTools生成加密后的密码即可解决，公钥放配置里，私钥在启动时通过参数传入，既简单又能在答辩时体现你对安全问题的思考。

spring-mvc.xml要配置的核心三件事：开启注解驱动、扫描Controller包、配置视图解析器。视图解析器的前后缀一定要检查清楚，通常配的是前缀/WEB-INF/views/、后缀.jsp。这个前缀配错会导致Controller返回逻辑视图名时找不到页面，而且报错信息比较隐晦，第一次遇到容易懵。

web.xml里需要配置Spring的上下文监听器、SpringMVC的前端控制器DispatcherServlet、以及CharacterEncodingFilter字符编码过滤器。字符编码过滤器的位置不能随便放，它必须配置在所有过滤器的最前面，而且forceEncoding要设为true，否则Post请求能解决中文乱码、Get请求依然乱码。

4.2 用户登录与权限拦截

登录功能是每个系统都有的模块，但越是基础越值得把细节做扎实。登录流程：用户提交账号密码，Service层先从数据库查询用户，比对密码时用MD5加密后再比对，登录成功后把用户对象存到Session，同时记录登录日志。

权限控制方面，我用SpringMVC的拦截器实现三套路径拦截规则：/user/**和/company/**开头的请求必须登录后才能访问，Admin路径必须管理员才可以访问。拦截器里主要做两件事：检查Session中是否存在登录标识；检查访问路径与用户类型是否匹配。

实际开发时企业端的路径拦截有点小曲折——登录接口本身也要走/company/前缀，如果不做排除配置，会出现“登录接口被拦截器拦截导致永远登录不了”的经典死循环。解决办法是在拦截器配置里把login开头的请求明确排除掉，这个细节我在第一次实现时花了大半个小时排查。

4.3 职位搜索与筛选

职位搜索是求职端的核心使用场景。页面上提供关键词、城市、薪资范围、学历要求、经验要求五个筛选条件，搜索结果按发布时间倒序排列。

这里的难点在于SQL是动态拼接的：用户可能选了城市没选薪资，也可能只填了关键词。用MyBatis的<where>加<if>标签动态拼接SQL是标准解法，注意每个<if>里判断条件要加上参数非空判断，尤其是薪资范围这种要求同时判断最低值和最高值的场景。

薪资存储我用了两个整数字段min_salary和max_salary，筛选时条件就是min_salary >= #{salaryMin} AND max_salary <= #{salaryMax}。有人图省事把薪资存成一个字符串“8k-15k”，看上去直接展示很方便，但后续做薪资筛选时就需要把字符串截断转数字，纯属给自己挖坑。业界的通用做法是把区间拆开存。

4.4 简历投递与状态流转

投递功能的核心逻辑是防重复投递：同一用户同一职位只能投递一次。实现时先在投递记录表查记录，存在则提示“请勿重复投递”，不存在则插入一条初始状态为“待查看”的记录。这个操作涉及检查加插入两步，并发场景下需要为表增加唯一索引兜底。

投递状态的设计采用了最简单的单字段状态机：待查看（1）→ 已查看（2）→ 通过初筛（3）/ 不合适（4），或者待查看（1）→ 已查看（2）→ 待面试（5）→ 已录用（6）/ 已拒绝（7）。状态流转只在Service层处理，Controller不允许直接改投递记录的状态字段，以保证业务逻辑不被绕过去。

求职者端查看投递进度时，一个页面要展示职位信息、企业信息、投递状态、更新时间四条数据。用一次连表查询解决，SQL拆解后是投递记录表主表，关联职位表、企业表取信息，关联简历表取投递简历名称。这个查询涉及的关联表较多，确保索引覆盖到位后性能才能有保障——这在面试和答辩中都可以作为亮点讲。

5. 简历模块与文件上传实现

5.1 在线简历编辑

在线简历编辑我采用了分段保存的方式，整个简历拆成基本信息、自我评价、工作经历、项目经历四块，每个Tab独立表单，每次只保存当前Tab的数据而不是整页提交。原因有两个：一是招聘网站本身就是这么设计的，用户体验合理；二是分段提交可以避免用户在一个超大表单中误触刷新导致已填内容全部丢失。

工作经历和项目经历这种一对多的子表数据，我用列表方式动态增删。前端维护一个JSON数组，添加一条记录就向数组push一个对象，删除就splice。保存时前端把JSON序列化成字符串，后端用Java对象接收后循环插入数据库。这个场景里如果想体现技术深度，可以改为用MyBatis的<foreach>标签做批量插入，效率更高也更好回答。

5.2 简历附件上传

附件上传支持常见的PDF和DOC格式，大小限制在5MB以内。SpringMVC解析文件上传依赖CommonsMultipartResolver配置，注意设置maxUploadSize属性，超出限制时要捕获MaxUploadSizeExceededException并给出友好提示，默认情况下会直接抛出500错误，首次使用不配置就容易踩到这个坑。

文件存储路径建议单独放在项目外部目录，比如D:/upload/或者服务器上的/home/upload/，避免文件存放在Web应用目录内——重新部署项目时旧文件会被一起清空，这在部署环境里必须特别小心。文件名要重新生成，用UUID加原始扩展名拼接，避免中文文件名乱码和重名覆盖两个问题同时出现。

下载附件时Controller通过ResponseEntity返回文件流，设置Content-Disposition为attachment触发浏览器下载。系统的安全细节也要注意：下载文件的请求参数如果是文件名，务必做路径校验，防止通过../跳转读取服务器任意文件。这个安全问题在企业开发中属于高危漏洞，毕设中能注意到并主动防护是很加分的。

5.3 企业查看简历的交互设计

企业端查看求职者投递的简历时有三个操作：标记为合适、标记为不合适、邀请面试。每次操作除了更新投递记录状态，还应该生成一条通知记录。求职者下次登录时，右上角消息中心出现未读红点。

通知表的设计很简单：通知ID、接收人ID、通知内容、状态（未读/已读）、创建时间。查询时统计一个“未读数量”接口，前端定时三分钟轮询一次。做秒级推送需要WebSocket，招聘系统这个场景三分钟轮询完全够用，不必为毕设引入过重的实时通信方案——这也是取舍设计中的一个可讲点。

6. 管理后台与数据统计

6.1 后台功能组织

管理员登录后进入独立后台，后台页面的布局和用户端不同，采用经典的左侧菜单加右侧内容区结构。功能菜单包括：用户管理、企业管理、职位管理、投递管理、数据统计。

用户管理支持关键字搜索和禁用/启用操作。禁用用户时除了改状态字段，还要强制清除该用户Session，否则用户已经登录的状态不会被状态变更影响。实现时在禁用操作中同时通过Spring的SessionRegistry找到该用户的HttpSession并调用invalidate方法——这块内容平时SpringSession管理和在线用户管理相关，值得记录一笔。

企业管理主要是企业认证审核。企业注册时提交营业执照等材料，管理员查看后审核通过才能发布职位。审核状态改变后该企业的登录用户可以收到一条消息通知，实现方式和之前的通知模块复用同一套逻辑。

6.2 数据统计与图表展示

数据统计是提升系统整体完成度的功能，也是展示工作量的一个重要入口。统计指标四个：用户总数、企业总数、职位总数、今日投递量。趋势图方面做了近七天的职位发布趋势和投递趋势两条折线图，用ECharts实现，后端提供聚合查询接口返回日期和数量列表。

SQL上按天分组统计需要用到DATE_FORMAT(create_time, '%Y-%m-%d')格式化时间字段，再配合GROUP BY完成聚合。这里有一个经验点：统计结果里没有数据的日期不会出现在结果集中，比如某天没有人投递，那天的记录就是空的，前端图表的X轴坐标会缺失，补数据时需要在Java层把缺失日期补0。这个问题在实际工作中经常会碰到，提前处理掉能省掉联调阶段的大量沟通成本。

7. 项目打包与部署全流程

7.1 本地环境准备

部署前先确认本地环境：JDK 1.8、Maven 3.6+、Tomcat 8.5+、MySQL 5.7+。开发IDE我用的是IDEA 2020版本，社区版和旗舰版都能正常跑SSM项目。

数据库初始化方面，项目里附带一个init.sql脚本，包含建库建表和基础测试数据。执行时用Navicat或者命令行source命令均可。我建议在SQL脚本里直接插入一个测试管理员账号、一个测试企业账号、一个测试用户账号以及若干条职位数据，第一次启动后就能直接体验完整流程，不需要逐个注册——这一点对后续演示项目功能时能节省大量时间。

7.2 Maven打包

SSM项目打包成war包部署到Tomcat是标准操作。IDE里点击Maven工具面板的package命令即可，命令行的等效操作是mvn clean package -DskipTests。跳过测试的原因是单元测试代码不完整时，执行测试可能导致打包失败，打包前跳过测试是统一的做法。

打包完成后，target目录下会生成以artifactId-version.war命名的war包。需要额外注意一点：项目里如果配置了<finalName>标签，war包名称会变成自定义值，部署访问路径可以直接控制。部署到Tomcat时，war包放在webapps目录下，Tomcat启动时会自动解压。

我在部署测试时发现第一次解压会自动创建同名目录，如果希望应用的访问路径是根路径，可以把war包改名为ROOT.war，Tomcat启动后直接通过IP加端口访问即可，不再需要带应用名路径——这个配置在本机调试时方便很多。

7.3 服务器部署要点

服务器部署之前，先检查项目里两个容易遗漏的配置：

数据库配置：连接地址从localhost改为服务器内网IP或公网IP。MySQL需要确认账号允许远程连接，同时为了安全设置，不建议用root账号直接连项目，创建专用库账号并授权指定库的权限更加规范。

文件上传路径：本地开发时上传目录在D:/upload/，Linux服务器上要改成/home/upload/，并且提前创建好目录。部署后如果上传功能报错文件名相关异常，优先检查目录是否存在、是否具有写入权限。

部署时如果使用Linux服务器，还需要确认防火墙和服务器安全组是否放行8080端口。很多同学部署完成后网页访问不了，检查半天代码，最后发现是端口没放开——因为云服务商的安全组里必须单独配置规则，在自己电脑上根本没这个问题。Tomcat默认端口是8080，如果想改成80端口直接访问，修改server.xml里的Connector port就行，但需要确保服务器上没有其他程序占用80端口。

7.4 部署验证清单

系统启动完成后，按以下清单逐项验证，能快速发现部署问题而不是浪费大量时间排查：

• 数据库连接是否成功：看Tomcat启动日志，如果报错Access denied for user或者Communications link failure，先检查数据库账号密码和网络连通性。
• 首页是否正常显示：访问http://IP:端口/，页面能出现系统首页说明静态资源路径配置正确；如果404检查是否部署为ROOT.war还是带应用名访问。
• 登录功能是否可用：用SQL脚本里预置的测试账号登录，能跳转到对应的用户中心或管理后台说明Session配置正常。
• 上传功能是否可用：在用户中心上传附件简历，到服务器上确认文件是否写入指定的上传目录。
• 修改数据库配置文件后是否重启：Tomcat部署war包后修改了jdbc.properties，必须重新打包并替换war包，不能只修改Tomcat下的解压目录，因为重启时Tomcat不会重新解压文件。

8. 常见问题与问题排查技巧

8.1 开发阶段高频问题

问题一：启动Tomcat报404错误

这类问题通常是项目没有部署成功。排查步骤依次为：检查项目是否打成war包并放置webapps目录；检查Tomcat启动日志中有没有报错信息；检查访问路径是否正确（带不带上下文路径）。其中上下文路径不匹配导致404最常见。

问题二：登录后页面显示乱码

先检查数据库连接URL是否带characterEncoding=utf8参数；再检查web.xml中的CharacterEncodingFilter是否配置且forceEncoding是否为true；最后检查页面本身的charset设置。三条全对之后乱码基本会消失，但注意SQL脚本导入数据时如果编码不一致也可能造成乱码，这种情况需要重新导入并指定--default-character-set=utf8参数——因为数据库里存的就已经是乱码，光改Java端是修不好的。

问题三：404访问不到Controller，也没有Tomcat报错信息

先看前端请求地址和Controller的@RequestMapping的值是否一致；再看WebMVC配置是否正确扫描到Controller包，直接加一个日志输出或断点查看DispatcherServlet有没有进入；如果都没有问题，检查web.xml那SpringMVC前端控制器是否配置了<url-pattern>/</url-pattern>和全局异常处理策略。

问题四：从本地复制项目到另一台机器，启动时连不上数据库

常见原因是IP地址和密码不一致，把jdbc.properties里的localhost改成目标机器的IP即可。还有一个隐蔽坑点是MySQL从5.7升级到8.x版本后驱动类名变了，连接的URL后缀也需要增加时区参数，否则时间字段全部报错。

问题五：Ajax请求返回数据正常，但页面无法渲染

大部分情况是因为后端返回的字段名与前端And段落要求的字段名不一致。SSM项目里JSON序列化默认遵循JavaBean的getter方法命名规则，比如Java端字段isShow序列化后会变成show，导致前端拿不到isShow属性。解决方法是统一字段命名规范，布尔类型字段不要用is前缀，这是个让人当时摸不着头脑但确认原因后很无语的问题。

8.2 部署阶段高频问题

问题一：访问不到Tomcat

按顺序排查：服务器是否安装Java环境，Tomcat是否启动成功且监听端口；安全组是否放行对应端口，防火墙是否拦截；域名是否解析到服务器。注意如果安装的是云厂商自带的全新CentOS系统，默认防火墙是开启的，需要显式放开8080端口，这个坑在云服务器上特别常见。

问题二：部署后登录正常，上传文件失败

优先检查上传目录的权限，执行chmod 777 /home/upload放通权限。随后检查项目里读取的保存路径是否存在。代码中用的是相对路径时，排查Tomcat的启动目录，不同环境下相对路径指向的位置不同，部署后容易踩坑——因此我一直推荐用绝对路径，并在项目里配置读取外部配置文件按环境自动切换保存目录的做法。

问题三：项目部署到服务器后图片/样式丢失

用浏览器F12看Network面板，定位失败的资源是404还是403。404说明静态资源路径配错了，403多数是tomcat配置里WebDAV或者目录访问权限限制。SSM项目中静态资源路径容易在配置DispatcherServlet时拦截掉.js和.css文件，需要在spring-mvc.xml配置<mvc:default-servlet-handler/>做放行。

问题四：内存不足导致部署失败

Tomcat的bin目录下的catalina.sh里可以设置JVM参数，例如JAVA_OPTS="-Xms512m -Xmx1024m"。但实际操作中我发现很多情况下不是真的内存不足，而是启动时重复触发了Tomcat进程，端口被占用。用ps -ef | grep tomcat查看进程信息，用lsof -i:8080查看端口占用，这个排查习惯比调节JVM参数更初期的见效快。

问题五：部署完成后，功能一闪界面不出现

打开Tomcat本地日志catalina.out，关注启动过程有没有异常。SSM项目部署时常见的坑是把JDK版本选太高，例如在JDK 17下运行Spring 5.1，启动过程会报一些类似反射访问失败的警告甚至直接报错。用Spring 5.1版本时确保JDK是8或11，尽量避免跨大版本使用的时期。

8.3 排查问题的通用方法论

排查问题有一套通用的方法论，掌握后绝大多数SSM项目的运行问题都能自己解决。第一步，看日志。Tomcat的logs目录里，catalina.out记录启动级错误，localhost.log记录应用WebApp部署信息，应用自己的log4j配置文件指定日志路径。绝大多数SSM项目二次提交问题时，日志里就能看到拍板级别的错误堆栈信息。

第二步，确认范围。请求的时候打开浏览器F12看Network和Console两个面板。看到Ajax请求404或500时，问题基本锁定在Controller和Service；看到网络请求正常但页面弹错，优先看JS代码逻辑；看到数据库操作失败堆栈，检查SQL和数据库表结构。

第三步，最小化复现。把请求参数固定到一个已知可以成功的值，逐步往出加代码，定位到导致问题的具体参数或具体操作。比如职位搜索无结果，可以先只按城市查，再单独加关键词，把问题范围从多个筛选条件并存的情况中释放出来。

第四步，善用搜索。项目报错拿到完整堆栈后，把错误信息核心段复制到搜索工具查一遍。像是ClassNotFoundException、NoSuchBeanDefinitionException、Invalid bound statement这些数据库M被映射的框架错误，基本都能直接命中相同场景的解决方案，不用自己硬扛。

9. 功能扩展与演进方向

核心功能全部跑通之后，系统的骨架已经完整了。如果想在答辩时增加亮点，或者作为简历项目投递时增加竞争力，可以考虑以下几个方向。

方向一：加入ElasticSearch实现全文检索

现在的职位搜索使用的是MySQL的LIKE模糊查询，数据量小没问题，数据量大了之后性能会明显下降。把职位数据同步到ElasticSearch，利用其分词和相关性排序能力实现全文检索。涉及的核心知识点是ES的索引设计、数据同步策略、检索API调用。这块改造成本大概会多花一到两周时间，但对技术视野的提升很大。

方向二：引入Redis做热点缓存

职位详情页是所有用户都会频繁访问的页面，每次从数据库查询会产生较大的数据库压力。用Redis缓存热门职位的详情数据，设置过期时间十分钟，缓存未命中时查询数据库并回填。然后再进阶一点，用Redis做投递次数的计数器，支持企业端实时查看职位预览量。这个方案改造起来不大，复杂度可控。

方向三：Spring Boot渐进式重构

SSM版本功能稳定后，把Spring配置和MyBatis整合同步迁移到Spring Boot自动配置，对比两种框架的差异，也算工作积累。重构的目的是理解Boot的约定大于配置理念，对比SSM手动声明bean和Boot自动配置的区别。这部分经历在面试中被问到框架差异时，往往能回答得比别人更有说服力。

方向四：加入消息推送机制

目前通知模块是轮询拉取，实际体验会有半分钟左右延迟。优化方案是用SSE（Server-Sent Events）或WebSocket做服务端主动推送。SSE的实现比WebSocket简单很多，只需要Spring的SseEmitter，在前端用EventSource接收即可。让投递状态变化后，求职者端浏览器实时弹出状态更新提示，体验提升非常明显。

10. 写在最后的个人经验

做了这么多年的Java项目，回头来看SSM框架技术本身已经不是市场上最新的技术栈，但它依然是理解Java Web开发底层逻辑非常好的一种手段。招聘系统的业务并不复杂，难的是把所有细节都考虑到，从表结构设计到状态流转，从权限控制到文件上传，从安全防护到部署上线，每一个环节都能体会到实际工程中的取舍。

给正在做这个题目的同学一个建议：不要只把“能跑起来”当作目标。多问自己几个“为什么”——为什么这一层要这样设计、为什么不直接用另一个框架、并发场景下会不会有问题。这些问题在答辩时面试官都会问到，提前想明白了，项目质量和答辩表现都会有明显提升。

这个过程本身的价值，能大于毕业设计本身。