Spring Boot 3.4.1 + Vue 3 构建校园招聘系统：架构设计与核心实现-编程实验室

简介：本资源是一套面向计算机专业本科生与毕业设计学习者的校园求职招聘系统完整实现方案，基于Spring Boot 3.4.1与Vue 3前后端分离架构，精准覆盖校园场景下的职位发布、简历投递、面试安排、权限管控等核心业务需求。压缩包共98个文件，含55张系统界面与流程图JPG/PNG截图、22个前端组件及交互逻辑JS/CSS/HTML文件、4份关键文档（含系统表结构设计、论文初稿、查重报告等），以及源码ZIP/RAR双格式备份，整体大小为42.43MB，结构清晰、模块可独立复用。已有21人下载学习，适合用于课程设计、毕设参考或全栈开发能力训练。读者可直接获取可运行的前后端源码、数据库建表脚本、JWT鉴权实现细节、Axios通信封装示例、Vue单文件组件组织方式及完整部署指南，兼具工程规范性与教学实用性。

1. 项目概述：一个面向校园的求职招聘系统

最近在整理过往项目时，翻到了一个挺有意思的“校园求职招聘系统”。这个项目是典型的基于Spring Boot 3.4.1和Vue的前后端分离架构，旨在为高校学生和企业搭建一个专属的线上求职招聘平台。不同于市面上通用的招聘网站，校园系统更聚焦于应届生和实习岗位，功能上会强调简历投递、宣讲会管理、在线沟通等场景。当时做这个项目，一方面是技术栈的实践，另一方面也是想解决学生找实习信息分散、企业进校招聘流程繁琐的实际痛点。

这个系统核心要解决几个问题：对学生而言，需要一个能集中查看校招信息、便捷投递简历、跟踪进度的平台；对企业而言，需要一个能高效发布职位、筛选简历、安排面试甚至举办线上宣讲会的工具；对学校就业指导中心而言，则需要一个能管理所有招聘活动、统计就业数据的管理后台。因此，整个系统的设计就围绕着学生端、企业端和管理员端这三个角色展开。技术选型上，后端用Spring Boot是看重其快速构建和生态成熟，Vue则负责构建灵活、响应式的前端界面，两者通过RESTful API进行数据交互，是当下非常主流且高效的开发模式。

接下来，我会详细拆解这个系统的设计思路、技术实现细节以及开发过程中踩过的那些“坑”，希望能给正在学习或打算构建类似系统的朋友一些参考。无论你是想了解Spring Boot和Vue如何协同工作，还是对招聘系统的业务逻辑设计感兴趣，相信都能从中找到有价值的内容。

2. 系统整体设计与架构拆解

2.1 核心业务角色与功能模块设计

一个校园招聘系统，首要任务是厘清参与方及其核心诉求。我们主要设计了三个角色：学生用户、企业用户和系统管理员。

学生端的功能核心是“找”和“投”。学生注册登录后，可以完善个人简历（包括基本信息、教育背景、项目经历、技能等），这是后续所有操作的基础。系统首页会根据学生的专业、意向岗位等信息进行职位推荐。学生可以按公司、职位、薪资等条件筛选和搜索职位，查看职位详情（包含职位要求、公司介绍、工作地点等）。最关键的一步是“一键投递”，学生可以选择已创建好的简历投向心仪的职位。投递后，学生可以在“我的投递”中查看投递状态（如“已投递”、“已查看”、“邀请面试”、“不合适”等）。此外，学生还可以收藏感兴趣的职位、查看企业发布的线上宣讲会直播或回放、与企业的HR进行在线沟通（简单的站内信或即时通讯）。

企业端的功能核心是“发”和“管”。企业用户需要提交营业执照等资料进行认证，认证通过后才能发布职位。发布职位时，需要填写详细的职位描述、要求、薪资范围、工作地点等。企业可以管理已发布的职位（上线、下线、修改）。当学生投递简历后，企业HR可以在后台查看投递列表，在线预览学生简历，并对每一份投递进行状态标记和操作，比如“标记为合适”并发送面试邀请（附带面试时间、地点或在线会议链接），或者“标记为不合适”。企业还可以发布和管理宣讲会信息，支持上传宣讲资料或配置直播链接。

管理员端的功能核心是“审”和“统”。管理员拥有最高权限，负责审核企业用户的资质，确保平台企业的真实性。管理员可以管理所有用户（学生和企业）的基本信息，处理举报或纠纷。同时，管理员需要管理所有职位和宣讲会信息，对违规内容进行下架。此外，管理员后台最重要的功能之一是数据统计与分析，例如：各专业学生的就业率趋势、热门岗位排行、企业活跃度、平台流量等，这些数据能为学校的就业指导工作提供决策支持。

注意：角色权限的设计务必在数据库和接口层面做严格隔离。例如，查询投递记录的接口，学生只能查自己的，企业只能查自己发布职位下的，管理员可以查全部。这通常通过@PreAuthorize注解配合Spring Security来实现，在编码初期就要规划好，避免后期出现越权漏洞。

2.2 技术栈选型与前后端分离架构

为什么选择Spring Boot 3.4.1 + Vue这个组合？这是经过权衡的。

后端技术栈（Spring Boot 3.4.1）：

核心框架：Spring Boot 3.4.1。选择较新的3.x版本，是为了利用其更好的性能（如虚拟线程的初步支持）、更现代的Java特性（如JDK 17+）以及更简洁的配置。相比于旧版本，3.x在安全性和依赖管理上也有改进。
安全框架：Spring Security + JWT。用于实现用户认证和授权。用户登录成功后，后端生成一个JSON Web Token（JWT）返回给前端，前端后续请求都在HTTP Header中携带此Token。这样后端服务就是无状态的，易于扩展。
数据持久层：MyBatis-Plus。这是一个强大的MyBatis增强工具，内置了通用的CRUD操作，可以极大减少编写简单SQL的工作量。它的条件构造器（QueryWrapper）也非常好用，能安全、方便地构建动态查询条件。
数据库：MySQL 8.0。关系型数据库，用于存储用户、职位、简历、投递记录等结构化数据。表结构设计时，要特别注意关联关系，例如用户-简历（一对多）、职位-投递记录（一对多）、企业-职位（一对多）。
缓存：Redis。用于缓存热点数据（如首页推荐职位列表）、存储用户会话（如果不用JWT而用Session方案）、以及用作短信验证码的临时存储（设置过期时间）。
其他工具：Lombok（简化POJO代码）、Hutool（国产工具集，处理日期、加密等非常方便）、Spring Boot Validation（参数校验）。

前端技术栈（Vue 3 + Element Plus）：

核心框架：Vue 3。采用Composition API，逻辑组织更灵活，尤其适合复杂组件。搭配Vite作为构建工具，开发热更新速度极快。
UI组件库：Element Plus。这是基于Vue 3的桌面端组件库，提供了丰富的、美观的组件，如表格、表单、对话框、导航菜单等，能极大加速前端开发。它的表格组件配合分页，非常适合展示职位列表、投递记录等数据。
状态管理：Pinia。Vue官方推荐的新一代状态管理库，比Vuex更简洁，TypeScript支持更好。用于管理全局状态，比如用户登录信息、全局的提示框状态等。
路由：Vue Router。管理单页面应用（SPA）的路由跳转。
HTTP客户端：Axios。用于发起对后端RESTful API的请求，可以统一配置请求拦截器（自动添加JWT Token）和响应拦截器（统一处理错误）。
其他：使用Sass/Scss编写样式，让CSS更可维护。

前后端交互：采用标准的RESTful API设计风格。后端提供一组清晰的API接口，例如/api/student/resume（学生简历相关）、/api/company/job（企业职位相关）。前后端通过JSON格式交换数据。开发时，前后端可以并行，后端先用Swagger或Apifox定义好接口文档，前端就可以根据文档模拟数据（Mock）进行开发，提升效率。

2.3 数据库表结构核心设计思路

数据库设计是系统的基石，这里列举几个核心表及其关联：

用户表（sys_user）：存储所有用户（学生、企业、管理员）的登录基础信息，如用户名、密码（加密存储）、手机号、邮箱、头像、用户类型（user_type，枚举：学生、企业、管理员）等。这里采用单表多角色的设计，通过user_type字段区分。
学生信息表（student_profile）：与sys_user一对一关联，存储学生的详细信息，如真实姓名、学号、学院、专业、入学年份、个人简介等。
企业信息表（company_profile）：与sys_user一对一关联，存储企业的详细信息，如公司全称、营业执照编号（用于审核）、Logo、公司规模、行业、地址、公司简介等。有一个audit_status字段表示审核状态（待审核、通过、驳回）。
简历表（resume）：与student_profile一对多关联（一个学生可以有多个版本的简历）。包含简历名称、求职意向、工作经历（可存为JSON字段或另建子表）、项目经历、技能列表、附件简历文件路径等。
职位表（job_position）：与company_profile多对一关联。包含职位名称、职位类别、薪资范围、工作城市、学历要求、经验要求、职位描述、职位要求、发布状态、浏览次数等。
投递记录表（job_application）：这是系统的核心枢纽表。它关联了resume（哪份简历）、job_position（哪个职位）以及sys_user（哪个学生投的）。此外，还有投递时间、当前状态（枚举）、企业方的处理备注、面试安排时间等字段。
宣讲会表（career_talk）：与company_profile多对一关联。包含宣讲会标题、时间、地点（或在线链接）、简介、海报图片等。

实操心得：对于像“工作经历”这种可能有多条、结构固定的数据，我倾向于设计一个单独的表work_experience，通过resume_id关联。虽然用JSON字段存储在resume表里更简单，但不利于后续的复杂查询（例如，想筛选有“Java开发”经验的学生）。数据库设计要在灵活性和查询效率之间做权衡。

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

3.1 后端Spring Boot核心功能实现

3.1.1 用户认证与授权（Spring Security + JWT）

这是系统的安全大门。我们采用无状态的JWT方案。

登录接口(/api/auth/login)：接收用户名和密码。后端校验通过后，使用JJWT库生成一个JWT Token。这个Token的Payload部分通常包含用户ID、用户名和用户类型。关键是要设置一个合适的过期时间（如2小时）。

// 示例代码片段：生成JWT public String generateToken(String username, String userType) { Map<String, Object> claims = new HashMap<>(); claims.put("username", username); claims.put("userType", userType); return Jwts.builder() .setClaims(claims) .setSubject(userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expiration)) .signWith(SignatureAlgorithm.HS512, secretKey) .compact(); }

JWT过滤器：我们自定义一个JwtAuthenticationFilter，将其配置在Spring Security的过滤器链中。这个过滤器会检查每个请求的Header中是否有Authorization: Bearer <token>，如果有，则解析Token，验证其有效性（是否过期、签名是否正确），并将解析出的用户信息设置到Spring Security的SecurityContextHolder中，这样后续的接口就能通过@AuthenticationPrincipal注解获取当前用户。
权限控制：在接口方法上使用@PreAuthorize注解。例如，发布职位的接口只能企业访问：@PreAuthorize("hasAuthority('COMPANY')")。学生更新简历的接口：@PreAuthorize("hasAuthority('STUDENT')")。管理员审核企业的接口：@PreAuthorize("hasAuthority('ADMIN')")。

3.1.2 简历与职位管理的CRUD与业务逻辑

这部分是业务核心，使用MyBatis-Plus能极大提升效率。

简历管理：学生端提供创建、更新、删除、查询列表、查询详情等接口。在创建或更新时，需要对传入的JSON数据（如工作经历列表）进行校验和转换。文件上传（附件简历）通常使用Spring的MultipartFile，保存到服务器本地或云存储（如阿里云OSS），并将文件访问路径存到数据库。

职位管理：企业端类似。发布职位时，需要确保企业认证状态为“已通过”。职位列表查询接口是高频且复杂的，它需要支持分页、按条件筛选（职位名、城市、薪资范围、学历要求等）。这里强烈推荐使用MyBatis-Plus的QueryWrapper来动态构建查询条件，避免拼接SQL字符串的安全风险。

// 示例：动态构造职位查询条件 public Page<JobPosition> queryJobs(JobQueryDTO queryDTO, Page<JobPosition> page) { QueryWrapper<JobPosition> wrapper = new QueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(queryDTO.getKeyword()), "job_name", queryDTO.getKeyword()) .eq(StringUtils.isNotBlank(queryDTO.getCity()), "work_city", queryDTO.getCity()) .ge(queryDTO.getMinSalary() != null, "min_salary", queryDTO.getMinSalary()) .le(queryDTO.getMaxSalary() != null, "max_salary", queryDTO.getMaxSalary()) .eq("publish_status", 1); // 只查询已发布的职位 return jobPositionMapper.selectPage(page, wrapper); }

3.1.3 投递流程与状态机设计

投递行为/api/application/apply是一个核心事务操作。

学生点击投递，前端传来jobId和resumeId。
后端接口首先检查：该职位是否存在且处于发布状态；该简历是否属于当前登录学生；该学生是否已投递过该职位（防止重复投递）。
检查通过后，向job_application表插入一条新记录，状态初始化为APPLIED（已投递）。
同时，可以异步增加该职位的“投递数”统计，或者给学生发送一条站内信通知。

状态流转是投递流程的关键。我们可以定义一个枚举ApplicationStatus，包含APPLIED（已投递）、VIEWED（已查看）、INTERVIEW_INVITED（面试邀请）、OFFERED（已发Offer）、REJECTED（不合适）等状态。企业HR在后台进行的“标记合适”、“邀请面试”等操作，本质上就是调用一个接口来更新这条投递记录的状态字段。这个状态变更最好能有日志记录，方便追踪。

3.2 前端Vue核心页面与组件开发

3.2.1 基于Vue Router和Pinia的权限路由管理

前端也需要感知用户权限，以控制菜单和页面的显示。

路由守卫：在router/index.js中设置全局前置守卫router.beforeEach。当用户跳转到任何页面时，先判断Pinia的store中是否有用户信息（Token）。如果没有，则跳转到登录页。如果有，则根据用户类型（从JWT解析或后端接口获取）动态生成或过滤出该用户有权限访问的路由菜单。
动态菜单：菜单数据可以来自后端接口，也可以在前端根据用户角色硬编码配置。例如，学生登录后，侧边栏菜单显示“首页”、“职位搜索”、“我的简历”、“我的投递”、“宣讲会”。企业登录后，则显示“首页”、“职位管理”、“简历筛选”、“宣讲会管理”。
Pinia Store：创建一个authStore，用于集中管理登录状态、用户信息、Token等。登录成功后，将Token存入localStorage并更新store状态。Axios的请求拦截器从store或localStorage读取Token，添加到请求头。

3.2.2 职位列表与筛选组件开发

这是学生端最复杂的页面之一，需要良好的用户体验。

布局：采用左右或上下布局。左侧或顶部是筛选条件区域（城市选择器、薪资范围滑块、学历要求下拉框、关键词搜索框等），右侧或下部是职位列表展示区域。
组件：筛选条件部分，大量使用Element Plus的ElSelect、ElInput、ElSlider、ElButton等组件。列表部分使用ElTable组件，显示职位名称、公司名称、薪资、城市、发布时间等列。
交互逻辑：
1. 页面加载时，自动调用后端接口加载第一页数据。
2. 当用户点击“搜索”或改变任何筛选条件时，重新组装查询参数，调用接口，并重置到第一页。
3. 实现分页，使用ElPagination组件，当切换页码时，携带当前筛选条件请求对应页的数据。
4. 列表中的每个职位项，应有“查看详情”和“立即投递”按钮。“立即投递”按钮点击后，弹出模态框让用户选择要使用的简历，然后调用投递接口。
性能优化：对于筛选条件的变化，可以加入防抖（debounce）处理，避免在用户快速输入或切换时频繁请求接口。

3.2.3 企业后台简历筛选与交互功能

企业登录后，进入“简历筛选”页面，这里会以表格形式列出所有投递了本公司职位的简历。

表格设计：表格列包括：学生姓名、投递职位、投递时间、简历状态、操作。HR可以点击“查看简历”预览学生的完整简历（通常以弹出层或新页面的形式展示一个精心设计的简历详情页）。
状态操作：在“操作”列，提供下拉菜单或按钮组，包含“标记为已查看”、“邀请面试”、“不合适”等操作。点击后，调用后端更新状态的接口，并刷新当前表格数据。
批量操作：为了提高效率，可以增加复选框，支持HR批量选中多条投递记录，然后进行统一的“标记为已查看”或“发送面试通知”操作。
沟通功能：可以在每条记录旁增加一个“联系”按钮，点击后跳转到站内信聊天界面，或直接显示学生的邮箱/电话（需学生授权）。

4. 关键技术点与深度优化实践

4.1 文件上传与存储方案

系统中涉及多种文件上传：用户头像、企业Logo、简历附件、宣讲会海报等。

本地存储：最简单的方式是使用Spring Boot的MultipartFile，将文件保存到服务器磁盘的某个目录（如/upload/avatar/）。需要配置一个资源映射，将URL路径（如/upload/**）映射到物理目录，以便前端能访问。缺点是服务器扩容、迁移时文件管理麻烦，且不适用于分布式部署。
云对象存储（推荐）：对于生产环境，强烈推荐使用阿里云OSS、腾讯云COS或七牛云等云服务。以阿里云OSS为例：
1. 后端集成OSS的SDK。
2. 前端直接上传到OSS（更推荐）或通过后端中转。前端直传需要后端提供一个“获取OSS上传凭证”的接口，前端拿到凭证后直接用SDK上传到OSS，上传成功后将文件在OSS的地址（URL）回传给后端保存。这种方式能极大减轻后端服务器的带宽和负载。
3. 优势：无限扩容、高可用、自带CDN加速、有图片处理能力（如生成缩略图）。
安全性考虑：
- 文件类型校验：在后端检查文件的MIME Type或后缀名，防止上传可执行文件等危险类型。
- 病毒扫描：重要系统可以考虑集成病毒扫描服务。
- 重命名：保存时使用UUID等随机名称，避免原始文件名冲突或包含特殊字符。
- 权限控制：确保用户只能访问自己有权访问的文件（如企业只能看到投递到自己职位下的简历附件）。

4.2 搜索功能的实现与优化

职位和简历搜索是高频功能，简单的数据库LIKE查询在数据量大时性能堪忧。

初期方案（数据库模糊查询）：对于小规模数据，使用MyBatis-Plus的wrapper.like()可以满足。但LIKE ‘%关键词%’会导致索引失效，全表扫描。
进阶方案（数据库全文索引）：对职位表的job_name、job_description等字段建立MySQL的全文索引（FULLTEXT），然后使用MATCH ... AGAINST语法进行搜索，效率更高。
高级方案（引入Elasticsearch）：当数据量达到数十万级以上，或搜索需求复杂（需要分词、高亮、相关性排序、聚合统计）时，必须引入专业的搜索引擎如Elasticsearch。
1. 搭建Elasticsearch集群。
2. 使用Logstash或编写Java程序，将MySQL中的职位数据同步到Elasticsearch的索引中。
3. 后端提供搜索接口，接收关键词，构造Elasticsearch的DSL查询语句，从ES中检索数据。
4. 优势：毫秒级响应、强大的分词和高亮、支持拼音搜索、复杂的过滤和排序。
5. 实操难点：需要处理数据同步的实时性问题（双写、监听binlog等），以及维护ES集群的稳定性。

4.3 实时通信与通知机制

系统需要一些实时或准实时的交互，比如HR发送面试邀请后，学生能及时收到通知。

WebSocket（强实时）：如果需要实现一个在线的聊天功能（学生与HR即时沟通），WebSocket是首选。后端使用Spring Boot整合spring-boot-starter-websocket，前端使用原生WebSocket或SockJS+Stomp。当用户上线时，建立连接并订阅个人频道。发送消息时，后端将消息推送到目标用户的频道。
服务器推送事件SSE：一种轻量级的、服务器向浏览器单向推送的技术。适合实现简单的通知中心，比如“你有新的面试邀请”。SSE实现比WebSocket简单，但它是单向的。
轮询与长轮询：不推荐，效率低。
实践方案：对于本系统，一个折中且实用的方案是：WebSocket用于核心的在线聊天，而系统通知（状态变更、新消息提醒）则采用“WebSocket推送+数据库持久化”。
1. 当HR发送面试邀请时，后端一方面更新数据库状态，另一方面尝试通过WebSocket向该学生推送一条实时通知：“您投递的[职位名]已发出面试邀请”。
2. 同时，这条通知内容也会插入到notification通知表中。
3. 如果学生当时不在线，没有建立WebSocket连接，那么当他下次登录或刷新页面时，前端会主动调用接口拉取notification表中未读的通知。
4. 这样既保证了重要通知的到达率（持久化），又提供了良好的实时体验（WebSocket）。

5. 部署、运维与性能调优

5.1 多环境配置与CI/CD流水线

一个规范的项目必须有开发（dev）、测试（test）、生产（prod）等不同环境。

Spring Boot多环境配置：使用application-{profile}.yml文件。例如application-dev.yml配置开发数据库，application-prod.yml配置生产数据库和Redis地址。通过启动参数--spring.profiles.active=prod来激活对应环境。
前端环境变量：Vue项目使用.env.development、.env.production文件来管理不同环境的后端API基础地址。
CI/CD（持续集成/部署）：使用Jenkins、GitLab CI或GitHub Actions。流程大致为：
1. 开发者推送代码到Git仓库的特定分支（如dev或master）。
2. CI工具自动触发，拉取代码，运行单元测试、打包。
3. 后端：使用Maven或Gradle打包成可执行的JAR文件。
4. 前端：运行npm run build:prod生成静态文件（dist目录）。
5. CD工具将构建产物（JAR包和dist文件夹）通过SSH或SCP上传到对应的服务器。
6. 在服务器上执行部署脚本：停止旧服务、备份、替换文件、启动新服务（后端可能是java -jar命令，前端可能是将dist目录放到Nginx的HTML目录下）。
7. 自动化的CI/CD能极大减少人工操作错误，提升发布效率。

5.2 服务器部署与Nginx配置

典型的部署架构：一台云服务器（如2核4G的CentOS 7.9），安装JDK 17、MySQL、Redis、Nginx。

后端部署：将打包好的your-application.jar上传到服务器，使用nohup java -jar your-application.jar --spring.profiles.active=prod &后台启动。更优的方案是使用systemd来管理服务，实现开机自启和便捷的启停控制。

# 示例 systemd 服务文件 /etc/systemd/system/campus-recruit.service [Unit] Description=Campus Recruitment Backend Service After=network.target [Service] Type=simple User=appuser WorkingDirectory=/opt/app/backend ExecStart=/usr/bin/java -Xms256m -Xmx512m -jar campus-recruit.jar --spring.profiles.active=prod Restart=on-failure [Install] WantedBy=multi-user.target

前端部署：将dist目录下的所有文件，上传到服务器某个路径，例如/usr/share/nginx/html/。

Nginx配置：Nginx扮演两个角色：1. 静态资源服务器（服务前端文件）；2. 反向代理服务器（将API请求转发给后端Spring Boot应用）。

server { listen 80; server_name your-domain.com; # 或服务器IP # 前端静态文件 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; # 支持Vue Router的history模式 } # 后端API反向代理 location /api/ { proxy_pass http://localhost:8080; # 转发到Spring Boot应用 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 可选：上传文件的访问路径代理（如果文件存在本地） location /upload/ { alias /opt/app/upload/; autoindex off; } }

配置好后，用户访问http://your-domain.com就能看到前端页面，前端发起的/api/xxx请求会被Nginx转发到后端8080端口。

5.3 数据库性能优化与缓存策略

随着数据增长，数据库可能成为瓶颈。

索引优化：这是最有效的手段。为所有作为查询条件的字段建立索引，尤其是WHERE、JOIN、ORDER BY子句中的字段。例如：job_application表的job_id,student_id,status字段；job_position表的publish_status,city,create_time字段。使用EXPLAIN命令分析慢SQL，查看索引使用情况。
查询优化：
- 避免SELECT *，只查询需要的字段。
- 对大数据量的分页查询，使用LIMIT offset, size在偏移量很大时（如LIMIT 100000, 20）会很慢。优化方案是使用“游标分页”或“基于ID的分页”，即记录上一页最后一条记录的ID，查询条件改为WHERE id > last_id LIMIT size。
- 合理使用JOIN，避免多表关联时产生笛卡尔积。
缓存策略：
- Redis应用：
  1. 热点数据缓存：将首页的推荐职位列表、热门公司信息等查询频繁、更新不频繁的数据放入Redis，设置过期时间（如5分钟）。
  2. 会话缓存：如果使用Session，可将Session存储到Redis，实现分布式Session共享。
  3. 防重提交：用户点击“投递”按钮时，用“用户ID+职位ID”作为Key，设置一个短时间的Redis锁（如3秒），防止快速重复点击导致重复投递。
  4. 短信验证码：用户注册或登录时获取的短信验证码，以“phone:code”为Key存入Redis，设置60秒过期。
- 本地缓存（Caffeine）：对于一些极少变更的字典数据（如城市列表、学历枚举），可以使用Caffeine在应用内存中缓存，速度极快。

5.4 监控、日志与故障排查

系统上线后，可观测性至关重要。

日志：使用SLF4J + Logback框架。在application.yml中配置日志级别和输出格式。关键业务操作（如用户登录、投递简历、发布职位）必须打上INFO日志。异常错误必须打上ERROR日志，并记录完整的堆栈信息。日志文件按日期滚动归档。
监控：
- 应用监控：集成Spring Boot Actuator，暴露/actuator/health、/actuator/metrics等端点，可以查看应用健康状态、JVM内存、GC情况、请求计数等。
- 可视化监控：将Actuator的指标通过Micrometer导出到Prometheus，然后用Grafana制作监控大盘，实时查看QPS、响应时间、错误率、JVM堆内存等。
- 分布式链路追踪：如果服务拆分，可以集成SkyWalking或Zipkin，追踪一个请求经过的所有微服务，便于定位性能瓶颈。
告警：配置Prometheus Alertmanager或使用云监控服务，对关键指标（如CPU持续过高、接口错误率飙升、服务下线）设置告警规则，通过邮件、钉钉、企业微信通知到负责人。

6. 常见问题与排查实录

在开发和运维这个系统的过程中，我遇到了不少典型问题，这里记录下排查思路和解决方法。

6.1 前端跨域（CORS）问题

现象：前端运行在localhost:5173，后端运行在localhost:8080，前端调用接口时浏览器控制台报错：Access-Control-Allow-Origin。
原因：浏览器的同源策略阻止了跨域请求。

解决：在后端Spring Boot应用中，通过配置WebMvcConfigurer或使用@CrossOrigin注解来允许跨域。生产环境应严格指定允许的源（allowedOrigins），而不是使用*。

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOrigins("http://localhost:5173", "https://your-production-domain.com") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowCredentials(true) .maxAge(3600); } }

6.2 文件上传大小限制

现象：上传较大的简历PDF文件时失败，后端报MaxUploadSizeExceededException。
解决：在application.yml中调整Spring Boot的文件上传大小限制。
```
spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB
```

6.3 生产环境前端路由404

现象：在开发环境Vue Router的history模式工作正常，但部署到Nginx后，刷新非首页的页面（如/job/list）会返回Nginx的404页面。
原因：Vue是单页应用，路由由前端控制。当用户直接访问/job/list时，Nginx会去服务器上找这个路径的文件，当然找不到。
解决：在Nginx配置中，为前端服务的location /块添加try_files $uri $uri/ /index.html;指令（见5.2节Nginx配置）。这样，当请求的文件不存在时，Nginx会返回index.html，由Vue Router来处理路由。

6.4 数据库连接池耗尽

现象：在高并发时段，系统日志出现大量Cannot get connection from datasource或Connection timeout错误。
排查：
1. 检查应用和数据库监控，看是否存在慢SQL，导致连接被长时间占用。
2. 检查应用配置的连接池参数（如HikariCP的maximumPoolSize）是否过小。
3. 检查代码中是否存在连接泄漏（获取了连接但没有正确关闭）。
解决：
1. 优化慢SQL，添加索引。
2. 适当调大连接池最大连接数，但不要超过数据库的max_connections限制。
3. 确保所有数据库操作都在try-with-resources或finally块中正确关闭连接（MyBatis通常自动管理，但复杂场景需注意）。
4. 设置合理的连接超时和空闲超时时间。

6.5 线上环境配置泄露

现象：不小心将包含数据库密码、Redis密码、OSS密钥的application-prod.yml文件提交到了GitHub公开仓库。
教训：生产环境的敏感配置绝不能硬编码在配置文件中提交到代码库。
最佳实践：
1. 使用环境变量注入。在application.yml中这样写：
```
spring: datasource: url: ${DB_URL:jdbc:mysql://localhost:3306/test} username: ${DB_USERNAME:root} password: ${DB_PASSWORD:123456}
```
2. 在服务器上通过export命令或Docker的env文件设置环境变量。
3. 或者使用配置中心，如Spring Cloud Config、Apollo、Nacos。

6.6 第三方服务依赖故障

场景：系统集成了短信服务（用于注册验证码），某天短信服务商接口突然不稳定，导致用户注册流程卡住，甚至拖慢整个应用响应。
解决思路：
1. 超时与重试：调用第三方接口时，必须设置合理的连接超时和读取超时（如3秒）。对于可重试的失败（如网络超时），可以实现简单的重试机制（最多3次）。
2. 熔断与降级：集成Resilience4j或Sentinel等熔断器。当短信接口失败率达到阈值，熔断器打开，后续请求直接快速失败（走降级逻辑），不再调用短信接口。降级逻辑可以是：记录日志，提示用户“短信发送稍慢，请稍后再试”，或者对于非核心功能，直接跳过。
3. 异步处理：将发送短信的任务放入消息队列（如RabbitMQ、RocketMQ），由独立的消费者异步处理。这样即使短信服务暂时不可用，也不会阻塞主业务流程，任务会在队列中等待重试。

开发这样一个完整的系统，从设计到上线，是一个不断遇到问题、解决问题的过程。每个“坑”踩过之后，都会对系统架构和编码细节有更深的理解。最重要的是，要建立一套规范的开发、测试、部署和监控流程，这样才能保证系统的稳定性和可维护性。

本文还有配套的精品资源，点击获取