企业官网建设流程全解析

每年毕业季，就业指导中心的老师们都会面对一个老难题：几百份纸质简历堆在桌上，签约数据散落在不同电脑的Excel表格里，统计一次就业率要来回核对好几天。我当时接到这个需求，第一反应就是这活儿该交给一套在线系统来干。于是从需求梳理到数据库设计，再到前端页面，我们做了这套基于SpringBoot+Vue的大学生就业服务平台管理系统，后端用MyBatis操作MySQL，前后端完全分离。这篇博文把整套项目的设计思路、核心实现和部署过程完整复盘一遍，给正在做同类毕业设计或课程项目的同学一个可以直接参考的完整样本。

1. 这个系统到底在解决什么问题

1.1 一个在校生视角的就业业务流程

先别急着谈技术，我们需要弄清楚就业服务平台背后真实的业务链条。假设一所高校有五六千应届毕业生，企业要来发布招聘岗位，学生要上传简历、浏览职位、投递申请，辅导员要审核学生的就业协议，就业办要统计各专业的去向落实率。这套流程如果完全靠人工，最痛苦的不是某一环，而是信息反复填、数据对不上、状态没人更新。

比如A同学在学校就业网站投了一家公司的开发岗，公司HR通过电话确认了签约意向，A同学把三方协议交到辅导员那里登记。这件事在纸质流程里至少要经过四五个人的手，每个人手里都有一份"最新版"Excel。等就业办要统计表时，发现某个学生的签约状态在辅导员表和HR表里互相矛盾，还得一个个打电话核实。

我们的系统就是围绕这条链路设计的：企业端维护招聘信息，学生端管理简历和投递记录，教师端审核签约和发布通知，管理员端看全局统计。每个角色的页面看到的数据都是同一套数据库里的实时值，不再存在"多份Excel打架"的情况。

1.2 角色划分与权限模型

整个系统我按四个角色切分权限，这也是最贴近实际业务的划分方式：

• 学生：注册登录后可以维护个人简历、浏览职位、投递简历、查看投递状态、收到录用通知。
• 企业：发布和下线职位、查看收到的简历、对投递学生进行初筛标记。
• 教师/辅导员：查看本班学生就业进度、审核就业协议、发布学院通知。
• 管理员：管理所有用户、审核企业资质、维护基础数据（专业列表、城市列表）、查看全校统计报表。

权限模型落在代码里其实就是一张用户表和角色字段，再配合前端的路由守卫和后端的接口拦截。后端根据当前登录用户角色判断该请求是否允许执行，前端根据角色动态渲染菜单项，两边同时控制才足够安全。后面第4章我会专门讲JWT拦截的实现细节。

1.3 管理端统计报表的业务含义

管理端最核心的不是CRUD，而是那张就业统计报表。因为每年学校要上报各专业就业率、协议就业人数、灵活就业人数，这些数字必须从投递和签约状态里自动算出来，不能手工填。

我在设计统计模块时把口径固定为三张基础表：学生表、职位表、投递记录表，统计时按专业分组，计算已签约和已就业的人数占总人数比例。状态字段的取值决定了一个学生算不算"已就业"，比如协议就业、合同就业、灵活就业都算，而"待签约"和"未就业"不算。前端用折线图和饼图展示这些数据，每年就业评估的时候老师们直接导出Excel就行，不用再手动合并多份表格。

2. 技术选型的真实理由：SpringBoot、Vue、MyBatis、MySQL怎么凑到一起的

2.1 SpringBoot：从SSH到SpringBoot的必然选择

很多同学纠结毕业设计要不要用Ssm框架，我的建议是这类就业管理平台优先考虑SpringBoot。为什么？因为SpringBoot带来的最大收益是简化了项目配置，不用再写一堆XML里的Bean定义，内嵌Tomcat也让部署变得轻量。对比传统的Ssm，SpringBoot把大部分自动配置都封装好了，开发效率更高，代码结构也更清晰。

选型时我也认真权衡过SpringCloud微服务方案，但这是一个中小型管理系统，核心业务在同一个数据库里就能完成，拆成微服务只是徒增成本。对于这种单体应用完全够用的场景，微服务带来的分布式事务、服务发现、链路追踪都是负担。我的原则很简单：业务复杂度还不高的时候，单体应用就是最好的架构。

2.2 Vue：前后端分离带来的开发体验

前端选择Vue 2配合Element UI，主要是因为生态成熟、上手门槛低，而且组件库对管理系统的适配度很高。表格、表单、分页、弹窗这些后台管理的高频组件几乎都是开箱即用，能省下大量写样式的时间。

更重要的是前后端分离模式下，后端只需要提供RESTful接口，前端用Axios调用并渲染页面，两边可以并行开发。我和另一位同学在实际开发时，他负责前端页面，我负责后端接口，只要提前把接口文档定义清楚，效率比传统JSP模板高了不止一截。前端代码我使用的是Vue Router做页面跳转，Vuex存登录状态和全局用户信息，这些组合在处理权限控制时非常自然。

2.3 MyBatis和MySQL：数据层的最稳妥组合

MyBatis相比Spring Data JPA更贴近SQL本身，适合业务中大量统计查询的场景。例如多表关联查询、分组统计、条件拼接，用MyBatis的XML映射文件写起来非常直观，我甚至可以先把SQL在数据库客户端里调通，再复制到映射文件里，排错成本非常低。

MySQL则是最主流的开源关系型数据库，使用门槛低，部署运维的文档多，遇到问题基本都搜得到解决方案。对于就业服务平台这种数据量大但并发量不高的系统，MySQL的性能完全足够，配合数据库索引设计，即使数据量到了十万条级别，日常查询也能保持毫秒级响应。

3. 核心功能模块与数据库表结构设计

3.1 用户三表到底怎么建

先看用户模块，我没有把学生、教师、企业分别建表，而是统一放一张用户表，用role字段区分身份。这样设计的好处显而易见：登录接口只需要查一张表，权限拦截只需要判断一个字段，管理员管理用户时也只需要处理一张表。缺点是不同角色的个性化字段会比较多，所以允许部分字段为空。

核心字段大致是：id、username、password、real_name、role、phone、email、create_time，学生额外关联major_id表示专业，企业记录company_name和industry字段。密码我建议存MD5加盐后的密文，虽然现在更推荐BCrypt，但MD5方案在课设里还是比较常见，只要不在公网暴露数据库风险就可控。

3.2 招聘信息与投递记录的业务表设计

招聘职位表是第二个核心表，字段包括id、title、company_name、industry、work_city、salary_range、education_requirement、description、status、create_time。status用来控制职位上架还是下架，企业可以随时调整，管理员也能在异常情况下强制下架。

投递记录表则是打通学生和企业的桥梁，字段为id、user_id、job_id、status、update_time。这里的status我设计了完整的状态流：0-待查看、1-已通过初筛、2-已拒绝、3-录用。企业查看简历后更新状态，学生端就能实时看到进度。为了保证一个学生对同一个职位只能投递一次，我使用了一条带NOT EXISTS的INSERT语句，这个设计后面细聊。

3.3 统计报表如何用一条SQL实现

就业率的统计如果是用代码逐条计算，性能会很差，正确做法是尽可能让SQL自己完成。我写了这样一段核心统计SQL：

SELECT m.name AS major_name, COUNT(u.id) AS total_count, SUM(CASE WHEN u.employment_status IN (1,2,3) THEN 1 ELSE 0 END) AS employed_count FROM student_info u LEFT JOIN major m ON u.major_id = m.id GROUP BY m.name;

这里student_info表里存了学生的就业状态字段，管理员端展示时再用employed_count除以total_count得到就业率。如果还需要筛选不同学院或者不同年级，只需要在WHERE条件里增加对应字段即可，扩展起来非常方便。

4. 核心接口实现：从登录鉴权到简历投递

4.1 JWT登录与后端权限拦截

用户登录成功后，后端会生成一个JWT令牌返回给前端。JWT里我放了用户id和角色字段，有效期设置为24小时，令牌本身带签名，每次请求时后端校验签名是否合法，同时解析出当前用户是谁。

@PostMapping("/login") public ResultVO login(@RequestBody LoginDTO dto) { User user = userMapper.getByUsername(dto.getUsername()); if (user == null || !MD5Util.verify(dto.getPassword(), user.getPassword())) { return ResultVO.error("用户名或密码错误"); } String token = JwtUtil.generateToken(user.getId(), user.getRole()); return ResultVO.success(new LoginVO(token, user.getRole(), user.getRealName())); }

后端权限拦截我直接在Spring的Interceptor里写了一个JwtInterceptor，注册时配置对应的路径规则，比如/admin/**必须管理员才能访问。每次请求进来先取Header里的Authorization字段，调用JwtUtil解析，如果令牌无效直接返回401。这样核心接口的权限控制就统一收口了，不用在每个Controller里重复写判断逻辑。

4.2 投递简历的防重复与并发处理

学生投递简历这个操作看着简单，实际有坑。如果学生在两秒内连点了两次投递按钮，发出两个请求，就可能在数据库里插入两条重复的投递记录。前端的按钮加loading只是防君子不防小人，真正可靠的做法是在数据库层面做唯一约束。

我设计了两种方案结合使用：一是给投递记录表加唯一索引(apply_user_id, apply_job_id)，二是改用INSERT...SELECT WHERE NOT EXISTS语句，保证重复插入直接失效。

<insert id="insertApply"> INSERT INTO apply_record (user_id, job_id, status, create_time) SELECT #{userId}, #{jobId}, 0, NOW() WHERE NOT EXISTS ( SELECT 1 FROM apply_record WHERE user_id = #{userId} AND job_id = #{jobId} ) </insert>

这条SQL的执行效果是：如果该学生已投过该职位，新数据插不进去，但也不会报错，只会影响行数为0。接口层再判断返回值，如果为0就提示"您已投递过该职位"，这样无论多少个并发请求过来，数据库都能保证最多只有一条记录。

4.3 前端路由守卫和状态管理

前端我用Vue Router的全局前置守卫控制页面访问权限，每次跳转前读Vuex里保存的用户角色，如果目标路由要求特定角色而当前用户不匹配，就直接跳到403页面。另外我们会把JWT存在localStorage里，页面刷新时从localStorage恢复登录态，避免刷新后丢了登录状态。

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

这个方案在公司项目里可能不算最严谨，但在管理类系统里够用且逻辑清晰，后续如果要接入更复杂的权限体系，重心应该放到后端接口权限上，前端只是体验层的控制。

5. 源码部署：从解压到全流程跑通

5.1 环境准备清单

源码拿到手之后，我建议先花十分钟把环境准备齐全再动手，否则中途启动失败很容易打击信心。部署这套项目实际需要的环境如下：

• JDK 1.8 或 JDK 11，两者都测试过可以正常跑。
• MySQL 5.7 或 8.0，注意驱动类略有区别。
• Maven 3.6 以上，用于编译后端项目。
• Node.js 14 以上，用于前端依赖安装和构建。
• Nginx（可选），如果要把前端和后端都部署到一台服务器上时使用。

5.2 后端配置修改与启动

先把项目里的SQL脚本文件导入MySQL数据库，脚本里包含了建库、建表和初始数据。然后打开后端工程的application.yml文件，修改三个地方：数据库地址、用户名、密码。这块最容易出问题的是MySQL 8默认使用的驱动类变成了com.mysql.cj.jdbc.Driver，如果yml里还在用旧的com.mysql.jdbc.Driver就会启动失败。我用的配置大致如下：

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

配置改完后，在项目根目录执行mvn spring-boot:run，后端默认监听8080端口。看到控制台输出"Started Application"就说明启动成功了。这一步如果报端口占用，就在application.yml里换一个端口，比如8081。

5.3 前端构建与Nginx部署

前端目录进入后先执行npm install安装依赖，如果你的网络环境不稳定，可以配置一下国内镜像源再装，速度会明显提升。依赖装完执行npm run build，构建完成后会在dist目录生成打包好的静态文件。

本地开发阶段前端是通过Vue CLI启动的devServer访问8080端口，需要配置代理转发后端接口请求。正式部署时，我把dist目录里的文件放到Nginx的html目录，并在nginx.conf中配置一条代理规则，把/api开头的请求转发到后端服务：

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

这样用户访问80端口就是前端页面，页面里的接口请求经Nginx转发给后端，前后端完全隔离，以后单独升级任何一端都不会影响另一端。

6. 部署联调阶段我踩过的坑与排查链路

6.1 时区问题导致的时间全乱了

第一次把项目部署到服务器上测试时，数据库里create_time字段全部比北京时间慢了8个小时。排查了很久才发现是MySQL连接URL里没有指定serverTimezone参数，默认使用了服务器系统时区。解决方案就是在数据源URL末尾加上serverTimezone=Asia/Shanghai，同时确认MySQL服务本身时区设置正确，这个问题马上消失。这个问题很典型，本地开发因为电脑本身是北京时间，不容易暴露，换到云端服务器就立刻现原形。

6.2 跨域问题：前端访问后端接口被拦

前端开发服务器是localhost:8081，后端接口是localhost:8080，浏览器直接请求会报跨域错误CORS。这个错误本质上是因为浏览器出于安全策略，不允许页面里的AJAX请求访问不同端口的接口。解决方式我在后端加了一个统一配置的跨域过滤器，允许所有来源访问，同时处理了OPTIONS预检请求。如果你用的是Nginx部署，其实也可以通过反向代理规避，把前后端放到同一个域名下自然就不存在跨域问题了。

6.3 MyBatis查询结果字段全部为null

这是一个非常隐蔽的坑。MyBatis默认有驼峰转下划线映射功能，但SpringBoot配置里如果没有显式开启，数据库字段create_time就无法自动映射到Java属性createTime上，导致查询结果里所有多单词字段都是null。我当时排查了很久，一度以为是SQL写错了，后来检查配置文件发现缺少一行配置：

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

加上之后重启，查询结果马上恢复正常。这个配置建议在新建项目时就直接写好，省得后面出现问题还要花半天时间定位。

6.4 上传简历附件时的文件大小限制

学生上传简历附件时，如果PDF文件稍大几MB，后端会直接报MaxUploadSizeExceededException。SpringBoot默认的上传文件大小限制只有1MB，需要手动调大。我配置了两种环境的取值范围：

spring: servlet: multipart: max-file-size: 20MB max-request-size: 20MB

如果你还要在云端存储简历附件，另外还要注意服务器上磁盘的存储目录权限问题，否则文件明明显示上传成功了，实际却写不进磁盘。

7. 这套源码还可以怎么扩展

7.1 增加消息通知功能

现在系统里的状态流转都是学生主动刷新页面才能看到变化，体验相对被动。实际使用中比较舒服的体验是站内消息通知：企业更新了投递状态，学生一登录就看到未读数。在现有表结构上增加一张message表，关联接收者用户id、消息内容、是否已读，然后在状态更新的地方同时插入消息记录，这个扩展并不会给系统增加太大负担。

7.2 接入可视化大屏

就业统计如果只是简单的表格和饼图，领导看着还是不够直观。可以引入大屏展示方案，把今日新增职位数、累计投递数、各专业就业率这些核心指标做成实时刷新的可视化图表，投屏到办公室展示大屏上。前端只需要定时轮询统计接口，配合图表动画，效果立刻上一个档次。

7.3 智能推荐岗位

如果你希望系统更有亮点，可以给学生增加岗位推荐功能。基于学生填写的专业、技能标签和职位表里的行业、技能要求做关键词匹配，给每个职位算出一个匹配度分数，按分数高低推荐给学生。这个功能在毕设答辩时非常加分，因为它涉及到一点算法思路，又不是特别复杂。

我自己的体会是，这种管理系统最大的价值不在于用了多新的技术，而在于真正贴合了业务需求。当你把一个原本靠纸质表格流转的场景，变成一套实时联动、角色清晰、数据自动汇聚的系统时，那种成就感远超过背熟某个框架的API。对正在做类似项目的同学，我的建议是先把业务链路搞透，再谈技术选型；把数据库设计打磨清楚，后面所有功能开发都会顺很多。如果你在这套源码基础上遇到底层数据设计或者联调的问题，欢迎按我上面的排查思路逐步验证，大部分问题都能靠日志和SQL调试来定位解决。