企业官网建设流程全解析

就业推荐系统这个题目，我在不同阶段被同一个问题问过很多次：为什么Java+SpringBoot+SSM这套技术栈适合做它？答案其实很简单——它不挑用户，应届生、社会求职者、企业HR、学校就业办都用得上；它也不挑技术，SpringBoot负责工程化落地，SSM负责把业务逻辑讲清楚，两者叠加正好覆盖从传统SSM到SpringBoot进阶的完整知识面。整个系统我前后梳理过多遍完整闭环，从用户注册、简历维护、岗位发布，到核心的岗位推荐和投递管理，再到管理后台的统计数据，所有模块都围绕一个目标：让求职者用最少的成本找到匹配的岗位。

所以今天这篇分享，不是把源码每一行都念一遍，而是把项目里真正值得花时间的地方拆开：技术选型为什么这样定、数据库表怎么设计、推荐算法怎么做才不过度设计、以及我在调试和交付时踩过的坑。适合正在做同一个项目的学生，也适合想快速了解SpringBoot+SSM项目全貌的后端开发。无论你是打算照着写一遍，还是拿到源码后想二次开发，这篇都能省你不少折腾时间。

1. 项目全貌：就业推荐系统是什么，解决什么问题

1.1 项目定位与核心价值

就业推荐系统的本质，不是把招聘网站做一遍，而是解决“信息过载”和“匹配效率低”这两个问题。一个毕业生面对几千个岗位，靠关键词一页一页翻，效率很低；企业HR收到的简历多数不匹配，筛选成本又很高。系统把求职者、企业、管理员三类角色拉到一个平台上，用数据把双方连接起来。

对求职者来说，完善简历后可以获得个性化岗位推荐，不用海投；对企业来说，发布岗位后可以看到匹配的学生列表，甚至可以按技能标签、城市、学历筛选；对管理员（学校就业办或平台运营方）来说，可以查看注册人数、投递趋势、热门岗位标签、就业率这些统计数据，用来指导后续工作。这也是为什么这类系统经常被学校拿来做毕业设计选题——它足够完整，有清晰的业务场景，又有“推荐算法”这个可以讲深的技术点。

1.2 适合谁看，能学到什么

第一类是计算机相关专业、正在做毕业设计或课程设计的学生。这套系统的信息管理加推荐算法加统计图表，覆盖了选题要求里的大多数考点，而且业务链路完整，从登录到投递到推荐，每一步都有明确的用户价值。第二类是初级Java开发，可以借这个项目复习SSM整合、SpringBoot自动装配、MyBatis动态SQL、集合排序这些面试高频内容。第三类是中小团队想低成本搭一个招聘类平台，这套代码结构清晰，二次开发很方便。

值得强调的是，这类项目的核心价值不在CRUD，而在“推荐”这两个字上。CRUD谁都能写，但如何设计标签体系、如何计算相似度、如何做冷启动兜底，才是拉开差距的地方。这也是答辩或面试时最容易被追问的部分，我把这块单独放在后面重点讲。

2. 技术选型与架构设计：SpringBoot+SSM如何落地

2.1 从SSM到SpringBoot：不是替代关系，而是协作关系

SSM是Spring、SpringMVC、MyBatis三件套，分别负责依赖管理、请求路由、SQL持久化。SpringBoot则是一个工程化框架，通过自动配置把上面三样东西串起来，让项目可以独立运行。很多人问“标题里SpringBoot和SSM是不是重复了”，其实不重复。业内说的SpringBoot+SSM，通常是指以SpringBoot为骨架，内部仍然使用SpringMVC和MyBatis完成具体功能，本质上是“SpringBoot整合SSM”。

SpringBoot最核心的机制是自动装配。@SpringBootApplication 相当于 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan 三个注解的组合，启动时会根据classpath里的依赖自动创建数据源、配置MVC、注册拦截器等，省掉了传统SSM项目一大段XML配置。面试时如果被问“SpringBoot自动装配原理”，可以抓住两点：一是spring.factories或AutoConfiguration.imports文件里定义了所有自动配置类，二是@ConditionalOnClass等条件注解决定哪些配置生效。能做到“讲清楚自动装配”，这个项目的基本功就算过关了。

为什么保留MyBatis而不是换成MyBatis-Plus或JPA？我的看法是：就业推荐系统的岗位搜索条件很多，关键词、城市、薪资范围、学历、经验、排序方式，这种复杂查询用MyBatis动态SQL最直观，也最方便在答辩时讲出细节。MyBatis-Plus做单表CRUD确实省事，但一旦涉及多表关联和条件拼接，反而没有原生MyBatis可控。当然，用一个PageHelper做分页是没问题的，它本身是对MyBatis的插件增强。

2.2 项目分层与包结构：代码怎么组织才不混乱

我见过不少项目的是把所有类堆在一起，controller里直接写SQL，最后改一个功能要翻半天。这套就业推荐系统的代码量不算大，但依然要按标准三层架构拆清楚。推荐包结构如下：

com.example.job ├── controller // 接口层，接收参数，返回统一结果 ├── service // 业务层，处理业务规则 │ └── impl // 业务实现类 ├── mapper // MyBatis接口，只声明方法 ├── entity // 数据库实体，和表字段一一对应 ├── dto // 入参对象，接收前端传来的数据 ├── vo // 出参对象，返回前端需要的数据 ├── common // 统一返回体、全局异常、常量 ├── config // 配置类，拦截器、跨域、文件上传等 └── utils // 工具类，推荐算法、相似度计算

entity、dto、vo分开是很多新手容易忽略的细节。entity直接对应数据库表，如果把password、status这些字段原样返回给前端，等于把内部数据暴露出去。正确做法是controller接收dto，从session里拿当前登录人信息，service处理后返回vo。dto和vo看起来多写几个类，但能让接口更安全，也方便做字段校验和格式化。

controller层只做参数绑定和结果包装，service层写业务规则，mapper层只负责SQL。数据权限这类逻辑一定要放在service层，不能放在SQL里用固定条件写死。比如学生只能查自己的投递记录，条件是“userId = 当前登录用户”，这个userId必须动态传入，否则随便改个请求就能看到别人数据了。

2.3 数据库核心表设计：五张表撑起整个闭环

就业推荐系统的核心表其实不多，围绕“用户-简历-岗位-投递-收藏”这五条主线设计就能撑起全部业务。我常用的表结构如下：

经验提醒：岗位表我习惯叫job_post而不是position，虽然position在MySQL里不是保留字，但很多SQL工具有时候会标蓝提示，看着别扭，干脆避开。users表加一个role字段区分角色，比创建三张用户表更简单，权限判断也方便。user_id和job_id这类外键，我建议不在数据库里建物理外键，而是在应用层控制逻辑关联，这样删数据灵活、性能更好。但投递记录一定要加唯一索引（user_id, job_id），防止用户重复投递同一岗位。

skill_tags和tags这种标签字段，有两种设计方式：一种是单独建标签关联表，比如user_tags、job_tags，适合数据量大、需要做标签统计的场景；另一种是用逗号分隔的字符串，适合中小系统，读取后直接在Java里split成集合。我建议先用逗号字符串方案，因为推荐算法会在内存里拆分为Set，数据量几千条以内完全够用，实现也更直观。如果后面标签数量涨到几万，再迁移到关联表也不迟。

索引方面，job_post表给(city, status)建联合索引，因为岗位列表页最常按城市和上线状态过滤；apply_record表给user_id和job_id各建索引，方便查“某个用户的投递记录”和“某个岗位收到的简历数”；resume表的user_id要建唯一索引，一个用户只能有一条主简历。

3. 业务模块核心拆解：登录、搜索、推荐、统计怎么实现

3.1 三种角色的权限控制：学生、企业、管理员

权限控制是整个系统的安全地基，也是最容易被遗漏的部分。这个系统有三类角色，处理方式不能只靠前端隐藏按钮，后端必须做接口级校验。

我采用的方案是SpringMVC拦截器加Session（或Redis登录态）。先定义角色枚举：0是管理员，1是企业，2是学生。注册时前端选择身份，后端设置默认状态。管理员账号初始化时写入数据库，企业注册后可以由管理员审核通过才能登录发布岗位，学生则可以立即使用基础功能。

权限控制要分两个维度。第一个维度是接口能否访问：自定义一个HandlerInterceptor，在preHandle里判断请求路径，/admin/**开头的接口只允许role=0访问，/company/**只允许role=1访问，/student/**只允许role=2访问，拦截不到就返回401。第二个维度是数据权限，这个更关键：学生只能操作自己的简历和投递记录，企业只能操作本公司发布的岗位。实现方式是在service层从Session或Token里取出当前登录人ID，作为SQL查询和更新的必要条件，绝不能让前端随便传一个userId过来修改他人数据。

这里顺带说一个被问得很多的问题：为什么推荐用拦截器而不是Spring Security？Spring Security功能更强，支持注解权限控制，但学习成本高、配置复杂。毕业设计和中小型项目用拦截器就够了，代码量少，逻辑透明，答辩时也更方便讲清楚“我是怎么控制三角色权限的”。如果你后面想扩展JWT无状态登录，也只需要在拦截器里换掉Session取值逻辑，业务层完全不用动。

提示：权限校验不要只校验“是否登录”，更要校验“登录的是谁”。行级数据权限缺失是很多管理系统被一锅端的主要原因，面试官和答辩老师都很关注这一点。

3.2 岗位搜索与简历投递：MyBatis动态SQL是主力

岗位搜索页是系统的入口，也是MyBatis动态SQL最核心的使用场景。页面上会有关键词输入框、城市下拉框、薪资范围、学历要求、工作经验、排序方式这些筛选条件，每个条件都可能为空，这就很适合用 和 标签来做动态拼接。核心SQL片段如下：

<select id="pageSearch" resultType="com.example.job.vo.JobVO"> SELECT jp.*, cu.company_name FROM job_post jp LEFT JOIN users cu ON jp.company_id = cu.id <where> <if test="keyword != null and keyword != ''"> AND (jp.title LIKE CONCAT('%', #{keyword}, '%') OR jp.tags LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="city != null and city != ''"> AND jp.city = #{city} </if> <if test="minSalary != null"> AND jp.salary_max &gt;= #{minSalary} </if> <if test="maxSalary != null"> AND jp.salary_min &lt;= #{maxSalary} </if> <if test="education != null and education != ''"> AND jp.education &lt;= #{education} </if> <if test="status != null"> AND jp.status = #{status} </if> </where> ORDER BY <choose> <when test="orderBy == 'hot'">jp.apply_count DESC</when> <when test="orderBy == 'salary'">jp.salary_max DESC</when> <otherwise>jp.create_time DESC</otherwise> </choose> </select>

注意XML中“<”和“>”要转义成<和>，否则解析会报错。这里用salary_max >= minSalary和salary_min <= maxSalary做薪资区间重叠判断，比单纯比较某个字段更符合“岗位薪资区间与筛选区间有交集”的逻辑。

分页我推荐直接用PageHelper。使用时要记住一个原则：PageHelper.startPage()之后必须紧跟第一条查询语句，中间不能插入其他SQL操作，否则分页会作用到错误的查询上。如果你不希望引入PageHelper，也可以用limit #{offset}, #{pageSize}手动拼，但需要自己计算总条数和总页数。

投递接口的逻辑要照顾到幂等性。用户点击“投递简历”，先根据(user_id, job_id)查apply_record，如果已存在就直接提示“已投递，请耐心等待”；不存在才插入新记录，再对job_post表的apply_count做加一操作。同步更新岗位热度字段，可以避免后面推荐时还需要单独count投递量。投递状态流转可以用一个int字段存：1待查看、2已查看、3面试通知、4录用、5拒绝，前端根据数字显示不同标签，后端判断流转是否有权限。

3.3 轻量级推荐算法：标签匹配加权重排序

推荐模块是整个项目最大的亮点，也是很多人的难点。我的建议是：不要一上来就做协同过滤或深度学习，数据量小且稀疏的场景下，基于内容标签的相似度匹配反而更可靠，而且实现简单、可解释性极强，答辩时能清楚讲出每一步计算过程。

先说核心思路：把用户简历里的skill_tags拆成一个标签集合A，把岗位的tags拆成标签集合B，两个集合越相似，匹配度就越高。衡量两个集合相似度最经典的是Jaccard系数：

J(A, B) = |A ∩ B| / |A ∪ B|

举个例子。学生简历标签集合A = {Java, SpringBoot, MySQL, Redis}，岗位A标签集合B1 = {Java, SpringBoot, MySQL, Vue}，交集是{Java, SpringBoot, MySQL}，并集是{Java, SpringBoot, MySQL, Redis, Vue}，所以J = 3/5 = 0.6。另一个岗位B2 = {Java, SpringBoot, Docker, K8s}，交集是{Java, SpringBoot}，并集是{Java, SpringBoot, MySQL, Redis, Docker, K8s}，J = 2/6 ≈ 0.333。两个岗位相比之下，岗位A显然更匹配这位学生。

Java代码实现也很直接：

public class RecommendUtil { private RecommendUtil() {} public static double jaccard(Set<String> userTags, Set<String> jobTags) { if (userTags == null || jobTags == null || userTags.isEmpty() || jobTags.isEmpty()) { return 0.0; } Set<String> union = new HashSet<>(userTags); Set<String> intersection = new HashSet<>(userTags); union.addAll(jobTags); intersection.retainAll(jobTags); if (union.isEmpty()) { return 0.0; } return (double) intersection.size() / union.size(); } }

只算相似度还不够，推荐排序还要考虑“新鲜度”和“热度”。岗位刚发布的信息更值得看，投递量高的岗位代表已经有人验证过价值。我常用一个加权公式：

score = 0.6 * jaccardScore + 0.2 * freshScore + 0.2 * hotScore

freshScore可以设计成岗位发布时间越近分数越高，hotScore可以根据apply_count归一化到0到1之间。三个分数都控制在0到1，最终得分也是0到1，方便解释和比较。具体权重不需要很复杂，把相似度作为主因子，其他两个作为微调即可。

冷启动是推荐模块必须处理的场景。学生第一次登录，简历是空的，skill_tags为空集合，Jaccard算出来全是0，推荐接口就会返回空列表。我的处理方式是：如果用户没有简历或简历标签为空，就先用“热门岗位+城市筛选”兜底，推荐apply_count高的岗位，同时前端提示“完善简历获取更精准的推荐”。这一步不做，推荐模块在演示时会直接翻车。

这里可以顺带提一个进阶方向。如果想要更“智能”一点，可以做一个基于行为相似度的协同过滤：如果两个学生投递的岗位集合重合度高，就推荐其中一个学生投过、另一个没投过的岗位。但我的建议是作为扩展功能保留在源码里，主流程仍然用标签匹配，因为协同过滤在数据稀疏时效果不稳定，而且还增加了大量计算代码，对一个小型系统并不划算。

3.4 统计报表与可视化：用数据讲清楚就业情况

一个只有增删改查的系统没有亮点，统计模块能让项目上一个台阶。管理后台至少需要四个统计维度：注册用户趋势、岗位发布趋势、投递量Top10企业、热门岗位标签分布。这些数据都从已有表里聚合出来，不必新建大的统计表。

以“投递量Top10企业”为例，一条GROUP BY SQL就能搞定：

SELECT cu.company_name, COUNT(ar.id) AS apply_count FROM apply_record ar LEFT JOIN job_post jp ON ar.job_id = jp.id LEFT JOIN users cu ON jp.company_id = cu.id GROUP BY cu.company_name ORDER BY apply_count DESC LIMIT 10;

前端图表我推荐用ECharts，折线图展示趋势，柱状图展示排名，饼图展示标签占比。后端接口返回List<Map<String, Object>>或专门的统计VO，前端直接绑定数据。需要注意MySQL 5.7及以上默认开启了ONLY_FULL_GROUP_BY，SELECT的字段要么出现在GROUP BY里，要么被聚合函数包裹，否则SQL会报错。

统计模块还有一个隐藏价值：它是演示时的“加分项”。答辩时与其对着代码讲业务，不如打开图表页面，用数据说明“系统运行一段时间后的结果”，直观很多。

4. 实操记录：从环境准备到联调通过的完整流程

4.1 环境版本选型：先定版本，再写代码

技术栈版本选择是我看到很多新手翻车的第一关。SpringBoot 2.x和3.x差别非常大，SpringBoot 3.0以上强制要求JDK17，很多老教程里的依赖坐标也会失效。如果使用的是JDK8，一定不要选SpringBoot 3.x，推荐组合是：JDK8 + SpringBoot 2.7.x + MyBatis + MySQL5.7/8.0。如果机器上只有JDK17，那就可以选择SpringBoot 3.x，但相关的MyBatis starter也要找适配Boot3的版本。

Maven建议用3.6以上，并配置阿里云镜像仓库，不然下载依赖会等到怀疑人生。MySQL连接URL千万记得加上时区和SSL参数：

spring: datasource: url: jdbc:mysql://localhost:3306/job_recommend?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

如果使用旧的driver-class-name：com.mysql.jdbc.Driver，启动时会直接报加载失败。MySQL 8.0的驱动类已经改名成com.mysql.cj.jdbc.Driver。

依赖坐标方面，核心就这几个：spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、lombok、pagehelper。如果用到登录缓存，再引入spring-boot-starter-data-redis。不要一股脑把网上看到的所有依赖都塞进去，每加一个依赖就多一份冲突风险，项目够用就行。

4.2 项目初始化与跑通最小闭环

拿到源码后不要急着全量阅读，先跑通最小闭环再深入研究。第一步，用IDEA以Maven方式导入项目，等待依赖下载完成，这一步最容易出问题，建议在IDEA的Maven设置里配置阿里云镜像。第二步，新建数据库job_recommend，执行sql脚本，检查核心表是否创建成功。第三步，修改application.yml里的数据库账号密码，启动主类。看到SpringBoot启动日志出现“Started”即可。

跑通启动后，建议按“一条主链路”去调试：注册学生账号—登录—完善简历—搜索岗位—投递岗位—查看推荐岗位—企业账号收到简历—管理员查看统计数据。这条链路全部跑通，项目就基本没问题了。很多初学者喜欢每个页面都点一遍，遇到一个错改一个，结果越改越乱。正确做法是先定义清楚主流程，再逐个模块把异常和边界处理加上。

如果项目带前端，先检查前端代理配置是否指向后端端口。Vue项目通常有vue.config.js里的proxy配置，本地开发前端默认端口是8080或5173，后端默认是8080，需要把proxy target改成后端实际端口。跨域问题也可以在后端加一个CorsFilter配置类统一处理，但生产环境不建议全放行，可以指定允许的来源域名。

4.3 前后端联调与部署：本地调试和上线注意什么

前后端联调阶段，第一件事是约定接口返回格式。我用的是统一返回体Result ，包含code、msg、data三个字段，成功时code=200，失败时code=500或业务码。这个统一格式能省掉前端一大堆判断逻辑。另外，全局异常处理用@RestControllerAdvice捕获业务异常和未知异常，避免服务端一报错就返回一长串堆栈给前端。

部署方式上，如果只是小范围使用，推荐最简单方案：后端打成jar包，前端构建后的dist目录复制到SpringBoot项目的src/main/resources/static下，然后一起打成jar包运行。访问域名时就不用配Nginx了，SpringBoot内置Tomcat会直接托管静态资源。这也是热词里“vue打包放进springboot中”的实际操作。前端项目打包之前，记得把接口请求地址从http://localhost:8080改成相对路径或线上域名。

服务器部署命令很简单：

nohup java -jar job-recommend-1.0.jar > server.log 2>&1 &

上线记得修改数据库密码和Redis密码，关闭SpringBoot的DevTools热部署，移除或隐藏调试接口。日志级别可以从debug调整为info，避免日志文件迅速膨胀。

5. 常见问题、避坑指南与交付经验

5.1 开发期最容易踩的五个坑

这里是很多源码项目里不会写，但在实际调试中一定会遇到的高频问题，我整理成一张速查表。

还有一个非常容易被忽略的小问题：数据库字段名如果带下划线，比如create_time，实体类字段是createTime，一定要在MyBatis全局配置里开启驼峰映射：

mybatis: configuration: map-underscore-to-camel-case: true

不开启的话，查询结果里create_time字段映射不到createTime属性，数据永远为null。这个坑我见过太多次了，排查起来特别浪费生命。

5.2 推荐不准怎么办：三个排查方向

推荐接口返回的岗位不合理是最容易收到反馈的问题，排查时从三个方向入手。

第一个方向是数据源头。简历标签或岗位标签为空、标签太粗泛，推荐效果一定差。系统要在前端引导用户完善简历，至少要填写技能标签和期望岗位，再谈推荐。对于标签太少的岗位，可以在发布时做合法性校验，常见标签做成下拉选项而不是自由输入，减少垃圾标签。

第二个方向是匹配公式设计。如果只用Jaccard相似度，所有带Java标签的学生都会得到几乎一样的结果，因为没有区分“核心技能”和“辅助技能”。我的做法是给标签分权重，或者分两段计算：第一段先用“期望岗位+城市”做粗筛，第二段再用标签相似度做精排。比如一个学生的期望岗位是Java开发工程师，城市是杭州，就在岗位池里先过滤出杭州的Java岗位，再按标签排序，推荐的精准度立刻提升。

第三个方向是排序策略。纯相似度排序会导致一些旧岗位长期占据推荐位。加入时间衰减之后，发布超过30天的岗位freshScore越来越低，自然会让新岗位有展示机会。热度因素也不宜占比过高，否则会出现“大家都投我就要更早看到”的羊群效应，Tags更匹配但是投递量少的好岗位被埋没。

5.3 配套文档与项目讲解怎么做

很多项目都配有一份说明文档，但不少文档就是大量截图加流水账。我的经验是，文档要做到“老师能按你的思路复现整个项目”。结构上至少包含需求分析、系统设计、功能实现、系统测试、总结五个部分。需求分析里说清楚用户角色和功能清单；系统设计里给出技术架构图、E-R图、核心表说明和接口设计；功能实现部分放关键代码和解释，不用全贴代码；系统测试部分给一个功能测试用例表，列出操作步骤、预期结果、实际结果。调试文档则简单直接，写清楚环境清单、初始化步骤、启动顺序和默认账号即可。

讲解演示是最后一步，也是最容易被低估的环节。我的建议是三个步骤：先讲业务，一分钟说清楚系统解决什么问题；再讲核心，把推荐算法的计算过程和MyBatis动态SQL设计作为亮点；最后演示主链路，从登录到推荐到投递一气呵成。演示前准备好测试数据，不要现场注册账号填表，特别尴尬。老师如果问“为什么不用深度学习”，你就说：在冷启动和中小数据场景下，标签匹配可解释、可迭代、成本低，效果不比深度学习差，而深度学习依赖大规模样本，不适合这类小型系统。

这个系统我前后梳理过很多次，最大的体会是：别把推荐算法想复杂了。真正让用户愿意用的，不是算法多高级，而是推荐结果有没有过滤掉已投递、能不能解释为什么推荐、冷启动时有没有兜底方案。如果让我重新做一遍，我会先写一个最简单的标签匹配版本，跑通闭环之后再根据数据反馈慢慢加内容。最后分享一个小技巧：把推荐计算的逻辑独立成一个工具类，输入用户标签和岗位列表，输出排序后的结果，这样单元测试很好写，答辩演示时也能随时切换到不同测试数据去验证，完全不需要把整个项目启动起来。