企业官网建设流程全解析

1. 毕设选题复盘：为什么我敲定了高校就业管理系统

每年到了毕设开题季，大批计算机专业的学生就开始在“图书管理系统”“商城系统”“酒店管理系统”里反复横跳。说实话，这几个方向已经被做到快烂大街了，答辩现场撞题率极高，老师扫一眼就知道你是在哪套模板上改的。我当初选高校就业管理系统，就是不想再走那条人人都走的老路。

高校就业管理这个场景其实特别有意思。传统思路里它就是个“毕业去向登记表”，但真实的高校就业工作远不止填一张表那么简单。学校里既有学生端——要维护简历、浏览企业发布的岗位、完成在线投递；又有企业端——要发布招聘职位、查收学生简历、管理面试流程；还有辅导员和就业办视角——要审核企业资质、筛选招聘信息、统计毕业去向、生成就业率报表。一个系统里同时有身份权限、业务流程、文件上传、统计分析、消息通知，几乎把SpringBoot后端开发的核心环节全部覆盖了。

选它做毕设，我还有几个现实考量。第一，就业管理属于“有人管、有人用”的真实业务系统，不是纯教学演示品，写起来有抓手；第二，它的功能边界很清晰，不会像电商系统那样无限膨胀，更适合在半年内做完；第三，答辩的时候可讲的东西特别多——权限设计了没有、表关系是怎么权衡的、统计口径怎么定的，随便拎一个出来都能展开讲十分钟。既不至于太简单让老师觉得没含量，也不至于复杂到一个人做不完。

更重要的是，这套系统的开发思路和市面上主流的企业级后台管理项目高度一致。做完它之后，SpringBoot + MyBatis Plus + Vue 这套组合基本就吃透了，后续找实习、做开源项目，节奏都会顺很多。带着源码交付，导师和答辩组拿到手也能直接跑起来看效果，比交一份纯文档体面的多。

2. 技术选型不是凑热闹：SpringBoot为什么是最稳的底子

2.1 后端框架对比，我最终选了SpringBoot而不是SSH

先明确一件事：毕设项目的本质，是在有限时间内做出一个功能完整、逻辑自洽、能演示的系统。技术栈的先进程度不是第一优先级，稳定性和自己能否驾驭才是。目前高校和培训机构里，Java后端的主流教学栈已经全面倒向SpringBoot。相比早期的SSH（Spring + Struts + Hibernate）和SSM（Spring + SpringMVC + MyBatis），SpringBoot把大量配置自动化，内嵌Tomcat容器，打一个Jar包就可以直接运行，省去了部署Web服务器的步骤。

我给自己的选型原则很朴素：用最主流的组合，避免冷门框架。最终确定的后端核心是SpringBoot 2.7.x + MyBatis Plus + MySQL 8.0。SpringBoot负责整体框架和自动配置，MyBatis Plus在MyBatis之上封装了通用CRUD，写单表增删改查时基本不用手写SQL，能把大量时间省下来放到业务逻辑上。前端选了Vue + Element UI，用axios发请求，数据交互走JSON。整个项目前后端分离，接口路径和返回格式从一开始就规范好，后面联调会省很多事。

2.2 项目分层结构：controller-service-mapper三层是整个系统的骨架

工程创建后，我把包结构按照业务边界切分得很清楚，这也是后期能快速定位问题的基础：

com.university.employment ├── controller // 接收请求、参数校验、返回统一结果 ├── service // 业务逻辑层，事务边界在这里 ├── mapper // 数据访问层，继承BaseMapper ├── entity // 数据库实体映射 ├── dto // 接口入参/出参对象 ├── vo // 前端展示对象 ├── config // 配置类（跨域、拦截器等） ├── common // 通用工具、统一返回体、异常处理 └── utils // 工具类（JWT、文件存储、日期处理等）

这套分层的好处体现在两点。一是职责隔离，controller里不做业务，只做参数接收和结果包装；service里不碰HttpServletRequest，专心处理逻辑；mapper只跟数据库打交道。二是方便复用，比如统计就业率这个逻辑，Excel导出要用、前端图表接口要用、首页看板也要用，把它放在service层里单独拆一个方法，三个地方直接调就行了。

每个模块我遵循了一个约定：实体类字段与数据库表字段一一对应，DO不直接返回给前端；对外接口统一使用VO对象，避免把数据库里的敏感字段（比如管理员密码加盐后的哈希值）泄露出去。

2.3 接口鉴权与统一返回体，千万别等最后再补

很多毕设项目在开发初期图省事，接口全部裸奔，等所有功能做完才开始补登录鉴权，结果陷入了“改一个接口崩三个页面”的困境。我这次把基础设施提前做好了。

统一返回体用的是最简单的泛型封装：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String message) { ... } }

所有Controller都返回Result对象，前端拿到后统一判断code是否为200。异常处理上加了一个@RestControllerAdvice全局异常类，业务异常、参数校验异常、未知异常分三类处理，不会出现错误堆栈直接抛到前端的情况。

登录鉴权这块，我选了自己可以完全控制逻辑的JWT方案。用户登录成功后，后端生成带过期时间的Token返回给前端，前端把Token存在localStorage里，之后每次请求都放到Authorization请求头中。后端写了一个拦截器，在请求进入Controller之前检查Token的有效性，同时根据用户角色判断是否有权限访问对应模块。学生账号访问不了企业管理页面，管理员账号能进入系统设置页面，这套权限控制写到拦截器里，接口层面就关死了。

3. 核心业务模块拆解：就业数据是怎么在系统里流转的

3.1 学生端：从简历到投递的一条完整业务链路

学生端是整个系统里使用频率最高的模块，拿我设计的流程来说，学生在系统里走的路径是：完善个人信息 -> 维护简历 -> 浏览职位 -> 投递简历 -> 查看投递状态。

个人信息的核心字段包括学号、姓名、学院、专业、班级、入学年份、预计毕业年份、联系电话、邮箱。这里有一个细节值得注意：院系和专业信息不要让学生自由填写，而是做成下拉选择，数据来自系统里预先维护好的学院表和专业表。这样可以保证后期按学院、专业统计就业率时，数据的口径完全统一。

简历模块我采用“基础信息 + 教育经历 + 实习/项目经历 + 技能特长 + 附件简历”的结构。前四个部分是结构化字段，方便后台做关键词匹配和筛选；附件简历支持PDF和Word格式上传，上传成功后保存文件路径到数据库。

职位浏览和投递是学生最关心的功能。职位列表支持按职位名称、企业名称、工作城市、薪资范围筛选，分页查询用MyBatis Plus的Page对象实现。学生点击投递后，系统会先判断是否已经投递过该职位，防止重复投递，然后生成一条投递记录，状态默认为“待审核”。企业查看后可以更新为“已查看”“面试邀请”“已录用”“不合适”等状态，学生端在“我的投递”页面里看到实时进度。

3.2 企业端：招聘信息发布背后的审核逻辑

企业角色分两类：一类是系统管理员手动录入的合作企业，另一类是企业用户自己注册。考虑到毕设系统的边界，我没有开放完全自由的企业注册，而是采用更符合高校实际的做法——企业信息由就业办审核后统一录入或导入，企业用户账号由管理员分配。

企业账号登录后可使用的核心功能有三个。第一，维护企业基本资料，包括企业名称、统一社会信用代码、所属行业、企业规模、联系方式、企业简介。第二，发布和管理招聘职位，职位字段包含职位名称、招聘人数、薪资范围、工作地点、学历要求、职位描述。第三，查看和管理投递到本企业职位的学生简历列表，并执行状态流转。

这里有一个我认为很关键的权限设计：企业只能看到投递了自己职位的学生简历，无法浏览全校学生的信息。这个边界在SQL层就卡住了，查询简历时强制带上前置条件——校验该职位确实属于当前登录企业。不是光靠前端菜单隐藏来控制，而是从数据源头上隔离，防止越权。

3.3 辅导员与就业办：统计报表的口径设计

管理端是整个项目里相对出彩的部分，因为它直接体现了“系统不是简单录入工具”的价值。就业办和辅导员登录后，可以按学院、专业、班级、学历层次、毕业年份、就业状态等维度组合筛选学生，并查看对应的就业统计看板。

就业状态的字典项要在一开始就定义清楚。我这里采用了“已就业（签就业协议）”“已就业（签劳动合同）”“升学（境内）”“升学（出国/境外）”“自主创业”“灵活就业”“暂未就业”七类。如果分类不标准，后期统计口径就会出问题，这是做这个模块第一个也是最重要的经验。

统计报表的呈现方式选择了三种：总数卡片、柱状图、饼图。后端接口返回的是已经聚合好的数据，比如按学院统计各学院就业人数、按就业状态统计占比。图表展示用ECharts，直接对接后端JSON数据。这个设计让答辩时很有展示效果，数据一变图表就动，评委看完基本能确认这不是个死系统。

3.4 管理员端：用户管理、字典管理与系统配置

管理员端是整个系统权限最高的地方，负责以下内容：用户管理（创建教师/企业账号、重置密码、禁用账号）、学院专业管理（维护基础数据）、职位类别管理、企业审核、系统公告发布。独立的系统管理模块让整个项目更完整，也方便在答辩时演示RBAC（基于角色的访问控制）概念。

我额外做了一个容易被忽略但实用性很强的功能：数据字典管理。举个例子，学历要求这个字段，在职位表里存的是字典编码，而不是中文文本。前端拿到字典编码后，调接口获取字典表中的真实文本进行翻译展示。这样做的好处是，如果学校要求新增一个学历类别，不用改代码、不用改表结构，运维人员直接在管理后台加一条字典记录就行。这个细节也成了答辩时老师主动追问的点，说明它确实体现了系统设计思维。

4. 数据库设计：十六张表是怎么把整个业务串起来的

4.1 核心表结构与字段设计

整个数据库一共设计了16张表，听起来很多，但真正核心的业务表只有几张。这里我把最重要的一组列出来，方便参考：

这里有一个比较关键的设计思路：用户表和学生信息表没有合并成一张表。原因是系统里的用户类型有三种：学生、教师（辅导员）、企业账号。如果强制公用一张大表，字段会大量冗余；如果每类用户单独建表，多态查询又太麻烦。我的折中方案是：用户表只存登录认证必需的通用字段，学生、企业各自的专属信息放到扩展表中，通过user_id关联。这样既保证了登录流程的统一，也兼顾了各角色的差异化字段。

4.2 简历、职位、投递记录之间的关联逻辑

投递记录表是整个业务流转的关键枢纽，也是表关联关系最复杂的地方。一张投递记录包含了学生ID、职位ID两个外键，通过student_id可以关联到具体的学生及其简历，通过job_id可以关联到具体的职位及其所属企业。

举一个实际的查询例子：企业端要查看“投递了某职位的学生列表及简历”，SQL可以这样组织：

SELECT d.id AS delivery_id, d.status AS delivery_status, s.student_no, s.real_name, r.title AS resume_title, r.attachment_url FROM delivery_record d LEFT JOIN student_profile s ON d.student_id = s.user_id LEFT JOIN resume r ON r.student_id = s.user_id WHERE d.job_id = #{jobId} AND d.deleted = 0 ORDER BY d.create_time DESC

这个判断的核心是：投递记录是列表主表，学生和简历都通过外键关联。左连接保证即使学生还没完善简历，投递记录依然能查出来。设计关联关系的时候，我一直提醒自己：不要为了查询方便去建冗余的中间表，一个清晰的业务状态流转，用一条记录的多状态更新来表达，比建一堆乱七八糟的关联表更可靠。

4.3 逻辑删除和审计字段，是我在所有表上的统一约定

数据库设计里很多人容易忽略审计字段，我这次从建表第一天就统一加上了create_time、update_time、deleted三个字段。尤其是deleted字段，所有的删除操作都不是物理DELETE，而是UPDATE把deleted置为1。MyBatis Plus的@TableLogic注解可以自动实现这个逻辑，查询时自动拼接AND deleted = 0，不需要每个SQL手动加，非常省心。

选逻辑删除而不是物理删除，有两个原因。一是所有业务操作都可追溯，即使误删了数据也能迅速恢复；二是项目答辩时如果需要展示“删除了再去数据库里查”的恢复过程，逻辑删除能直接演示。代价就是所有查询语句都要注意MyBatis Plus自动拼接的条件，如果遇到自定义SQL一定要手动加上deleted过滤条件，否则会出现已删除数据被查出来的bug。这是我在开发过程中真实踩过的坑，后面单独讲。

5. 从零到能跑：工程搭建和功能联调的几个关键节点

5.1 初始化工程：application.yml 里的几个必备配置

创建SpringBoot工程的步骤不复杂，但有些配置细节特别容易坑新手。我在application.yml里做了几个关键配置，这里直接给出来：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/employment_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

有几个容易踩的坑我得专门说一下。第一，serverTimezone=Asia/Shanghai必须配，否则MySQL 8.0连接时会报时区错误。第二，map-underscore-to-camel-case开启后，数据库里的student_no字段可以自动映射到Java里的studentNo属性，避免手写大量映射。第三，logic-delete-field的全局配置能让我在实体类上只用加@TableLogic注解，而不用每个mapper方法都去处理删除条件。

5.2 简历文件上传：从MultipartFile到数据库存储路径

文件上传是就业管理系统里绕不开的一个功能，也是很多毕设项目里实现得比较粗糙的地方。我的实现逻辑是：前端用Element UI的el-upload组件选择文件，提交时以multipart/form-data格式把文件传给后端的/api/resume/upload接口。后端用MultipartFile接收，校验文件类型和后缀，然后调用工具类把文件存储到服务器本地磁盘目录/data/upload/，文件名用UUID重命名防止冲突，最后把相对路径/files/20250612/uuid.pdf保存到数据库的attachment_url字段里。

访问上传的文件时，需要一个静态资源映射配置：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceHandler("file:" + uploadPath + "/"); } }

这里有一个经验：不要把文件直接存到项目的src/main/resources/static目录下。因为项目打包成Jar之后，这个目录是只读的，运行时写入文件会报错。把上传目录放到服务器外部路径，然后通过配置类做映射，打包部署之后功能完全不受影响。

5.3 前后端联调：跨域与Token携带问题的处理方式

前后端分离的项目，联调阶段最常见的问题就是跨域。我在后端写了一个CorsFilter配置类，允许前端开发服务器http://localhost:3000访问后端接口。跨域之外，Token携带的安全细节更容易被忽略。前端在axios请求中做了一个拦截器：

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

后端在登录接口的路由排除列表里加入/api/user/login、/api/user/register等不需要鉴权的路径，其他所有/api/**请求都会先经过Token拦截器。这里有一个顺序问题：如果静态资源路径/files/**也被拦截器拦了，浏览器直接访问简历附件URL就会返回401。所以拦截器的排除路径里一定要加上静态资源目录。

6. 验收前夜：实测踩过的坑和答辩演示清单

6.1 MyBatis Plus逻辑删除与自定义SQL的冲突

这是我在测试投递记录查询时发现的一个隐蔽bug。我用MyBatis Plus的BaseMapper默认方法查询投递记录时，deleted过滤条件会自动带上；但是一旦在Mapper接口里写了自定义SQL，比如多表联查投递记录和企业职位信息时，deleted条件就不会自动拼接了。

当时的表现是：学生已经撤销了一条投递记录，但企业的收件箱里仍能看到这条数据。排查了很久才意识到是自定义SQL没有手动加过滤条件。修改方式很简单：

SELECT ... FROM delivery_record d INNER JOIN job_position j ON d.job_id = j.id AND j.deleted = 0 WHERE d.student_id = #{studentId} AND d.deleted = 0

这个教训很典型：框架帮你做的事情越多，你自己写SQL时越要清楚框架在背后做了什么。用MyBatis Plus，@TableLogic只对BaseMapper的通用方法生效，自定义XML里的一切都得自己负责。

6.2 统计报表的数据口径：为什么图表和学生列表对不上

开发和测试统计功能时，我遇到了一个数据对不上的问题：就业看板里显示“已就业80人”，但点进去看已就业学生列表，实际只有78条。这类问题在答辩演示时是致命的，因为老师一旦发现数据对不上，整个系统的可信度都会受质疑。

排查后发现，报表统计和列表展示用了两个不同的聚合条件。列表接口查询的是就业信息表中的记录数，而统计接口在计算时把就业状态为“已就业（签劳动合同）”和“已就业（签就业协议）”两条记录都并入“已就业”类别，但列表页因为筛选条件没写完整而漏掉了其中一条。这个问题的本质是统计口径没有统一，修了两处：一是把统计口径定义放到一个公共的常量类里，二是让统计接口和列表接口复用同一个口径枚举，保证两侧查询条件永远一致。

6.3 答辩演示前，我建议优先跑通的五个核心场景

毕设答辩基本就是“文档 + 演示 + 问答”三件套，其中现场演示翻车是最尴尬的。根据我的实测经验，以下五个场景一定要提前完整跑通，最好录一份演示视频备着，防止现场网络或环境出问题：

1. 管理员登录 -> 创建企业账号 -> 录入一条职位 -> 审核通过，完整走一遍数据创建流程。
2. 学生登录 -> 完善信息 -> 上传附件简历 -> 检索并投递一个职位。
3. 企业登录 -> 查看收到的投递 -> 改变投递状态为“面试邀请”。
4. 学生再次登录 -> 查看投递状态变化，确认流程闭环。
5. 管理员进入统计看板 -> 切换学院筛选 -> 核对学生列表与图表统计数量一致。

这五个场景基本覆盖了系统的全部核心功能，跑通之后演示环节的底气会足很多。我在正式答辩前把每一步都用同样的账号、同样的数据反复操作了三遍，就是为了防止临场出现数据库连接超时或者缓存异常之类的问题。数据的一致性核对尤其重要，宁可少讲一个炫酷功能，也不能让数据逻辑在评委眼皮底下出错。