企业官网建设流程全解析

简介：这份文档是面向计算机专业学生与Java Web初学者的人才招聘系统毕业设计参考资料，围绕求职者、招聘企业与管理员三类角色，梳理了从需求分析到系统实现的完整思路。内容涵盖个人求职注册与信息发布、企业招聘注册与职位管理、简历浏览与邮件通信、管理员对求职广告和公司信息的审核管理等核心模块，并介绍了JSP、Tomcat、SQL Server与JDBC的技术选型及数据库表设计。资源包共1个doc文件，约1.07MB，以Word文档形式呈现，便于直接阅读、摘录与二次编辑。目前已有484人学习下载，适合需要完成同类课题、参考系统模块划分与论文结构的学习者，可据此快速理解招聘系统的功能组成与开发流程，为课程设计或毕业设计提供可借鉴的文档范本。

1. 基于 Java Web 的人才招聘系统：从简历投递到面试邀约的完整链路

招聘旺季，HR 一天要翻两百份简历，邮箱里还混着重复投递、附件打不开、格式五花八门的文件。很多中小团队的第一反应是买 SaaS，但数据不在自己手里，定制字段要加钱，和内部 OA 打通更是遥遥无期。基于 Java Web 的人才招聘系统，解决的就是这条链路上的信息流转问题：求职者注册、投递简历、企业发布职位、HR 筛选、发起面试邀约、记录面试结果，全部落在一个自己可控的 Web 应用里。

这套系统适合谁？适合有 Java 基础、想做一个完整业务闭环项目的学生和初级工程师，也适合需要内部招聘工具、又不想被第三方平台绑死的中小团队技术负责人。它不追求高并发秒杀那种极限场景，但对权限模型、状态流转、文件存储、跨浏览器兼容这些工程细节有实打实的要求。下面按「先想清楚再动手」的顺序，把选型、建表、接口、页面和踩坑一次讲透。

2. 技术选型与工程骨架：为什么是 Spring Boot + MyBatis + Vue

2.1 后端为什么优先 Spring Boot 而不是原生 Servlet

标题里写的是 Java Web，这个范围很宽。原生 Servlet + JSP 能跑，但配置量大、依赖管理靠手动导 jar，做到权限拦截和事务控制时很容易写成一团。常见做法是直接上 Spring Boot，它把 Tomcat 内嵌、依赖版本、自动配置都收拢了，一个main方法就能起服务。对招聘系统这种「中等复杂度、模块清晰」的项目，Spring Boot 的收益最明显。

选型时我一般看三点：团队熟悉度、生态完整度、后期维护成本。Spring Boot 在权限（Spring Security）、事务（@Transactional）、参数校验（Validation）上都有现成方案，不用自己造轮子。数据库层用 MyBatis 而不是 JPA，原因是招聘系统里「按条件动态筛选简历」的查询很多，比如同时按学历、工作经验、投递状态过滤，MyBatis 的 XML 动态 SQL 写起来更直观，也方便后期 DBA 直接看 SQL 调优。

前端用 Vue 做前后端分离，后端只返回 JSON。这样做的好处是页面交互（比如简历列表的即时筛选、分页）不用整页刷新，体验接近现在的招聘网站。如果团队只会 JSP，也可以先做服务端渲染，但接口层要提前设计好，方便以后拆。

2.2 用 Maven 搭出可运行的最小骨架

第一步不是写业务，而是把工程跑起来。下面是一个最小pom.xml的关键依赖，版本按你本地仓库里稳定的来，不要盲目追最新。

<!-- pom.xml 关键依赖，parent 统一管理版本 --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <!-- Web 层：内嵌 Tomcat + Spring MVC --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 持久层：MyBatis 与 Spring Boot 整合 --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <!-- 参数校验，用于注册、发布职位等表单 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> </dependencies>

逻辑说明：spring-boot-starter-web负责 MVC 和 JSON 序列化；mybatis-spring-boot-starter让 Mapper 接口能被自动扫描；validation用来在 Controller 层拦截非法参数，避免脏数据进库。参数上要注意，MyBatis starter 的版本要和 Spring Boot 主版本匹配，2.3.x 对应 Boot 2.7.x，版本错配会在启动时报NoSuchMethodError，这是新手最容易翻车的地方。

配置文件application.yml里至少要写清数据源和 MyBatis 的映射路径：

spring: datasource: url: jdbc:mysql://localhost:3306/recruit?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.recruit.entity

serverTimezone必须显式指定，否则 MySQL 8 连接时会报时区错误；mapper-locations指向 XML 文件目录，接口和 XML 分离是 MyBatis 的常规做法，方便 SQL 集中管理。

2.3 前后端分离下的目录约定

工程目录不要随手放，按职责分层，后期加模块才不会乱。我一般这样组织：

src/main/java/com/example/recruit ├── controller // 接收请求，做参数校验 ├── service // 业务逻辑，事务边界 │ └── impl ├── mapper // MyBatis 接口 ├── entity // 数据库实体 ├── dto // 前端传入/返回的对象 └── config // 跨域、拦截器、安全配置 src/main/resources ├── mapper // SQL 映射 XML └── application.yml

Controller 只做「收参、校验、调 Service、返回结果」，业务判断全部下沉到 Service。这样做的直接好处是：以后要加「投递后自动发邮件通知」，只改 Service，Controller 不动。DTO 和 entity 分开，是为了避免把数据库字段（比如密码哈希）直接暴露给前端，这是安全底线。

3. 数据库设计：职位、简历、投递三张核心表怎么建

3.1 表结构拆解与字段取舍

招聘系统的数据模型围绕三个主体转：企业发布的职位、求职者的简历、以及两者之间的投递关系。很多人一开始把简历和用户合成一张表，结果一个人投多个岗位时数据冗余严重，改一次简历要更新多行。正确做法是拆开。

核心表我一般建这几张：user（账号，区分角色）、company（企业信息）、job（职位）、resume（简历）、application（投递记录）、interview（面试记录）。下面给出关键字段设计。

application表的status是整个系统的状态机核心，常见取值：待筛选、已查看、邀面试、已拒绝、已录用。所有状态变更都要走 Service 层统一方法，禁止在 Controller 里直接改，否则后期加「状态变更日志」时无从下手。

3.2 建表 SQL 与索引

-- 职位表，company_id 建索引，因为按企业查职位是高频操作 CREATE TABLE job ( id BIGINT PRIMARY KEY AUTO_INCREMENT, company_id BIGINT NOT NULL, title VARCHAR(100) NOT NULL, city VARCHAR(50), salary_min INT, salary_max INT, status TINYINT DEFAULT 1 COMMENT '1上架 0下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_company (company_id), INDEX idx_city_status (city, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 投递表，job_id 和 resume_id 联合唯一，防止重复投递 CREATE TABLE application ( id BIGINT PRIMARY KEY AUTO_INCREMENT, job_id BIGINT NOT NULL, resume_id BIGINT NOT NULL, status TINYINT DEFAULT 0 COMMENT '0待筛选 1已查看 2邀面试 3已拒绝 4已录用', apply_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_job_resume (job_id, resume_id), INDEX idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逻辑说明：uk_job_resume唯一索引是防重复投递的第一道防线，比在代码里先查再插更可靠，因为并发下「查了没有、插的时候有了」这种竞态靠代码很难完全避免。idx_city_status支撑「按城市筛在招职位」这个最常见的查询。字符集用utf8mb4，否则求职者姓名里的生僻字、emoji 会存不进去，这是血泪经验。

提示：薪资字段用两个 INT 存区间，不要用字符串存「10k-15k」。字符串没法做范围筛选，后期想加「薪资从高到低排序」就得改表。

3.3 简历附件的存储策略

简历附件有两种存法：存数据库 BLOB，或存磁盘/对象存储、数据库只存路径。我强烈建议后者。BLOB 会让数据库体积迅速膨胀，备份和迁移都痛苦，而且读取时要占连接。常见做法是存到服务器某个目录，数据库存相对路径，比如/upload/resume/2024/xxx.pdf。

上传时要校验三件事：文件后缀白名单（pdf、doc、docx）、文件大小上限（一般 5MB 够用）、文件名重命名（用 UUID，避免中文名和重名覆盖）。这三点少一个都会在生产环境出问题，尤其是直接用用户原始文件名，遇到同名文件会互相覆盖，属于典型的后悔药没处买。

4. 核心接口实现：投递、筛选、面试邀约的代码落地

4.1 投递接口：防重复与状态初始化

投递是求职者侧最核心的动作。接口要接收jobId，从当前登录用户查出简历，然后写入application表。

@PostMapping("/apply") public Result apply(@RequestParam Long jobId, HttpServletRequest request) { // 从 token/session 中取当前用户，不要信任前端传的 userId Long userId = (Long) request.getAttribute("currentUserId"); Resume resume = resumeService.getByUserId(userId); if (resume == null) { return Result.fail("请先完善简历"); } try { applicationService.apply(jobId, resume.getId()); } catch (DuplicateKeyException e) { // 唯一索引冲突，说明已投递过 return Result.fail("您已投递过该职位"); } return Result.success(); }

逻辑说明：用户身份必须从服务端会话或 token 解析，绝不能由前端传userId，否则可以伪造他人身份投递。捕获DuplicateKeyException而不是先查询再插入，是为了利用数据库唯一索引兜底并发。参数上jobId要做非空和存在性校验，投递前还要检查职位是否处于上架状态，下架职位不允许投递。

Service 层的apply方法要加@Transactional，因为投递成功后可能还要更新职位的投递计数。事务边界放在 Service，不要放在 Controller。

4.2 HR 筛选列表：动态条件查询

HR 端最需要的是「按条件快速筛出合适的简历」。这个查询条件不固定，可能只按状态，也可能叠加学历、经验、城市。用 MyBatis 动态 SQL 处理最合适。

<select id="selectByCondition" resultType="com.example.recruit.dto.ApplicationVO"> SELECT a.id, a.status, a.apply_time, r.real_name, r.education, r.experience, j.title AS jobTitle FROM application a JOIN resume r ON a.resume_id = r.id JOIN job j ON a.job_id = j.id <where> j.company_id = #{companyId} <if test="status != null"> AND a.status = #{status} </if> <if test="education != null and education != ''"> AND r.education = #{education} </if> <if test="keyword != null and keyword != ''"> AND r.real_name LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY a.apply_time DESC LIMIT #{offset}, #{pageSize} </select>

逻辑说明：<where>标签会自动处理第一个条件前的AND，避免手写WHERE 1=1这种不优雅的写法。companyId是必须条件，保证 HR 只能看到自己公司的投递，这是数据隔离的关键，漏掉就会导致越权查看。分页用LIMIT offset, pageSize，offset由页码换算，注意深分页时性能会下降，数据量大时改用「上一页最大 id」的游标方式。

参数说明：status、education允许为空表示不筛选；keyword做姓名模糊匹配，注意LIKE '%xx%'无法走索引，数据量大时要换成全文检索或前缀匹配。

4.3 面试邀约：状态流转与通知

面试邀约本质是把投递状态从「已查看」推进到「邀面试」，并生成一条面试记录。状态流转必须校验合法性，不能从「已拒绝」直接跳到「邀面试」。

@Transactional public void inviteInterview(Long applicationId, InterviewDTO dto) { Application app = applicationMapper.selectById(applicationId); // 只有待筛选和已查看状态可以发起面试 if (app.getStatus() != 0 && app.getStatus() != 1) { throw new BizException("当前状态不允许发起面试"); } Interview interview = new Interview(); interview.setApplicationId(applicationId); interview.setInterviewTime(dto.getInterviewTime()); interview.setAddress(dto.getAddress()); interviewMapper.insert(interview); app.setStatus(2); // 邀面试 applicationMapper.updateStatus(app.getId(), 2); }

逻辑说明：状态校验放在最前面，非法流转直接抛业务异常。插入面试记录和更新投递状态在同一个事务里，任何一步失败都回滚，避免出现「有面试记录但状态没变」的脏数据。interviewTime要校验必须是未来时间，address做长度限制，防止前端传超长字符串撑爆字段。

注意：状态值建议用枚举类统一管理，不要在各处硬编码 0、1、2。后期加状态时，硬编码的地方全是隐患。

5. 避坑与排查：跨浏览器、附件、权限的五个真实翻车点

5.1 附件下载在部分浏览器变成乱码文件名

现象：Chrome 下载简历正常，某些浏览器下载后文件名是一串乱码。原因：响应头里的文件名没有做 URL 编码，中文文件名在不同浏览器解析规则不一致。解决：设置Content-Disposition时对文件名做URLEncoder.encode(name, "UTF-8")，并替换掉编码后的+号，同时提供filename和filename*两个参数兼容不同浏览器。

5.2 日期格式前后端不一致导致面试时间差 8 小时

现象：前端选的面试时间是 14:00，HR 列表里显示成 06:00。原因：后端用Date序列化时默认时区与前端不一致，或者数据库连接没指定时区。解决：统一用java.time.LocalDateTime，在application.yml里配置spring.jackson.time-zone: Asia/Shanghai，数据库连接串加serverTimezone=Asia/Shanghai。三处时区必须一致，缺一处就翻车。

5.3 HR 能看到别家公司的投递记录

现象：测试时发现 A 公司 HR 登录后能查到 B 公司的简历。原因：筛选查询里漏了company_id条件，或者company_id是从前端传的。解决：company_id必须从当前登录 HR 的账号信息里取，服务端强制拼接，绝不接受前端传入。这是权限设计里最典型的越权漏洞，排查时优先检查所有列表接口的过滤条件。

5.4 简历附件上传成功但下载 404

现象：上传返回成功，数据库也有路径，但点下载报 404。原因：文件存到了项目临时目录，重启后目录被清空，或者存的是绝对路径、换环境后路径失效。解决：存相对路径，配置一个固定的上传根目录（如/data/upload），下载时用「根目录 + 相对路径」拼接。同时确认该目录不在应用打包范围内，否则每次部署都会被覆盖。

5.5 并发投递出现重复记录

现象：用户快速点两次投递按钮，数据库出现两条相同记录。原因：只靠代码里「先查再插」，两次请求都查到「没有」，然后都插入。解决：数据库加uk_job_resume唯一索引，代码捕获DuplicateKeyException返回友好提示。前端按钮点击后置灰只是辅助，服务端唯一约束才是最终防线。

6. 进阶技巧：用状态机枚举和接口幂等把系统做扎实

把基础功能跑通只是及格线，真正让这套招聘系统经得起用的是两件事：状态流转的可维护性，和接口的幂等性。这两点做好了，后期加需求会轻松很多。

先说状态机。前面提到投递状态有五个值，如果散落在各个 Service 里用if (status == 2)判断，加一个「待笔试」状态时就要全局搜索修改。我的习惯是定义一个枚举，把「当前状态能转到哪些状态」写进去：

public enum ApplicationStatus { PENDING(0, "待筛选"), VIEWED(1, "已查看"), INTERVIEW(2, "邀面试"), REJECTED(3, "已拒绝"), HIRED(4, "已录用"); private final int code; private final String desc; ApplicationStatus(int code, String desc) { this.code = code; this.desc = desc; } // 定义合法流转：待筛选->已查看/已拒绝，已查看->邀面试/已拒绝，邀面试->已录用/已拒绝 public boolean canTransferTo(ApplicationStatus target) { switch (this) { case PENDING: return target == VIEWED || target == REJECTED; case VIEWED: return target == INTERVIEW || target == REJECTED; case INTERVIEW: return target == HIRED || target == REJECTED; default: return false; // 已拒绝、已录用是终态 } } }

逻辑说明：canTransferTo把流转规则集中在一处，Service 里只调这个方法判断，规则变了只改枚举。code和数据库存的数值对应，desc用于前端展示。这样即使以后加状态，也不会漏改判断逻辑。参数上要注意，终态（已拒绝、已录用）不允许再流转，这是业务常识，写进枚举能避免误操作。

再说幂等。投递、邀面试这类「点一下产生一条记录」的接口，都要考虑重复提交。除了数据库唯一索引，还可以在前端提交时带一个一次性 token，服务端校验并消费。对招聘系统这种量级，唯一索引 + 前端按钮防抖已经够用，不必上分布式锁，过度设计反而增加复杂度。

最后说一个验证方法：把状态流转和权限过滤写成单元测试。比如「已拒绝的投递不能发起面试」「A 公司 HR 查不到 B 公司数据」，这两条测试用例能挡住大部分回归问题。我吃过亏，改筛选逻辑时不小心去掉了company_id条件，靠人工点页面没发现，是测试用例报的警。做这类系统，测试不是加分项，是保命项。

希望帮到你。

本文还有配套的精品资源，点击获取