1. 毕设选题复盘为什么我敲定了高校就业管理系统每年到了毕设开题季大批计算机专业的学生就开始在“图书管理系统”“商城系统”“酒店管理系统”里反复横跳。说实话这几个方向已经被做到快烂大街了答辩现场撞题率极高老师扫一眼就知道你是在哪套模板上改的。我当初选高校就业管理系统就是不想再走那条人人都走的老路。高校就业管理这个场景其实特别有意思。传统思路里它就是个“毕业去向登记表”但真实的高校就业工作远不止填一张表那么简单。学校里既有学生端——要维护简历、浏览企业发布的岗位、完成在线投递又有企业端——要发布招聘职位、查收学生简历、管理面试流程还有辅导员和就业办视角——要审核企业资质、筛选招聘信息、统计毕业去向、生成就业率报表。一个系统里同时有身份权限、业务流程、文件上传、统计分析、消息通知几乎把SpringBoot后端开发的核心环节全部覆盖了。选它做毕设我还有几个现实考量。第一就业管理属于“有人管、有人用”的真实业务系统不是纯教学演示品写起来有抓手第二它的功能边界很清晰不会像电商系统那样无限膨胀更适合在半年内做完第三答辩的时候可讲的东西特别多——权限设计了没有、表关系是怎么权衡的、统计口径怎么定的随便拎一个出来都能展开讲十分钟。既不至于太简单让老师觉得没含量也不至于复杂到一个人做不完。更重要的是这套系统的开发思路和市面上主流的企业级后台管理项目高度一致。做完它之后SpringBoot MyBatis Plus Vue 这套组合基本就吃透了后续找实习、做开源项目节奏都会顺很多。带着源码交付导师和答辩组拿到手也能直接跑起来看效果比交一份纯文档体面的多。2. 技术选型不是凑热闹SpringBoot为什么是最稳的底子2.1 后端框架对比我最终选了SpringBoot而不是SSH先明确一件事毕设项目的本质是在有限时间内做出一个功能完整、逻辑自洽、能演示的系统。技术栈的先进程度不是第一优先级稳定性和自己能否驾驭才是。目前高校和培训机构里Java后端的主流教学栈已经全面倒向SpringBoot。相比早期的SSHSpring Struts Hibernate和SSMSpring SpringMVC MyBatisSpringBoot把大量配置自动化内嵌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 ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ... } public static T ResultT 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张表听起来很多但真正核心的业务表只有几张。这里我把最重要的一组列出来方便参考表名核心职责主要字段sys_user统一用户表id、username、password、real_name、role_type、phone、email、statusstudent_profile学生扩展信息user_id、student_no、college_id、major_id、class_name、graduate_yearenterprise企业信息表id、enterprise_name、credit_code、industry、scale、contact、addressjob_position职位表id、enterprise_id、position_name、category、salary_min、salary_max、city、degree_required、description、statusresume简历表id、student_id、title、content、attachment_url、view_countdelivery_record投递记录表id、student_id、job_id、status、interview_time、feedbackemployment_info就业信息表id、student_id、employment_type、company_name、position、entry_date、remark这里有一个比较关键的设计思路用户表和学生信息表没有合并成一张表。原因是系统里的用户类型有三种学生、教师辅导员、企业账号。如果强制公用一张大表字段会大量冗余如果每类用户单独建表多态查询又太麻烦。我的折中方案是用户表只存登录认证必需的通用字段学生、企业各自的专属信息放到扩展表中通过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?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/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有几个容易踩的坑我得专门说一下。第一serverTimezoneAsia/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 PlusTableLogic只对BaseMapper的通用方法生效自定义XML里的一切都得自己负责。6.2 统计报表的数据口径为什么图表和学生列表对不上开发和测试统计功能时我遇到了一个数据对不上的问题就业看板里显示“已就业80人”但点进去看已就业学生列表实际只有78条。这类问题在答辩演示时是致命的因为老师一旦发现数据对不上整个系统的可信度都会受质疑。排查后发现报表统计和列表展示用了两个不同的聚合条件。列表接口查询的是就业信息表中的记录数而统计接口在计算时把就业状态为“已就业签劳动合同”和“已就业签就业协议”两条记录都并入“已就业”类别但列表页因为筛选条件没写完整而漏掉了其中一条。这个问题的本质是统计口径没有统一修了两处一是把统计口径定义放到一个公共的常量类里二是让统计接口和列表接口复用同一个口径枚举保证两侧查询条件永远一致。6.3 答辩演示前我建议优先跑通的五个核心场景毕设答辩基本就是“文档 演示 问答”三件套其中现场演示翻车是最尴尬的。根据我的实测经验以下五个场景一定要提前完整跑通最好录一份演示视频备着防止现场网络或环境出问题管理员登录 - 创建企业账号 - 录入一条职位 - 审核通过完整走一遍数据创建流程。学生登录 - 完善信息 - 上传附件简历 - 检索并投递一个职位。企业登录 - 查看收到的投递 - 改变投递状态为“面试邀请”。学生再次登录 - 查看投递状态变化确认流程闭环。管理员进入统计看板 - 切换学院筛选 - 核对学生列表与图表统计数量一致。这五个场景基本覆盖了系统的全部核心功能跑通之后演示环节的底气会足很多。我在正式答辩前把每一步都用同样的账号、同样的数据反复操作了三遍就是为了防止临场出现数据库连接超时或者缓存异常之类的问题。数据的一致性核对尤其重要宁可少讲一个炫酷功能也不能让数据逻辑在评委眼皮底下出错。 
长河君 · 2026/9/24 20:23:57 · 阅读 1.2k 基于SpringBoot+Vue的高校就业管理系统设计与实现
1. 毕设选题复盘为什么我敲定了高校就业管理系统每年到了毕设开题季大批计算机专业的学生就开始在“图书管理系统”“商城系统”“酒店管理系统”里反复横跳。说实话这几个方向已经被做到快烂大街了答辩现场撞题率极高老师扫一眼就知道你是在哪套模板上改的。我当初选高校就业管理系统就是不想再走那条人人都走的老路。高校就业管理这个场景其实特别有意思。传统思路里它就是个“毕业去向登记表”但真实的高校就业工作远不止填一张表那么简单。学校里既有学生端——要维护简历、浏览企业发布的岗位、完成在线投递又有企业端——要发布招聘职位、查收学生简历、管理面试流程还有辅导员和就业办视角——要审核企业资质、筛选招聘信息、统计毕业去向、生成就业率报表。一个系统里同时有身份权限、业务流程、文件上传、统计分析、消息通知几乎把SpringBoot后端开发的核心环节全部覆盖了。选它做毕设我还有几个现实考量。第一就业管理属于“有人管、有人用”的真实业务系统不是纯教学演示品写起来有抓手第二它的功能边界很清晰不会像电商系统那样无限膨胀更适合在半年内做完第三答辩的时候可讲的东西特别多——权限设计了没有、表关系是怎么权衡的、统计口径怎么定的随便拎一个出来都能展开讲十分钟。既不至于太简单让老师觉得没含量也不至于复杂到一个人做不完。更重要的是这套系统的开发思路和市面上主流的企业级后台管理项目高度一致。做完它之后SpringBoot MyBatis Plus Vue 这套组合基本就吃透了后续找实习、做开源项目节奏都会顺很多。带着源码交付导师和答辩组拿到手也能直接跑起来看效果比交一份纯文档体面的多。2. 技术选型不是凑热闹SpringBoot为什么是最稳的底子2.1 后端框架对比我最终选了SpringBoot而不是SSH先明确一件事毕设项目的本质是在有限时间内做出一个功能完整、逻辑自洽、能演示的系统。技术栈的先进程度不是第一优先级稳定性和自己能否驾驭才是。目前高校和培训机构里Java后端的主流教学栈已经全面倒向SpringBoot。相比早期的SSHSpring Struts Hibernate和SSMSpring SpringMVC MyBatisSpringBoot把大量配置自动化内嵌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 ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ... } public static T ResultT 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张表听起来很多但真正核心的业务表只有几张。这里我把最重要的一组列出来方便参考表名核心职责主要字段sys_user统一用户表id、username、password、real_name、role_type、phone、email、statusstudent_profile学生扩展信息user_id、student_no、college_id、major_id、class_name、graduate_yearenterprise企业信息表id、enterprise_name、credit_code、industry、scale、contact、addressjob_position职位表id、enterprise_id、position_name、category、salary_min、salary_max、city、degree_required、description、statusresume简历表id、student_id、title、content、attachment_url、view_countdelivery_record投递记录表id、student_id、job_id、status、interview_time、feedbackemployment_info就业信息表id、student_id、employment_type、company_name、position、entry_date、remark这里有一个比较关键的设计思路用户表和学生信息表没有合并成一张表。原因是系统里的用户类型有三种学生、教师辅导员、企业账号。如果强制公用一张大表字段会大量冗余如果每类用户单独建表多态查询又太麻烦。我的折中方案是用户表只存登录认证必需的通用字段学生、企业各自的专属信息放到扩展表中通过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?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/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有几个容易踩的坑我得专门说一下。第一serverTimezoneAsia/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 PlusTableLogic只对BaseMapper的通用方法生效自定义XML里的一切都得自己负责。6.2 统计报表的数据口径为什么图表和学生列表对不上开发和测试统计功能时我遇到了一个数据对不上的问题就业看板里显示“已就业80人”但点进去看已就业学生列表实际只有78条。这类问题在答辩演示时是致命的因为老师一旦发现数据对不上整个系统的可信度都会受质疑。排查后发现报表统计和列表展示用了两个不同的聚合条件。列表接口查询的是就业信息表中的记录数而统计接口在计算时把就业状态为“已就业签劳动合同”和“已就业签就业协议”两条记录都并入“已就业”类别但列表页因为筛选条件没写完整而漏掉了其中一条。这个问题的本质是统计口径没有统一修了两处一是把统计口径定义放到一个公共的常量类里二是让统计接口和列表接口复用同一个口径枚举保证两侧查询条件永远一致。6.3 答辩演示前我建议优先跑通的五个核心场景毕设答辩基本就是“文档 演示 问答”三件套其中现场演示翻车是最尴尬的。根据我的实测经验以下五个场景一定要提前完整跑通最好录一份演示视频备着防止现场网络或环境出问题管理员登录 - 创建企业账号 - 录入一条职位 - 审核通过完整走一遍数据创建流程。学生登录 - 完善信息 - 上传附件简历 - 检索并投递一个职位。企业登录 - 查看收到的投递 - 改变投递状态为“面试邀请”。学生再次登录 - 查看投递状态变化确认流程闭环。管理员进入统计看板 - 切换学院筛选 - 核对学生列表与图表统计数量一致。这五个场景基本覆盖了系统的全部核心功能跑通之后演示环节的底气会足很多。我在正式答辩前把每一步都用同样的账号、同样的数据反复操作了三遍就是为了防止临场出现数据库连接超时或者缓存异常之类的问题。数据的一致性核对尤其重要宁可少讲一个炫酷功能也不能让数据逻辑在评委眼皮底下出错。