说在前面：这个“中青年人员招聘平台”到底值不值得做

每年到了毕业设计开题季，总有一批人会对着“基于SpringBoot+Vue的XX平台设计与实现”这种题目发愁。我这两年带过不少学生和刚转行的朋友做这类全栈项目，说句实在话：“招聘平台”这个选题在计算机毕设里出现频率极高，但很多人的做法是套个模板、改个数据库表名、换几个页面，最后做出来的东西答辩老师一眼就能看穿。而中青年人员招聘平台这个方向，其实踩准了当前就业市场里一个很实际的需求场景——面向30到45岁这个年龄段的人员求职与招聘匹配，它比普通的大学生招聘、社会招聘更强调经验匹配、稳定性倾向和精准推荐逻辑，存在大量可以展开的业务细节和功能设计空间。

这个项目的技术栈是标准的SpringBoot + Vue前后端分离架构，附带源码、部署文档和讲解资源。也就是说，它的目标人群很明确：正在做毕业设计的高校学生、自学Java全栈想找一个有说服力的项目经历的人、以及想熟悉一套完整前后端分离项目从开发到部署全流程的初学者。如果你属于这几类人，这篇文章就是按“从零复现这套项目”的标准来写的。

顺便说一句，源码和部署文档能让项目“跑起来”，但答辩或面试时真正拉开差距的，是你对核心业务逻辑、权限控制、数据库设计和部署细节的理解。所以这篇文章不会只讲怎么把项目启动，我会把每个关键模块的设计思路、实现细节和最容易踩的坑全部拆开讲。

1. 项目定位：中青年招聘平台到底要解决什么实际业务问题

1.1 “中青年”这个定语决定了系统的核心差异

先别急着看代码，把这个项目的业务定位想清楚，后面所有表结构和接口设计都会顺着这个逻辑长出来。

市面上常见的招聘平台，典型的有拉勾、BOSS直聘、前程无忧，它们都有海量职位和简历，匹配逻辑偏向于“高频海投+即时沟通”。而“中青年人员招聘平台”这个题目里的核心词是“中青年”，在招聘业务里，这个群体的画像和应届生、低龄求职者有明显差别：

• 求职者普遍拥有3年以上工作经验，简历侧重项目经历、技术栈深度、行业背景，而非校园经历和实习经历。
• 招聘方的真实需求往往不是“广泛收集简历”，而是精准匹配某些特定行业、特定岗位经验的人。
• 平台需要有基础的筛选和推荐逻辑，比如按经验年限、期望薪资、期望城市、技能标签匹配职位。
• 中青年求职者对信息安全更敏感，简历的可见性控制、企业认证、隐私保护比普通招聘平台更重要。

所以这个项目不能只做“职位发布 + 简历投递”的简单闭环。一套及格的系统，至少要包括三个端：求职者端、企业端、平台管理端，还要有一次完整的业务流转。这也是为什么这类项目通常被要求包含“源码 + 设计文档 + 部署文档”全套，因为它的工作量确实不是一个简单CRUD能糊弄过去的。

1.2 技术选型为什么是SpringBoot + Vue，而不是其他组合

这个选择题其实是“标准答案”和“合理答案”的统一。Java + SpringBoot是当前国内中小型企业和教学体系里最主流的技术栈，资料全、招人多、遇到问题基本都能搜到解决方案。Vue在国内前端圈子的统治力也很稳，上手曲线平缓，生态成熟，组件库丰富。

如果你自己重新做一次技术选型，也建议保留这套组合，理由很实际：

• SpringBoot的自动配置和starter机制，让后端开发省去大量XML配置，可以快速把精力集中在业务代码上，这对项目周期紧张的毕设或个人项目至关重要。
• Vue的双向数据绑定和组件化开发方式，天然适合招聘平台这种“列表 + 详情 + 表单”密集型的交互场景。
• 前后端分离架构能体现现代Web开发的真实分工，答辩时关于“为什么用前后端分离”这个问题也能答得很充实。
• 部署方式成熟清晰，后端打jar包，前端npm构建后扔给Nginx托管，整个流程有迹可循，部署文档能写得很具体。

2. 系统核心功能模块拆解与权限边界设计

2.1 三种角色和一条完整业务闭环

招聘平台不是一个“人人都能发布职位”的简单社区，角色和权限的边界不给清楚，后端的接口设计就是一团浆糊。这套系统里我把角色分成三类：

一个完整的业务闭环是这样的：企业注册 → 企业信息认证（管理员审核）→ 发布职位（管理员审核通过后上架）→ 求职者浏览/收藏/投递 → 企业查看收到的简历 → 企业更新职位状态（招聘中/已停招）→ 求职者查看投递反馈。

这个闭环里有两个审核节点，这很关键。管理员审核企业资质和职位内容，一方面符合真实招聘平台的合规逻辑，另一方面也让后台管理模块有了实际存在的意义，不会出现“三个端功能雷同”这种答辩硬伤。

2.2 各功能模块的粒度划分

具体到代码层面，功能模块建议拆成这样：

• 用户模块：注册（支持求职者/企业双角色）、登录、验证码、个人信息维护、密码加密存储与修改。
• 简历模块：教育经历、工作经历、项目经历、技能标签、期望职位/薪资/城市，简历的在线编辑与预览。
• 企业模块：企业注册信息填写、资质证明材料上传、企业信息编辑。
• 职位模块：职位发布、职位编辑上下架、职位搜索（关键词 + 城市 + 经验要求 + 薪资范围筛选）。
• 投递模块：投递简历、投递记录列表、企业查看投递者简历、更新投递状态（已查看/已邀约/已拒绝）。
• 收藏模块：求职者收藏职位，方便后续统一查看。
• 审核模块：管理员对企业认证和职位发布进行审核，审核结果通知相关用户。
• 统计模块：平台用户数量、职位数量、投递数量的基础统计，用于管理员首页仪表盘。

每个模块的接口、实体类、业务逻辑，后面都会顺着这个清单展开。建议你在拿到源码后，先把模块清单和数据库表对应起来，做到“看到一个页面就能说出它是哪个模块的第几层逻辑”，答辩时即便被追问也不慌张。

2.3 前后端分离下的接口设计风格

这个项目的接口设计使用的是RESTful风格，统一以/api前缀开头，按模块划分路径：

code复制POST   /api/auth/register          # 注册
POST   /api/auth/login             # 登录
GET    /api/jobs                   # 职位分页列表，支持关键词/城市/薪资筛选
POST   /api/jobs                   # 企业发布职位
PUT    /api/jobs/{id}/status       # 企业更新职位状态
GET    /api/resume/mine            # 求职者查看自己的简历
POST   /api/resume                 # 保存或更新简历
POST   /api/deliveries             # 求职者投递职位
GET    /api/deliveries/company     # 企业查看收到的投递
GET    /api/admin/audits           # 管理员获取待审核列表

返回结果统一包装为Result对象，包含code、message和data三个字段。这样做的前端处理非常统一，拦截器里判断code是否为200即可，后续要扩展错误码也方便。

3. 数据库设计：招聘平台的数据骨架到底该怎么搭

3.1 核心表结构设计

数据库设计是这类项目评阅老师重点看的交付物之一，也是后期代码能不能写得顺畅的根基。我建议主库设计为以下这些核心表，表结构的命名直接体现业务含义：

3.2 几张关键表的设计思路

user表要单独建，不跟resume或company合并。原因很直接：用户的登录凭证（用户名、密码、角色）和业务资料（简历内容、企业信息）变更频率完全不同，拆开以后职责清晰，改简历不会误动登录数据，也更符合垂直分表的思路。

resume_experience表是一个典型的“主表 + 子表”结构。有些初学者喜欢把教育经历、工作经历、项目经历都以固定列名放在resume表里，比如学校一、专业一、工作一、工作二……这种设计的扩展性非常差，一个人有5段工作和3段项目经历怎么办？加20个字段？用子表，通过type字段区分经历类型，每条经历的起止时间和描述自由扩展，完美适配真实简历的多样性。

delivery表是整个业务闭环里最核心的一张表，必须记录resume_id和job_id两张外键。status字段建议用枚举值管理，例如0=待查看、1=已查看、2=已邀约、3=已拒绝，这样状态流转在代码里是常量级别的控制，不会出现“字符串路径写错导致状态跳变”的低级bug。

3.3 投递唯一约束和索引优化的细节

投递表要加一个联合唯一约束：(user_id, job_id)，同一用户对同一职位不能重复投递。这个约束很符合真实场景，而且后续业务层哪怕并发请求同时插入，数据库层面也能兜住。

索引方面，优先给这几组查询加索引：

• job表的(city, status, audit_status)联合索引，对应前端职位列表的筛选条件。
• delivery表的(company_id, status)联合索引，对应企业查看收到的简历列表。
• delivery表的(user_id)索引，对应求职者的投递记录查询。

具体到Navicat或SQL命令行，创建表时直接写好索引。真别小看这个步骤，没有索引的情况下，职位数据超过几千条后，联表查询的速度就会肉眼可见地变慢，答辩演示时如果因为这种低级问题卡页面，非常扣分。

4. 后端工程结构与核心模块实现

4.1 标准分层架构与包结构

后端工程我建议使用标准的四层架构：Controller层接收参数和返回结果，Service层处理业务逻辑，Mapper层（Repository）负责数据库交互，Entity层映射数据表。包结构可以参考下面这样：

code复制com.recruit.platform
├── common          # 统一返回结果、全局异常处理、常量类
├── config          # WebMvc配置、拦截器注册、跨域配置
├── controller      # 各模块接口入口
├── entity          # 数据库实体类
├── mapper          # MyBatis-Plus Mapper接口
├── service         # 业务逻辑层接口与实现
├── dto             # 前端交互的请求/响应对象
├── vo              # 视图对象，组合多表数据后返回给前端
└── utils           # JWT工具类、密码加密工具等

这个包结构是我做毕设项目的标准模板，也适合答辩时画架构图。它的核心思路是每个类只负责一件事：Controller层不写任何业务代码，只做参数接收入参校验和返回包装；Service层不出现SQL语句，只调用Mapper的预定义方法；Entity字段和数据库表字段一一对应，不掺杂前端需要的格式化逻辑。

4.2 登录认证：Session还是JWT？

这类前后端分离项目里，登录认证方案在SpringBoot技术栈下最常用的是JWT（JSON Web Token），也是当前企业级项目的主流方案。我这里使用的是JWT，具体实现逻辑：

1. 用户登录成功后，后端根据userId、username、role生成一个有效期为24小时的token。
2. token随登录接口的响应数据返回给前端。
3. 前端把token存在localStorage（或Pinia/Vuex）中，在axios请求拦截器里统一把token塞进Authorization请求头。
4. 后端写一个JwtInterceptor，在WebMvcConfig中注册到拦截器链里，统一校验请求头中的token是否合法，解析出用户信息后放入ThreadLocal上下文，供后续业务代码获取当前用户。

JWT的核心好处是服务端无状态，不需要像Session方案那样维护会话存储，节点越多优势越明显。需要注意的点是：JWT一旦签发无法主动失效，所以token有效期不能太长，并且退出登录的操作要走“前端清除token”这个方案。为了响应登出的需求补充一个黑名单也可以，但对毕设项目来说过度设计。

密码加密使用的是BCryptPasswordEncoder，这是Spring Security里自带的一个加密工具类，纯Java工程里也直接可以用。BCrypt是加盐哈希，每次加密结果都不同，而且计算成本可调，比MD5那种可逆的计算方式安全得多。数据库里的密码字段长度建议设成60到64位。

核心代码示例：JWT生成与校验工具类

java复制public class JwtUtils {
    private static final String SECRET = "your-secret-key";
    private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000;

    public static String generateToken(Long userId, String username, String role) {
        return Jwts.builder()
                .claim("userId", userId)
                .claim("username", username)
                .claim("role", role)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }

    public static Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

这段代码里的SECRET在生产环境肯定是要放到配置文件的，但在本项目中直接写在工具类里也够用。不过你如果打算把项目上传到公开仓库，建议至少把它移到application.yml里并通过环境变量注入，不然等于把密钥公开了。

4.3 拦截器实现用户身份注入

拦截器是后端安全的核心。我通常会写一个UserContext类，配合ThreadLocal进行用户身份存储：

java复制public class UserContext {
    private static final ThreadLocal<LoginUser> HOLDER = new ThreadLocal<>();

    public static void set(LoginUser user) { HOLDER.set(user); }
    public static LoginUser get() { return HOLDER.get(); }
    public static Long getUserId() { return HOLDER.get() == null ? null : HOLDER.get().getUserId(); }
    public static void clear() { HOLDER.remove(); }
}

拦截器处理流程：

1. 放行/api/auth/login、/api/auth/register、/api/jobs/list、/api/jobs/{id}这类公开接口。
2. 除白名单以外的所有/api/**请求，都从Authorization头里取token。
3. token为空或解析失败，直接返回401错误码。
4. token合法，把用户信息解析出来放到UserContext里，然后放行请求。
5. 请求结束后，在afterCompletion里调用UserContext.clear()，防止线程池复用导致的用户信息串线。

这一步是很多刚学前后端分离的人特别容易漏掉的地方。如果你在后端某个地方直接UserContext.getUserId()拿到的却是别人的ID，十有八九就是ThreadLocal没清理。

4.4 简历模块的核心业务逻辑

简历模块是求职者端的核心，也是这个项目最有业务深度的模块。我的实现思路是这样的：

保存简历的接口设计为POST /api/resume，前端一次性把简历主表信息和一段一段的经历列表传到后端。后端拿到数据后的处理逻辑是：

1. 根据当前登录用户ID查询现有简历。
2. 存在则更新主表字段，再根据传过来的经历列表逐条对比：前端传了经验的id就更新，没有id的做插入，数据库中存在但这次请求里没传的做删除。
3. 不存在则执行插入。

这段逻辑用MyBatis-Plus实现，核心是先把旧的经历记录全部逻辑删除或物理删除，再整体插入新的经历列表。对毕设项目来说，这是最简单也最不容易出错的做法。如果追求更精细的差异对比，代码复杂度会成倍上升，实际收益却不大。

另外一个常见的需求是“简历预览”。这块的前端处理方式建议是用一个独立的详情页面来渲染简历的各个板块，而不是在编辑页面切换模式。编辑提交后跳转到预览页，预览页只负责展示后端保存的数据。这样职责明确，也不用在同一页面里做复杂的组件状态切换。

核心代码示例：服务层保存简历

java复制@Transactional(rollbackFor = Exception.class)
public boolean saveResume(ResumeDTO dto) {
    Long userId = UserContext.getUserId();
    Resume resume = new Resume();
    BeanUtils.copyProperties(dto, resume);
    resume.setUserId(userId);
    // 保存或更新简历主表
    if (resume.getId() == null) {
        this.save(resume);
    } else {
        this.updateById(resume);
        resumeExperienceMapper.delete(new LambdaQueryWrapper<ResumeExperience>()
                .eq(ResumeExperience::getResumeId, resume.getId()));
    }
    // 重新插入经历列表
    if (dto.getExperiences() != null) {
        for (ResumeExperience experience : dto.getExperiences()) {
            experience.setId(null);
            experience.setResumeId(resume.getId());
            resumeExperienceMapper.insert(experience);
        }
    }
    return true;
}

这个接口加上了@Transactional，保证了“主表更新 + 子表清空重建”的原子性。如果不加事务，万一插入经历时出错，简历主表的数据已经改了，前端会拿到一个不一致的状态。

4.5 职位搜索与分页

职位列表是这个项目访问量最大的接口，要支持关键词模糊搜索和多项筛选。我在Service层用的是MyBatis-Plus的LambdaQueryWrapper配合Page对象：

java复制public Page<JobVO> searchJobs(JobQueryDTO query) {
    Page<Job> pageParam = new Page<>(query.getPageNum(), query.getPageSize());
    LambdaQueryWrapper<Job> wrapper = new LambdaQueryWrapper<>();
    if (StringUtils.hasText(query.getKeyword())) {
        wrapper.and(w -> w.like(Job::getTitle, query.getKeyword())
                            .or().like(Job::getDescription, query.getKeyword()));
    }
    if (StringUtils.hasText(query.getCity())) {
        wrapper.eq(Job::getCity, query.getCity());
    }
    if (query.getSalaryMin() != null) {
        wrapper.ge(Job::getSalaryMax, query.getSalaryMin());
    }
    if (StringUtils.hasText(query.getExperienceRequired())) {
        wrapper.eq(Job::getExperienceRequired, query.getExperienceRequired());
    }
    wrapper.eq(Job::getAuditStatus, 1)   // 审核通过
           .eq(Job::getStatus, 1);        // 招聘中
    wrapper.orderByDesc(Job::getCreateTime);
    // ... 返回数据附带企业信息
}

薪资筛选这里有一个容易出错的地方：如果你想筛选的是“期望薪资在8k-15k范围”，数据库里存的是最低薪和最高薪两个字段，查询的边界处理就要多想想。比如用户选择薪资下限8k，筛选条件应该是salary_max >= 8000，而不是salary_min >= 8000，否则那些薪资区间是“15k-20k”和“10k-15k”的职位会被漏掉。这个小细节，建议在答辩时主动说出来，会显得你确实考虑过业务场景的合理性问题。

4.6 企业投递管理模块

投递管理是连接求职者和企业的桥梁。企业端收到的简历列表，我的实现是：

1. 根据当前登录用户的companyId查所有该企业名下的职位id。
2. 用这些职位id查投递记录。
3. 关联查询每一条投递对应的简历信息和求职者基本信息。

这里有一个实操上的经验点：不要用三次以上的嵌套循环在Java层做数据拼接。正确做法是分两条SQL查询，一条查投递列表和简历ID，另一条按简历ID批量查询简历和用户信息，然后在Java层组装成VO对象返回给前端。数据量大的场景下，这种“拆开查再组装”的方式比嵌套查询高效很多，代码也不会绕成一团。

java复制public List<DeliveryVO> getCompanyDeliveries(Long companyId) {
    List<Job> jobs = jobMapper.selectList(new LambdaQueryWrapper<Job>()
            .eq(Job::getCompanyId, companyId));
    List<Long> jobIds = jobs.stream().map(Job::getId).collect(Collectors.toList());
    if (jobIds.isEmpty()) return Collections.emptyList();
    List<Delivery> deliveries = deliveryMapper.selectList(new LambdaQueryWrapper<Delivery>()
            .in(Delivery::getJobId, jobIds)
            .orderByDesc(Delivery::getCreateTime));
    // 批量查询简历和用户信息
    List<Long> resumeIds = deliveries.stream().map(Delivery::getResumeId).distinct()
            .collect(Collectors.toList());
    Map<Long, Resume> resumeMap = resumeMapper.selectBatchIds(resumeIds).stream()
            .collect(Collectors.toMap(Resume::getId, Function.identity()));
    // 组装 VO
    return deliveries.stream().map(delivery -> {
        DeliveryVO vo = new DeliveryVO();
        // ... 字段组装
        return vo;
    }).collect(Collectors.toList());
}

5. 前端Vue工程与关键页面设计

5.1 前端工程结构和路由设计

前端部分我选择Vue 3 + Vite + Vue Router + Pinia + Element Plus这个经典组合。Vite比Webpack的启动速度快很多，配置也更简洁，对新手友好。Element Plus则帮我们省掉了大量UI组件的造轮子时间，表格、表单、对话框、分页组件直接拿来用，样式也统一。

前端工程目录结构：

code复制frontend/
├── src
│   ├── api               # 接口请求封装
│   ├── assets            # 静态资源
│   ├── components        # 通用组件
│   ├── router            # 路由配置
│   ├── store             # Pinia状态管理
│   ├── views             # 页面组件
│   │   ├── admin         # 管理员端页面
│   │   ├── company       # 企业端页面
│   │   ├── seeker        # 求职者端页面
│   │   └── common        # 公共页面（登录、注册、首页）
│   ├── utils             # 工具函数
│   ├── App.vue
│   └── main.js

路由配置是前端结构的关键。我建议在router/index.js里给路由加上前置守卫，根据本地存储的token和用户角色做页面跳转控制：

javascript复制router.beforeEach((to, from, next) => {
    const token = localStorage.getItem('token');
    if (to.meta.requiresAuth && !token) {
        next('/login');
    } else if (to.meta.role && to.meta.role !== localStorage.getItem('role')) {
        next('/403');
    } else {
        next();
    }
});

这里有个细节：localStorage.getItem('role')是在登录成功后由后端返回的role字段，前端存下来。如果角色匹配不上，就跳转到403页面。这个机制虽然简单，但在前端做了一层初步的权限控制，避免用户从前端看到不属于自己角色的页面结构。

5.2 axios请求封装与登录态管理

前端请求封装我放在src/utils/request.js，统一配置axios：

javascript复制import axios from 'axios'
import { ElMessage } from 'element-plus'
import router from '../router'

const request = axios.create({
    baseURL: '/api',
    timeout: 10000
})

request.interceptors.request.use(config => {
    const token = localStorage.getItem('token')
    if (token) {
        config.headers.Authorization = token
    }
    return config
})

request.interceptors.response.use(
    response => {
        const res = response.data
        if (res.code !== 200) {
            ElMessage.error(res.message || '请求失败')
            return Promise.reject(new Error(res.message))
        }
        return res
    },
    error => {
        if (error.response && error.response.status === 401) {
            localStorage.removeItem('token')
            localStorage.removeItem('role')
            router.push('/login')
        }
        ElMessage.error('网络请求异常')
        return Promise.reject(error)
    }
)

export default request

这样的好处是所有接口都统一走一个实例，登录鉴权、错误提示、状态码处理都集中在一处。401时自动清理本地登录态并跳转登录页，这个交互逻辑对“token过期”场景的用户体验很重要，否则用户看到白屏没有任何提示。

5.3 核心页面拆解：职位列表、职位详情、简历编辑

职位列表页是整个求职者端最核心的页面。左侧是筛选条件区：关键词搜索框、城市下拉、经验要求单选框、薪资范围滑块，右侧是职位卡片列表，分页加载。点击职位卡片跳转到职位详情页。

筛选条件变化时的处理方式，我这里推荐的做法是：把筛选条件放进一个query响应式对象里，任何一项变化时手动调用接口刷新列表。这种方式比watch深度监听要直观得多，也符合列表中“筛选即查询”的交互预期：

javascript复制const query = reactive({
    pageNum: 1,
    pageSize: 10,
    keyword: '',
    city: '',
    experienceRequired: '',
    salaryMin: null,
    salaryMax: null
})

const search = async () => {
    query.pageNum = 1
    const res = await getJobList({ ...query })
    jobList.value = res.data.records
    total.value = res.data.total
}

职位详情页要展示职位信息、企业信息两块内容。右侧固定一个“投递简历”按钮，点击后前端判断登录角色：

• 未登录跳转到登录页。
• 登录但不是求职者角色，提示“只有求职者账号才能投递”。
• 是求职者但简历不完整，提示引导去完善简历。
• 已经投递过这个职位，按钮变灰，显示“已投递”。

这个交互逻辑看着简单，但非常体现业务细节，建议你在答辩时重点讲一讲。

简历编辑页我采用的是“分块编辑”布局：基本信息、教育经历、工作经历、项目经历、期望职位信息几大区块，每个区块折叠起来，用户按顺序填写。相比一个滚动长页面，这种布局在小屏幕设备上更好用，对用户的心理压力也更小。每个区块里的“添加记录”按钮，用v-for渲染一个数组，支持动态删除，实现起来很顺。

5.4 与后端联调的关键：跨域与接口代理

前后端分离项目，联调阶段最容易卡住的问题就是跨域。后端的跨域配置可以这样写：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

但这里分享一个实际项目中的建议：开发环境用Vite的代理转发，生产环境用Nginx反向代理到后端。也就是说，后端不要在生产环境放开跨域，统一走Nginx。

开发环境的Vite代理配置如下（vite.config.js）：

javascript复制export default defineConfig({
    server: {
        port: 5173,
        proxy: {
            '/api': {
                target: 'http://localhost:8080',
                changeOrigin: true
            }
        }
    }
})

这样的话，前端页面请求的URL是/api/jobs，代理转发到后端服务，纯前端层面就没有跨域问题了。后端CorsConfig也可以保留，但仅用于本地调试场景。

6. 部署文档的完整落地：从开发机到服务器

6.1 后端打包部署的标准流程

部署文档是这套交付物里很重要的一环，很多学生项目跑在本地没问题，一放到服务器上就各种报错，就是因为部署流程没整理清楚。这里我按照实际经验给出一个标准路径。

第一步：本地打包

在项目根目录执行：

bash复制mvn clean package -DskipTests

打包成功后会在target目录生成recruit-platform-0.0.1-SNAPSHOT.jar。这里有个关键点：application.yml里配置的数据库连接、Redis地址等，在打包前必须改成服务器环境的对应配置。很多人忘记这一步，导致jar包在本地测试没问题，一上传服务器就连不上数据库。

第二步：准备服务器环境

服务器建议使用Linux系统。部署前需要安装JDK 1.8或更高版本、MySQL 5.7或8.0、Nginx。如果是Docker部署，还需要安装Docker和Docker Compose。

第三步：上传jar包并启动

把jar包上传到服务器指定目录，然后用nohup启动：

bash复制nohup java -jar recruit-platform-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

查看日志确认启动成功：

bash复制tail -f app.log

看到Started RecruitPlatformApplication的日志输出后，用curl http://localhost:8080/api/jobs测试接口是否正常。这一步不要跳过，在你配置Nginx之前先确认后端服务本身是通的，不然排查问题时会产生大量干扰项。

6.2 前端打包与Nginx配置

在frontend目录下执行：

bash复制npm install
npm run build

构建完成后会生成dist目录，把这个目录里的静态文件上传到服务器的Nginx静态目录，比如/usr/share/nginx/html/recruit。

然后配置Nginx：

nginx复制server {
    listen       80;
    server_name  your-domain.com;

    location / {
        root   /usr/share/nginx/html/recruit;
        index  index.html;
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

这段配置里有几个关键点：

• try_files $uri $uri/ /index.html这句是SPA路由的核心。Vue Router使用的是history模式，用户直接访问/jobs/1时，服务器上没有这个物理文件，Nginx通过try_files把请求重写到index.html，前端路由接管后再渲染对应页面。
• location /api/这个代理块把前端发来的/api请求转发到后端SpringBoot服务的8080端口。这样前端请求就不会暴露后端真实端口，也避免了跨域问题。

配置完成后执行nginx -s reload使配置生效。如果前端用了history模式但没有配置try_files，刷新二级页面就会404，这是我在很多项目里反复见到的部署问题。

6.3 数据库初始化的坑与规避方案

部署文档里一定要包含数据库脚本的执行说明。通常数据库脚本包含create_table.sql（建表语句）和init_data.sql（初始化管理员账号、测试数据）。执行方式：

bash复制mysql -u root -p < create_table.sql
mysql -u root -p < init_data.sql

项目里的数据库连接配置要注意时区问题。MySQL 8.0的JDBC连接串建议加上serverTimezone=Asia/Shanghai，否则可能出现数据库时间比本地时间早8小时的问题。之前在帮别人排查一个“简历更新时间显示不对”的问题时，根源就是这个时区参数缺失，排查了好久。

另一个常见坑是数据库字符集不一致。建表时统一使用utf8mb4字符集，因为默认的utf8在存储表情符号时不够用：

sql复制CREATE DATABASE recruit_platform DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

这个细节如果等部署到服务器上出现乱码再处理就麻烦多了，数据可能要清掉重建，所以建库时一定要写清楚。

6.4 Docker部署的进阶思路

如果部署文档里再附带一个Docker方案，项目的含金量会提升不少。在项目根目录放一个Dockerfile：

dockerfile复制FROM openjdk:8-jre-alpine
WORKDIR /app
COPY target/recruit-platform-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

配合docker-compose.yml把MySQL和SpringBoot一起编排起来：

yaml复制version: '3'
services:
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: root123
      MYSQL_DATABASE: recruit_platform
    ports:
      - "3306:3306"
    volumes:
      - ./mysql-data:/var/lib/mysql

  app:
    build: .
    depends_on:
      - mysql
    ports:
      - "8080:8080"
    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/recruit_platform?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
      SPRING_DATASOURCE_USERNAME: root
      SPRING_DATASOURCE_PASSWORD: root123

有了这个方案，部署时只需要一条命令：

bash复制docker-compose up -d

这个Compose文件的妙处在于：容器内的mysql主机名在同一个Docker网络里可以被app服务直接访问，不需要改成服务器的真实IP。对不懂Linux的小白用户来说，跟着文档跑一遍就能把整套环境拉起来。

7. 这两年带这个项目踩过的几个高频坑

7.1 JWT过期时间设置不合理导致的“用着用着就掉线”

我见过不少人在写JWT工具类的时候图省事，把过期时间设置成2小时或更短，结果演示到一半，页面突然调接口报401，调度数据全部加载不出来了。项目演示的场景非常考验细节，token的有效期设定至少要覆盖整个演示周期。

建议：开发环境设置7天，部署文档里注释写明生产环境再调整为1天或半天。还要处理“刷新token”的逻辑——严格一点的方案是后端提供/api/auth/refresh接口，用户在token即将过期时通过一个长期有效的refreshToken换取新token；简单一点的方案是前端在拦截到401时自动重新登录。对学生项目来说，直接调大有效期是性价比最高的方案，但你要能在答辩时说出“生产环境怎么做”这个延伸方案，才是真正的加分项。

7.2 文件上传的路径与访问配置不一致

企业认证时要上传营业执照，简历模块可能要传头像，这类文件上传功能几乎是必做的。最常见的坑是这样的：上传的文件保存在本地磁盘D:/upload/目录，但前端页面访问的URL是http://localhost:8080/files/xxx.jpg，结果404。

解决这个问题的标准配置是给SpringBoot添加一个静态资源映射，把/files/**路径映射到本地磁盘目录：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/files/**")
                .addResourceLocations("file:" + fileUploadPath + "/");
    }
}

注意file:前缀不能丢，否则SpringBoot会把路径当classpath资源去解析。文件存储路径fileUploadPath最好配置在application.yml里，不要硬编码，这样部署到Linux服务器时只需要改配置不需要改代码。

另外，上传文件的校验也值得写全：文件大小不能超过2MB（SpringBoot的spring.servlet.multipart.max-file-size默认是1MB，不够用的话显式调大），后缀名要做白名单过滤，文件名要用UUID重命名，避免中文文件名和跨平台编码问题。

7.3 前端刷新后路由404或登录态丢失

这两个问题都属于前端“隐形大坑”，没有实操过的人很难提前意识到。

路由404：开发模式下Vite会处理history路由，刷新不报错。但部署到Nginx后，如果你没有写try_files $uri $uri/ /index.html这句，直接访问/jobs/1就会返回404。这个坑我在前面的Nginx配置里提过一次，但必须把它列入高频坑清单，因为它排查起来不直观，很多新人会以为是后端接口挂了，实际上Nginx日志里根本没有任何后端请求记录。

登录态丢失：如果你用的是Vue 3 + Pinia，把token放在Pinia的state里管理，刷新页面后Pinia的state会被重置，如果token只存在内存里，刷新后就丢了。解决方案是把token持久化到localStorage，或者在Pinia插件里配合pinia-plugin-persistedstate做自动持久化。每次刷新时，beforeEach路由守卫里先去localStorage拿token，再判断登录状态，这个流程才不会出现“刷新即退登录”的问题。

7.4 时间字段序列化导致的前端显示“一堆数字”

这是SpringBoot后端和Vue前端联调时非常经典的一个问题。后端返回的LocalDateTime字段，如果没做格式化处理，Jackson默认序列化出来是一个长整型时间戳，前端拿到后显示在页面上就是“1730000000000”这种数字，非常难看。

解决方案有两种：

第一种，在字段上添加@JsonFormat注解：

java复制@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")
private LocalDateTime createTime;

第二种，全局配置Jackson的日期格式化：

java复制spring.jackson.date-format=yyyy-MM-dd HH:mm:ss
spring.jackson.time-zone=GMT+8

第二种适合全局生效，不用每个字段都加注解。但要注意application.yml里的spring.jackson.date-format只对java.util.Date生效，对LocalDateTime不一定有效。如果你用的是Java 8的LocalDateTime，还是需要在字段或配置类里用Jackson2ObjectMapperBuilderCustomizer来处理：

java复制@Bean
public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() {
    return builder -> {
        builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
        builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
    };
}

从项目分工角度说，我推荐后端统一返回格式化后的时间字符串，前端不做任何转换处理，这样前端代码更简洁，也避免不同浏览器对时间字符串的解析差异。

7.5 数据库字段与实体类映射不一致的“玄学报错”

MyBatis-Plus默认开启驼峰命名转换，create_time字段会自动映射到createTime属性。但如果你用了自定义SQL（写在XML里或者@Select注解里），返回的ResultMap如果没有显式定义字段映射关系，就可能出现某个实体属性一直是null的情况。

比如你写了一个多表联查：

sql复制SELECT d.id, d.status, r.real_name, r.expected_position, j.title as job_title
FROM delivery d
LEFT JOIN resume r ON d.resume_id = r.id
LEFT JOIN job j ON d.job_id = j.id
WHERE d.company_id = #{companyId}

返回结果里d.id和d.status能自动映射，但r.real_name对应VO里的realName，需要开启驼峰映射配置，或者SQL里用别名：

sql复制SELECT d.id, d.status, r.real_name AS realName, r.expected_position AS expectedPosition, j.title AS jobTitle

这个问题在本地开发时往往会因为数据库字段和实体类属性恰好同名而幸免，但一旦改了个字段名，或者进入联表查询场景，立刻暴露。建议写Mapper自定义SQL之前，先到application.yml里确认map-underscore-to-camel-case: true已经开启。这个配置在MyBatis-Plus里默认就是开启的，但如果你同时引了原生MyBatis的依赖，就有可能会被覆盖，这种间接的配置冲突是最难排查的。

8. 如果时间充裕，这些扩展点能让项目再上一个台阶

8.1 用Elasticsearch或数据库全文索引优化职位搜索

项目的基础版本用的是数据库LIKE %keyword%查询，数据量小的时候完全没问题。但如果你想让项目在答辩时更有亮点，可以聊一聊Elasticsearch的优化思路。

Elasticsearch的核心价值在于全文检索和分词匹配。一个职位描述里可能有“Java”“Spring Boot”“微服务”“高并发”等一堆关键词，用数据库的模糊查询只能做到字符级别的包含，而ES可以用IK分词器做更智能的中文分词，再结合相关性评分排序，搜索效果会明显更好。

但对毕设项目来说，引入ES的代价是内存占用高、运维成本大。我给的建议是：在文档里写清楚“进阶优化方案”，实际代码可以不做，答辩时表现出“我知道这个问题有更优解”的深度就够了。

8.2 用定时任务做职位过期自动下架

职位发布后，如果长期没有更新，应该自动下架或标记为“已过期”。这个需求非常适合用SpringBoot的@Scheduled定时任务来实现。

java复制@Component
public class JobExpireTask {

    @Scheduled(cron = "0 0 2 * * ?")  // 每天凌晨2点执行
    public void expireJobs() {
        LocalDateTime threshold = LocalDateTime.now().minusDays(30);
        jobMapper.updateStatusByExpireTime(threshold);
    }
}

这只是一个很小的功能点，但体现了对业务完整性的思考。真实招聘平台里这种定时任务非常常见，加进去后项目不再是“纯业务CRUD”，还包含了系统级的功能设计。

8.3 基于FTP或OSS优化文件存储

之前的文件上传方案里，文件存在本地磁盘，这在单机部署场景下没问题。但如果你在项目文档里写出“生产环境应该把文件存储到阿里云OSS或MinIO等对象存储”，并画出架构图说明怎么通过内网访问、怎么配置CDN加速，这个视野就远超普通学生项目了。

如果只想小步改进，也可以使用FastDFS或MinIO做本地私有化对象存储。MinIO是更合适的学习选择：部署简单、有Web管理界面、API兼容S3协议，用Java SDK操作也不复杂。给文件存储模块加一个存储策略接口，把本地存储和MinIO存储做成两种实现类，通过配置文件切换，这是一个非常经典的设计模式应用案例，在答辩时非常加分。

9. 部署文档的写作规范与常见漏洞补全

9.1 一个合格的部署文档要覆盖哪些章节

这套交付物里的“部署文档”不只是给代码配个启动说明，它要能支持一个完全不懂你项目的人，从零开始把你整套系统跑起来。我的经验是至少包含以下章节：

1. 环境要求：JDK版本、Maven版本、Node版本、MySQL版本，写清楚具体版本号与兼容性说明。
2. 数据库初始化：脚本文件路径、执行方式、数据库配置修改位置。
3. 后端部署：打包命令、配置文件修改项（数据库连接、文件上传路径、JWT密钥）、启动命令、日志查看方式。
4. 前端部署：依赖安装命令、构建命令、Nginx配置示例、静态文件放置路径。
5. 访问地址与默认账号：前台访问地址、后台管理地址、初始账号密码。
6. 常见问题排查：端口占用、数据库连接失败、前端请求404、跨域错误等。

9.2 部署文档里最容易缺失的细节

• MySQL版本差异：MySQL 5.7和8.0的驱动名不一样，5.7用com.mysql.jdbc.Driver，8.0用com.mysql.cj.jdbc.Driver。Spring Boot 2.x之后会自动根据连接串识别驱动，但如果你用的不是starter而是手动引入的驱动包，这个坑就会踩到。
• 防火墙/安全组配置：云服务器上要让外部访问8080端口或80端口，需要在安全组里放行对应端口。这个内容很多人的部署文档压根没提，但实际上手时最容易卡住。
• 数据初始化脚本路径：不要只写“执行init.sql”就完了，要写清楚脚本在工程里的绝对路径，例如/root/recruit-platform/sql/init_data.sql，方便操作者定位。

9.3 “lw”也就是论文/设计文档的写作要点

这个项目交付物里有“lw”这个缩写，指的是论文或设计文档。写设计文档时，有几个章节特别容易写“水”：

• 需求分析：不要只写“用户可以进行登录注册”这种一句话需求，要画出用例图，并针对每个用例补充使用场景说明。
• 系统设计：要包含总体架构图、功能模块图、数据库ER图。画图是必须的，光用文字描述，评阅老师看不清系统全貌。
• 核心功能实现：不要贴大段代码，每段代码之前先解释业务场景和设计思路，代码只截取核心部分。
• 测试：至少包含功能测试用例表格，列出测试项、操作步骤、预期结果、实际结果。

我见过不少学生，代码写得能跑，设计文档却一塌糊涂，最后照样被卡。设计文档的写作思路，本质上和这篇博文的章节思路是一致的：讲清楚“为什么这样做”，比“做了什么”更重要。

写到最后想说的大实话

如果你准备用这个项目做毕设、面试项目或自学练手，我最后想给你几个很实际的建议。

第一，不要只满足于“能跑通”。SpringBoot + Vue联调跑通只是及格线。真正让你在答辩或面试时脱颖而出的，是你能说清楚每个模块的“为什么”：为什么简历用主表+子表结构、为什么投递记录要加唯一约束、为什么前端要配路由守卫、为什么生产环境要用Nginx代理而不直接跨域。这些问题在本文里我都给了详细答案，你把它们吃透，项目的含金量完全不一样。

第二，把项目代码和部署流程当成一套完整的产品去维护。代码仓库的README要有项目简介、技术栈、快速启动方式；配置文件的敏感信息要抽出来用环境变量管理；数据库脚本要保证在干净环境下从零执行不出错。这些习惯在真实开发中是基本功，从学生时代就养成，对你以后找工作或带项目都大有帮助。

第三，源码拿到手之后，先不要急着到处点，按顺序做三件事：看一眼数据库的ER图或建表SQL，明白表之间的关系；启动后端，用Swagger或Postman把每个接口调一遍；启动前端，在页面上把每个流程走一遍。走完这三步，你才真正拥有了这套代码，而不是只是“拥有这套代码的副本”。