企业官网建设流程全解析

每年三四月份，后台私信就会被“基于SpringBoot和Vue3的毕业生信息管理系统该怎么做”刷屏。标题可以拆出好几个版本——毕业生信息管理系统、高校毕业生就业信息服务平台、大学生求职就业数字化管理，但核心诉求其实是一样的：让毕业生能维护简历、浏览岗位、在线投递，让企业能发布职位、筛选人才，让学校就业部门和辅导员能掌握毕业生去向、做就业统计。这个题目在计算机毕业设计里热度一直很高，但恰恰是这种“听起来不难”的题目最容易翻车。很多同学写着写着就把它降级成了又一个增删改查脚手架，业务逻辑薄得像张纸，答辩时被老师问一句“你系统的就业状态是怎么流转的”就卡壳。这篇文章我就把这套系统背后真正值钱的业务设计和技术细节拆开讲清楚，给正在选这个题的同学一份能照着动手的完整参考。

1. 先看清全貌：就业平台承载的不只是增删改查

1.1 三类用户和三类诉求

做毕业设计最容易犯的错，是拿到题目就开建表，建完表就写CRUD，写完就以为完了。但“毕业生信息管理系统”这个名字，暗示的是一套服务于高校就业工作的完整业务闭环。你可以没有多复杂的算法，但必须把业务场景想清楚。

这套系统通常有三类用户，各自的诉求完全不同：

• 毕业生（学生）：想管理个人基本信息、填简历、看招聘会、查岗位、投简历、收面试通知、被录用后做就业登记。他们关心的是“我能否方便地找到适合自己的工作”。
• 企业招聘人员（HR）：想注册企业、发布招聘岗位、查看收到的简历、联系学生、管理招聘进度。他们关心的是“我能否高效筛到合适的人”。
• 学校管理人员（辅导员、院系管理员、就业中心）：想看本院系/全校学生的就业进度，包括毕业生人数、已签约人数、就业率、未就业学生名单，可能需要审核企业入驻或岗位发布。他们关心的是“我能否准确掌握就业数据，及时帮扶未就业学生”。

注意第三类人往往被很多毕设忽略。但“管理”二字恰恰落在他们身上——纯粹给毕业生和企业用的系统叫招聘网站，加上学校管理端的视角，才叫毕业生信息管理系统。

1.2 就业状态机：避不开的核心业务约束

什么是这套系统区别于普通CRUD的灵魂？答案是毕业生的就业状态流转。

一个学生从大四开始到离校，大致会经历：求职中 → 已投递 → 面试中 → 已录用 → 已签约 → 已就业/派遣。中间还可能出现放弃录用、解约、灵活就业等分支。不同角色在不同状态下的操作权限是不同的：

• 学生投递岗位后，状态从“求职中”变为“已投递”，自己不能重复投同一岗位。
• 企业将学生标记为“面试中”或“已录用”后，学生端应能看到对应反馈。
• 学生填写就业登记并通过审核后，系统里才计入已就业人数。

这其实是一个状态机问题。我在指导毕设时最强调的一点就是：业务实体不只是被增删改查，还要有合法状态流转的约束。比如你自己若在投递接口里不校验学生当前状态，就会出现一个“已签约”的学生还能继续投简历的尴尬场景。哪怕只是几个简单的状态字段+if校验，也足以让你的答辩内容从“我写了CRUD”升级成“我实现了带状态的业务流”。

1.3 模块划分和权限边界

基于上述角色分析，功能模块可以这样切：

权限边界是另一个很容易写糊的地方。我的建议是不要一开始就上Spring Security那套复杂的注解权限，先明确“按钮级权限只限于管理端，学生端和企业端做菜单隔离就够了”。很多毕设系统往往把学生能访问的接口和管理员能访问的接口混在一起，这会让后面的安全配置非常被动。

2. 技术栈雏形：SpringBoot与Vue3的选型细节

2.1 版本适配从第一行配置就开始

确定用SpringBoot+Vue3之后，第一个坑往往出现在版本上。SpringBoot 3.x要求JDK 17及以上，如果你的电脑上只装了JDK 8，又辛辛苦苦按新教程敲代码，会发现编译狂报错——那不是你写错了，是版本根本不对。稳妥的做法是：本机是JDK 8，就老老实实用SpringBoot 2.7.x；本机是JDK 17，才建议用SpringBoot 3.x。

对应地，MyBatis-Plus也有版本差异。SpringBoot 3.x要用mybatis-plus-spring-boot3-starter（目前主流是3.5.3+），SpringBoot 2.x则用原来的mybatis-plus-boot-starter。如果你在pom.xml里引错，启动时就会出现一堆ClassNotFoundException，光排错就得折腾半天。

前端方面，Vue3搭配的构建工具通常选Vite，不再用Vue CLI。原因很实际：Vite冷启动快，开发时修改页面秒级热更新，毕设后期改样式改布局的时候体验差距巨大。Vite对Node版本也有要求（一般建议Node 18+），装完Node之后跑npm create vite@latest即可把项目骨架拉起来。

2.2 为什么用MyBatis-Plus和JWT

ORM选型上，原生MyBatis写SQL很灵活，但业务里大量单表操作——用户、简历、岗位、投递记录，每张表都手写一套insert/update/select会把人写疯。MyBatis-Plus的价值在于单表CRUD可以零SQL完成，同时保留了自定义SQL的入口，正好匹配毕设场景。建一个实体类，继承BaseMapper<T>，基础的增删改查、分页查询就都有了。

认证选型上，我推荐JWT而不是session。两者都能实现登录，但前后端分离架构下，JWT让后端不关心session存储，前端拿到token存起来每次请求带上即可。这对Vue3端很友好。另一个理由是答辩时可以顺便讲清楚“无状态认证”和“传统会话认证”的差异，属于加分项。

2.3 前端框架选型的取舍

Vue3的UI组件库，目前生态最成熟的是Element Plus。表格、表单、对话框、分页、上传这些组件都覆盖得到，做管理后台类页面效率极高。学生端页面如果你想做得更年轻化，也可以考虑Naive UI，它基于TypeScript，样式更现代，但组件数量和社区问答量不如Element Plus。毕业设计求稳的话，Element Plus优先。

另一个细节是Vue3的写法。你可能会在Option API和Composition API之间纠结，我的建议是直接用Composition API（<script setup>语法）。Vue3官网已经明确推荐<script setup>，网上新教程也基本全是这种写法，代码组织可读性反而比Vue2时代的data/computed/methods更清晰。面试时被问到两者区别，也能顺势讲出Composition API解决逻辑复用问题的原理。

3. 数据库是地基：十来张表怎么撑起求职闭环

3.1 账号权限体系的标准做法

数据库设计是这种业务系统的重头戏。我通常建议至少设计12~15张表，以下这些是可以直接落地的核心表结构：

用户相关：

• sys_user：账号表，字段包含id、username、password（加密存储）、real_name、phone、email、user_type（学生/企业/管理员）、avatar、status、create_time。
• sys_role、sys_menu、sys_user_role、sys_role_menu：标准的RBAC四件套，管理端菜单权限会用到。

学生信息相关：

• student_info：学号、姓名、性别、学院、专业、班级、学历、毕业年份、生源地、联系方式、政治面貌等。
• resume（简历表）：学生id、期望岗位、期望城市、期望薪资、技能标签、自我评价、附件url、是否公开。
• education_experience、work_experience、project_experience：这三张是可拆可不拆的。如果毕设时间紧，可以把教育经历和工作/项目经历作为JSON字符串或者富文本内容存到resume表里，用文本域编辑，减少大量子表单的复杂度。

企业招聘相关：

• company_info：企业名称、统一社会信用代码、行业类别、规模、简介、logo、联系人、联系电话、地址、审核状态。
• positions（岗位表）：企业id、岗位名称、岗位类别、薪资范围（下限/上限）、学历要求、工作城市、招聘人数、岗位描述、职位标签、发布时间、下线时间、状态（上架/下架）。

核心业务连接：

• job_application（投递记录表）：学生id、岗位id、企业id、投递时间、状态（待筛选/面试中/已录用/已拒绝/已取消）、简历快照url或文本、更新时间和企业备注。
• job_favorite（岗位收藏表）：学生id、岗位id、收藏时间，用于“我的收藏”功能。
• employment_info（就业登记表）：学生id、就业状态（已签约/灵活就业/升学/暂未就业）、签约单位、单位性质、岗位类别、薪资、签约时间、审核状态、审核备注。

辅助沟通：

• message_notice（站内消息表）：发送者id、接收者id、消息类型、内容、已读状态、创建时间。无论是企业发面试邀请，还是学校发通知，都走这一张表。

3.2 简历、岗位、投递三张核心表的设计细节

先说简历表。最容易被忽略的是技能标签字段。它看起来只是个字符串，但后续“系统推荐岗位”功能要靠它做匹配。所以建议给resume表加skill_tags（以逗号或JSON数组存储），同时给positions表加job_tags（职位标签），推荐算法可以对两者做交集计算。

再说岗位表。薪资范围建议拆成salary_min和salary_max两个字段，而不是一个字符串。因为后续做条件筛选时，SQL里可以简单写WHERE salary_min <= #{期望薪资} AND salary_max >= #{期望薪资}。我之前见过有同学用一个salary_text字段存“8k-15k”，筛选时用正则去解析，又麻烦又容易出错。

投递记录表是连接学生和企业的枢纽，状态字段要设计得足够细。这里给出我常用的状态枚举：PENDING（待筛选）、INTERVIEW（面试中）、OFFER（已录用）、REJECTED（已拒绝）、WITHDRAWN（已撤回）。注意：面试邀请记录尽量单独处理，可以在投递记录表里加一个interview_time和interview_location字段，企业确认后生成消息推给学生，比额外建一张面试表更省事。

3.3 就业统计的数据来源设计

管理端最关心的是就业统计，包括总体就业率、分专业就业率、未就业名单、就业去向分布。这些数据主要有两个来源：

一是student_info表中的employment_status字段，二是employment_info表中的审核通过记录。为避免口径冲突，建议以employment_info表审核通过的记录为准，student_info里只存一个冗余状态，方便列表页直接展示和筛选。统计SQL的写法可以类似：

SELECT major, COUNT(*) AS total_students, SUM(CASE WHEN ei.id IS NOT NULL THEN 1 ELSE 0 END) AS employed_count FROM student_info si LEFT JOIN employment_info ei ON ei.student_id = si.id AND ei.audit_status = 'APPROVED' WHERE si.graduation_year = 2025 GROUP BY si.major;

这种SQL在答辩论证时拿出来讲非常有说服力，因为它既说明了你理解指标口径，也展示了SQL聚合能力。

另外，别忽略索引设计。job_application表的student_id、position_id，positions表的company_id、status，student_info表的major、employment_status，这几列在频繁查询条件里出现，务必要加索引。数据量不大，但加索引这件事本身可以在答辩时讲一讲。

4. 后端实现：接口不是堆CRUD，而是处理“状态”

4.1 登录鉴权与安全拦截

后端起步先把统一返回体和异常处理搭好。我习惯定义Result<T>类，里面放code、message、data三个字段，所有接口统一返回这个结构。配合@RestControllerAdvice做全局异常捕获，这样业务代码里就不用到处套try-catch。

登录接口的核心逻辑：

// 校验用户名密码，密码用BCrypt加密后比对 @PostMapping("/login") public Result<String> login(@RequestBody LoginDTO dto) { User user = userService.getOne(new LambdaQueryWrapper<User>() .eq(User::getUsername, dto.getUsername())); if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } String token = JwtUtil.generateToken(user.getId(), user.getUserType()); return Result.success(token); }

JWT工具类里要做的就是把userId和userType放进去，设置一个有效期（毕设场景设24小时或7天都行）。关键是后续加一个拦截器，在所有需要登录的请求上校验token。SpringBoot 2.x可以注册HandlerInterceptor，SpringBoot 3.x用WebMvcConfigurer的addInterceptors方法。拦截器里解析token拿到当前用户id，放进ThreadLocal或Request attribute，后面的业务逻辑直接取。

这里有个很实用的细节：像岗位列表、招聘会信息这类公开数据接口，可以放进排除拦截的路径里，否则学生未登录时连查看岗位都看不了，演示起来体验很差。建议放行路径包括/api/auth/login、/api/auth/register、/api/positions/list（公开浏览）、/api/companies/list（公开浏览）。

4.2 招聘流程接口的幂等设计

投递这个动作，看起来简单，做起来有讲究。学生点击“投递简历”，前端调POST /api/applications。后端至少要校验三件事：

1. 学生当前是否处于“求职中”或“已投递”状态，如果已经“已就业”，不允许再投。
2. 该学生是否已经投过该岗位——防止重复投递。可以在job_application表上建唯一索引(student_id, position_id)，也可以先查后插。
3. 岗位是否还在有效期内（offline_time是否大于当前时间），以及是否已下架。

第2点最好用数据库唯一索引做兜底，因为并发下先查后插会存在漏网之鱼。虽然毕设系统并发量不高，但“唯一索引兜底”这个意识在答辩时能体现出你的工程素养。

企业端的处理流程则是：查看投递列表 → 点击“邀约面试”（写面试时间和地点）→ 系统生成站内消息推送给学生 → 学生确认后反馈状态。这里状态的流转点很多，建议在job_application实体类里建一个statusHistory字段或用单独的status_change_log表记录轨迹——哪怕只存一个JSON，也方便你答辩护盘时展示流程。

4.3 简历匹配和统计报表的实现

简历匹配如果不做复杂的算法，可以基于标签取交集。举个例子：

// 伪代码：根据学生技能标签推荐岗位 String[] skills = resume.getSkillTags().split(","); List<Position> positions = positionService.list(); List<Position> matched = positions.stream() .filter(pos -> containsAnyTag(pos.getJobTags(), skills)) .filter(pos -> pos.getSalaryMin() <= resume.getExpectedSalary()) .sorted(Comparator.comparingInt(p -> matchCount(p, skills)).reversed()) .limit(20) .collect(Collectors.toList());

这种实现简单、效果直观，而且比纯SQL好讲。等有余力，可以加一个“看过这篇岗位的同学还看过”的协同过滤或基于历史行为统计，但那属于锦上添花，不是必做项。

统计报表接口就按前面设计的SQL来。推荐用MyBatis-Plus的自定义@Select注解写统计SQL，返回List<Map<String, Object>>，前端拿到之后直接用ECharts画饼图、柱状图。这样比在Java代码里层层group by要高效得多，也方便你调整口径。注意：如果不装ECharts，只展示表格数字，管理端的‘可视化’亮点基本就没了，所以我强烈建议前端集成一下ECharts，哪怕只画两张图，答辩展示效果会好很多。

5. Vue3前端：交互密集和管理后台的差异化开发

5.1 权限路由与Pinia状态管理

前端工程的第一步不是写页面，而是把路由和状态管理搭好。Vue3推荐用Pinia替代Vuex，API更简洁。存储的内容主要是：当前登录用户的token和userInfo。token要持久化到localStorage，刷新页面后从localStorage恢复，交给Axios拦截器统一加到请求头里：

// request.js 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 = `Bearer ${token}`; } return config; }); request.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); router.push('/login'); } ElMessage.error(error.response?.data?.message || '请求失败'); return Promise.reject(error); } );

路由守卫里根据用户类型控制页面访问。这里逻辑要清晰：学生端路由以/student开头，企业端以/company开头，管理端以/admin开头。在router.beforeEach里判断userType，如果访问了不属于自己类型的路由，直接重定向到各自首页。这样实现简单，也符合“菜单级权限”的项目定位。

5.2 面向学生的求职页面：岗位浏览、筛选与投递

学生端是前后端交互最密集的部分。岗位浏览页建议做成一个以岗位卡片为主的列表，左侧筛选栏放关键词、城市、学历、薪资范围。列表分页用Element Plus的el-pagination，每页10条或20条，后端接口用一个PageResult<T>统一返回total和records。

这里有一个开发常见坑：Element Plus的el-select配合远程搜索时，v-model绑定的值和options里label的对应关系容易错，导致下拉框选中后显示的是数字id而不是文本。解决办法是el-select的value-key字段要与option的默认字段名策略保持一致，或者用el-option时直接v-model绑定对象。为此我建议前端封装一个“字典翻译”的工具函数，通过字典编码在后端查列表，返回给label字段，避免硬编码。

投递交互的关键点是：点击“投递”按钮后，前端要先把当前简历的完整内容做快照提交（后端存一份简历快照），这样即使学生之后改了简历，企业看到的仍然是投递那一刻的版本。这个业务点如果能在代码里实现，在答辩论“需求分析”时就是非常漂亮的一个设计点。

5.3 面向后台的数据表格：性能与体验的平衡

管理端页面通常由“搜索表单 + 数据表格 + 分页 + 操作列”组成，Element Plus的el-table基本能覆盖所有需求。要注意的是大数据量下的渲染性能：后端分页一定要做好，前端不要一次拉全量数据。如果某张表的数据超过几千行，el-table开启stripe和border后依然可能卡，不要开懒加载或者虚拟滚动，老老实实分页即可。

对于就业统计页面，前端用ECharts +el-card布局，分别放总体就业率、专业就业率柱状图、就业去向饼图、最新未就业名单表格。这些图表的data都来自统计接口，在页面onMounted里用一个Promise.all并行请求，减少等待时间。前端代码里有一个容易踩的小坑：ECharts实例在窗口大小变化或Tab切换后需要调用resize()，否则图表会变形。封装一个useEcharts组合式函数，统一管理初始化、setOption和resize，能省掉很多重复代码。

6. 从联调部署到答辩演示：最后一公里别掉链子

6.1 跨域、代理与打包的三种组合

开发阶段前后端联调，最常遇到的就是跨域。最简单的方案不是在后端写@CrossOrigin，而是让前端用Vite的devServer做代理。在vite.config.js里配置：

server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端代码里请求/api/login，开发环境会自动转发到后端8080端口，避免跨域。后端在spring配置里也要允许前端来源的跨域请求，两种方式任选一种即可，不要同时用，免得出现“明明能通但总是报错”的奇怪问题。

生产部署有两种主流方式。第一种是前后端分开部署：后端打包成jar包（mvn package），前端npm run build生成静态dist目录，交给Nginx托管，Nginx里配一个/api的location反向代理到后端8080端口。这种方案贴近企业真实部署方式，答辩时值得讲一讲。

第二种是把前端dist目录直接拷进SpringBoot的src/main/resources/static下，后端一个jar包全搞定。这种方式演示最省事，但需要注意：前端用了vue-router的history模式时，刷新页面会404，需要在后端放行所有页面路由，或者改回hash模式。我比较推荐毕设演示用hash模式打包，省心不踩坑。

6.2 答辩演示的数据准备和讲法

很多同学平时测试用的是自己注册的几个测试账号，数据乱、字段不全，答辩现场演示时一页一页翻，老师根本看不出系统价值。答辩前必须准备一套可演示的完整数据：

• 至少3个学生账号，分别处于求职中、已投递并收到面试、已签约三种状态。
• 至少5家企业，覆盖互联网、教育、制造等不同行业，每家企业下两三条有效岗位。
• 至少布置20条投递记录，让统计页面的图表有东西可画。
• 准备一份包含项目经历、技能标签的完整简历，作为简历解析和匹配推荐的演示案例。

演示顺序建议按业务故事讲：先以学生身份登录，浏览岗位，搜索筛选，投递简历 → 切换企业账号，查看收到的简历，发送面试邀请 → 切回学生账号，看到消息通知和面试状态 → 学生填写就业登记 → 切换管理员账号，查看就业率图表和未就业名单 → 最后可以演示一下用户管理、公告发布这类收尾功能。

这个讲法最大的好处是让老师跟着你的业务流程走一遍，而不是看你在各个菜单间无规则切换。答辩时被问到“系统有哪些亮点”，可以从三个角度回答：“业务上实现了就业状态闭环流转”“技术上前后端分离、JWT认证、基于标签的岗位匹配”“工程上做了唯一索引防重复投递和Nginx反向代理部署”。这三个点都写在代码里，老师怎么追问都不怕。

这套系统做到最后你会发现，真正让你和同学拉开差距的，并不是用了多新的框架，而是有没有把业务链条走通、有没有把状态流转讲清楚、有没有把该考虑的数据边界考虑到。我每年看毕设答辩，最见高下的往往就是这个点——不是谁的页面更好看，而是谁能把自己的系统当成一个真实产品去解释它的业务逻辑。提前把这些细节磨好，答辩那十几分钟你会特别从容。