简介这是一个基于Spring Boot的简历系统完整项目包面向Java开发学习者、毕业设计学生以及需要搭建简历管理平台的开发者。系统覆盖用户注册登录、个人信息管理、简历创建编辑与预览导出、管理员筛选及权限控制等常见模块并整合Spring Security、Spring Data JPA、Thymeleaf等主流技术可作为课程设计或毕业设计的参考方案。资源共808个文件压缩包约55.74MB核心包含Java后端源码、Vue前端页面、HTML/CSS/JS静态资源、SQL数据库脚本及yml配置另有论文、PPT答辩文档和mp4演示视频能够辅助理解从数据库设计到接口开发、前端联调的整体流程。压缩包内的install/run/build批处理脚本可快速配置环境并启动项目降低上手门槛整体目录结构清晰便于按模块研读与二次开发。当前已有321人学习适合希望系统掌握Spring Boot全栈开发并需要完整可运行项目模板的读者。1. 简历系统听上去是 CRUD真正折磨人的是文件上传和检索一个典型的招聘场景候选人传一份 PDF 或 Word 简历上来HR 按技能、期望岗位、学历筛人面试官要把几周前看过的一份简历翻回来。这个系统的骨架确实是 Spring Boot 那套增删改查但只做到能存能查的项目三个月后会被两件事拖住。第一是文件怎么存二进制直接塞数据库会给备份和迁移添堵落磁盘又冒出来命名冲突、类型校验、目录膨胀的问题第二是内容怎么搜一份简历正文几万字数据库 LIKE 加前导通配符走不了索引表过几万行之后查询肉眼可见地变慢。下面按一线交付的路径把基于 Spring Boot 的简历系统完整捋一遍先立住四层架构和数据模型再做文件上传与元数据入库接着是分页查询和状态流转最后换成 Lucene 全文检索并处理上线前的安全口子。应届生做课程设计、公司内部要快速搭简历库的 Java 工程师包括准备写基于 Spring Boot 的考研系统这类同构项目的同学都能顺着这套路跑通。2. 用 Spring Boot 四层架构把简历系统拆成可维护的工程2.1 四层架构各自管什么Controller 只做转译Service 只写业务简历系统里天然存在两套变化节奏完全不同的东西文件存储策略和表结构相对稳定而查询条件和状态规则每隔两三个月就会被 HR 的流程调整牵动。如果不分层Controller 里同时出现 SQL 和文件路径拼接第一次改需求很痛快第三次就会开始在十几处雷同代码里找哪处没同步改。Spring Boot 项目最常用的分层是四层Controller 管 HTTP 参数接收和响应包装Service 管事务边界和业务规则Mapper 管数据访问实体类负责表结构映射。对简历系统来说Service 层还要多管一件事——文件存储的调用因为存简历文件和记简历元数据必须在一个统一语义下协调。层次职责在简历系统里的典型内容Controller参数接收、基础校验、状态码转译ResumeFileController 里一个上传方法对应一个接口不写 SQLService事务边界、文件存储编排、状态流转校验ResumeFileService 的 upload、changeStatusMapper数据访问负责 SQL 或 ORM 映射ResumeFileMapper 的 selectPage、insertEntity表结构映射ResumeFileEntity、ResumeSkillEntity这里有个细节值得说明许多教程习惯在 Controller 里直接 new Wrapper 来回折腾查询条件这不能算错但会让上传简历和修改简历两个接口在参数处理上重复代码。更常见的做法是让 Service 接收封装好的 Command 对象参数多的时候不用在方法签名里堆十几个入参。简历系统规模不大这一层做到方法参数不失控就够了。2.2 数据模型设计一张主表加两张从表文件不落库简历系统的表结构围绕两个核心问题展开简历元数据存什么简历文件的二进制放哪。关于后者直接在数据库里用 MEDIUMBLOB 存 PDF 是初学项目常见的方案但它有三个实际麻烦数据库备份体积被文件撑大、应用服务器没法直接输出二进制给浏览器预览、文件读写都会占用数据库连接。所以更接地气的做法是文件落磁盘或对象存储数据库只记相对路径和文件大小。主表 resume_file 是系统的事实表CREATE TABLE resume_file ( id BIGINT AUTO_INCREMENT PRIMARY KEY, candidate_name VARCHAR(64) NOT NULL COMMENT 候选人姓名, phone VARCHAR(20) NULL COMMENT 联系电话, email VARCHAR(128) NULL COMMENT 邮箱, position VARCHAR(128) NULL COMMENT 期望岗位, education VARCHAR(32) NULL COMMENT 最高学历, file_name VARCHAR(255) NULL COMMENT 上传时的原始文件名, file_url VARCHAR(512) NULL COMMENT 文件相对存储路径, file_size BIGINT NULL COMMENT 文件字节数, content_text LONGTEXT NULL COMMENT 解析出的纯文本供全文检索, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待初筛 1面试中 2已淘汰 3已入职, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, PRIMARY KEY (id), KEY idx_status_created (status, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT简历主表;content_text 这一列是为 Lucene 准备的关键设计后面第 5 章会专门讲。联合索引 idx_status_created 对应 HR 最常见的筛选入口按状态看列表并按时间倒序。另外两张从表存技能和工作经历CREATE TABLE resume_skill ( id BIGINT AUTO_INCREMENT PRIMARY KEY, resume_id BIGINT NOT NULL, skill_name VARCHAR(64) NOT NULL, level VARCHAR(16) NULL COMMENT 熟悉程度描述, KEY idx_resume (resume_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE resume_work_experience ( id BIGINT AUTO_INCREMENT PRIMARY KEY, resume_id BIGINT NOT NULL, company VARCHAR(128) NOT NULL, title VARCHAR(64) NULL, start_date DATE NULL, end_date DATE NULL, description TEXT NULL, KEY idx_resume (resume_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;技能和经历拆成从表是为了后续做按技能筛选候选人时不依赖 LIKE 去猜。如果团队用的是 SQLServer 而不是 MySQL这套 DDL 只需要把自增写法从 AUTO_INCREMENT 改成 IDENTITY(1,1)Spring Boot 侧改一下驱动坐标即可ORM 代码基本不用动。2.3 最小工程骨架pom.xml 依赖怎么选简历系统的依赖不需要多够用即可。下面这份是我会用于起步的 pom 片段parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-spring-boot3-starter/artifactId version3.5.7/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency /dependenciesspring-boot-starter-web 提供 MVC 和嵌入式服务器MyBatis-Plus 负责数据访问选择它是看重分页插件和条件构造器在中小团队里的上手成本mysql-connector-j 是 MySQL 8 的驱动坐标注意旧教程里经常出现的 mysql-connector-java 在 Spring Boot 3 里已经改名validation 里装着 NotBlank、Size 这些参数校验注解。写这套依赖时我不顺手加 spring-boot-starter-actuator除非确定要暴露哪些端点。actuator 未授权访问是简历系统这类内部工具最容易踩的坑有人配上 actuator 图方便把 management.endpoints.web.exposure.include 配成*heapdump 和 env 端点就把内存快照和配置明文全部露出去。加之前先想清楚只有 health 和 info 够不够用。对应的 application.yml 关键配置spring: datasource: url: jdbc:mysql://localhost:3306/resume?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: change_me servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: map-underscore-to-camel-case: trueurl 里的 characterEncoding 和 serverTimezone 是中文场景的两个高频坑缺前者中文乱码缺后者 MySQL 8 直接报时区错误。servlet.multipart 两个参数决定上传上限默认值是 1MB 和 10MB简历 PDF 稍大一点就会被拦在 Controller 之外所以单独强调。map-underscore-to-camel-case 让数据库的下划线命名自动映射到实体的驼峰字段避免每个字段都写 TableField。这套配置在 Spring Boot 3.x 上跑过将来升 4.x 主要看 starter 坐标是否调整四层架构和配置结构不会变。3. 简历文件上传从 MultipartFile 到目录落盘再到写库3.1 上传接口的请求设计与参数约定前端用form enctypemultipart/form-data或者 axios 的 FormData 提交后端对应方法PostMapping(/upload) public ResultLong upload(RequestParam(file) MultipartFile file, RequestParam(candidateName) String candidateName, RequestParam(value position, required false) String position) { if (file.isEmpty()) { throw new BizException(400, 上传文件不能为空); } if (candidateName.isBlank()) { throw new BizException(400, 候选人姓名不能为空); } return Result.ok(resumeFileService.upload(file, candidateName.trim(), position)); }RequestParam(file) 要求请求里 multipart 表单的字段名必须是 file前端如果写成 fileList这里直接收到 400candidateName 用 trim() 去掉首尾空格这是中文输入法下复制粘贴最常见的脏数据来源。BizException 是自定义运行时异常配合 RestControllerAdvice 统一转成 JSON 响应不要在 Controller 里逐段 try-catch 再手动拼错误信息。3.2 文件名处理与路径穿越防护有一个原则必须写死在代码里原始文件名不能直接拼进存储路径。private String buildStoredFileName(String originalFilename) { String ext Optional.ofNullable(originalFilename) .map(name - name.lastIndexOf(.) 0 ? name.substring(name.lastIndexOf(.)) : ) .orElse() .toLowerCase(); ListString allowed List.of(.pdf, .doc, .docx); if (!allowed.contains(ext)) { throw new BizException(400, 仅支持 pdf、doc、docx 格式); } return UUID.randomUUID().toString().replace(-, ) ext; }originalFilename 是浏览器传的攻击者可以把它写成 ../../../etc/crontab 这类内容。如果直接 new File(uploadDir, originalFilename) 拼进去路径穿越就能把文件写到 uploadDir 之外。这里的解法有两层存储名完全由服务端用 UUID 生成原始文件名只作为元数据存库扩展名用白名单而不是黑名单白名单天然拦截了 .jsp、.php 这些可执行后缀。UUID 重命名顺带解决两个平凡问题同名文件互不覆盖、中文文件名在某些文件系统上的编码烦恼。目录也要按日期分片我一般按月建目录String monthDir LocalDate.now().format(DateTimeFormatter.ofPattern(yyyyMM)); Path target Paths.get(uploadRoot).resolve(monthDir).resolve(storedFileName); Files.createDirectories(target.getParent()); file.transferTo(target);单个目录里塞几万份 PDF 后列目录和后续清理任务都会变慢按月份拆开后每个目录只有几百个文件日常维护、按时间清理都顺手。Files.createDirectories 必须在 transferTo 之前调用否则目录不存在时 transferTo 直接抛 NoSuchFileException。3.3 大小限制和临时文件阈值spring.servlet.multipart 参数怎么定参数默认值简历系统建议值说明spring.servlet.multipart.max-file-size1MB10MB单文件上限超过后 MultipartException 不会进 Controllerspring.servlet.multipart.max-request-size10MB20MB整个请求体积上限含文件外的表单字段spring.servlet.multipart.file-size-threshold0B2KB文件超过该值先写临时文件小于该值驻留内存max-file-size 和 max-request-size 的区别常被忽略前者管单个文件后者管整次 multipart 请求。上传简历时如果还带几个表单字段请求实际体积略大于文件本身两个值都调大更省心。file-size-threshold 默认是 0B意思是所有上传文件都先落临时文件改成 2KB 之后小文件驻留内存直接处理大文件才走磁盘减少无谓的 IO。另外如果系统前面还有 nginx 做静态资源和请求转发需要把 nginx 的 client_max_body_size 同步调大否则请求在网关层就被 413 拦下应用日志里什么都看不到。3.4 落盘与写库的顺序数据库事务管不到文件系统Service 层把两件事串起来Transactional public Long upload(MultipartFile file, String candidateName, String position) { StoredFile stored fileStore.store(file); ResumeFileEntity entity new ResumeFileEntity(); entity.setCandidateName(candidateName); entity.setPosition(position); entity.setFileName(file.getOriginalFilename()); entity.setFileUrl(stored.relativePath()); entity.setFileSize(stored.size()); entity.setStatus(0); resumeFileMapper.insert(entity); return entity.getId(); }Transactional 放在 Service 方法上不是 Controller——Controller 只管把参数递给 Service。数据库事务管的是库里的行管不住磁盘上已经写出的文件。两个顺序各有代价先落盘再写库写库失败会留下孤儿文件先写库再落盘落盘失败会留下孤儿记录。我一般选先落盘再写库因为孤儿文件可以用半小时级的定时任务清理——扫 uploadRoot 下早于当前时间、且在 DB 里查不到记录的.pdf、.doc、*.docx 直接删反过来清理孤儿记录要动数据库心理负担大得多。这个取舍定下来上传链路就完整了。4. 简历检索、分页与状态流转4.1 分页插件怎么配多条件查询怎么写MyBatis-Plus 3.5 之后配置分页插件只需一个配置类Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }不配这个 Bean 的话selectPage 只会全量查出来再内存分页数据一多直接内存溢出。查询服务的关键写法public IPageResumeFileVO pageQuery(ResumeQuery query) { PageResumeFileEntity page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperResumeFileEntity wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getCandidateName()), ResumeFileEntity::getCandidateName, query.getCandidateName()); wrapper.eq(query.getStatus() ! null, ResumeFileEntity::getStatus, query.getStatus()); wrapper.eq(StringUtils.hasText(query.getPosition()), ResumeFileEntity::getPosition, query.getPosition()); wrapper.orderByDesc(ResumeFileEntity::getCreatedAt); IPageResumeFileEntity entityPage resumeFileMapper.selectPage(page, wrapper); return entityPage.convert(entity - convertToVO(entity)); }LambdaQueryWrapper 的每个条件第一个参数是布尔开关false 时整条条件不拼进 SQL这是它比手写 XML 拼接省心的地方。eq 用等值匹配定位 position 和 statuslike 用在候选人和岗位名称上但注意别对这个字段用 like——content_text 是几万字的长文本前导通配符会让 MySQL 放弃索引全表扫。至于 JPA 和 MyBatis 的选型简历系统这种查询条件要精确控制的场景我更倾向 MyBatis 系如果团队已经习惯 Spring Data JPA用 JpaRepository 也能做分页只是多条件过滤要写 Query 或者 Specification样板代码会多一些。4.2 状态流转用一张转移表替掉散落的 if简历状态是典型的业务流程实体不应该是谁想改就改。常见设计是维护一张允许转移的规则表当前状态允许流向业务含义0 待初筛1 面试中、2 已淘汰HR 初筛后进入面试或直接淘汰1 面试中2 已淘汰、3 已入职面试结束的两种终局2 已淘汰1 面试中候选人复活重新进入流程3 已入职无终态实现时把规则收敛到一张 Mapprivate static final MapInteger, SetInteger ALLOWED_TRANSITIONS Map.of( 0, Set.of(1, 2), 1, Set.of(2, 3), 2, Set.of(1) ); Transactional public void changeStatus(Long resumeId, int targetStatus) { ResumeFileEntity entity resumeFileMapper.selectById(resumeId); if (entity null) { throw new BizException(404, 简历不存在); } SetInteger allowed ALLOWED_TRANSITIONS.get(entity.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BizException(400, 非法状态流转: entity.getStatus() - targetStatus); } resumeFileMapper.updateById(ResumeFileEntity.builder() .id(resumeId).status(targetStatus).build()); }把状态规则收敛到一张 Map 里比在各个接口里散落 if 判断好维护得多加新状态只改一处别人读代码时一眼就能看到整张流转图。并发场景下两个 HR 同时操作同一份简历会互相覆盖如果真要严谨给表加一列 version更新时 set status #{target}, version version 1 where id #{id} and version #{oldVersion}配 MyBatis-Plus 的 Version 注解就能做乐观锁简历系统内部用可以先不做但要留这个口子。4.3 详情页组合查询别在循环里查库简历详情页要展示主表加技能列表加工作经历。最容易写坏的版本是列表接口里 for 循环每行再查一次技能表也就是 N1。两个常见对策详情场景主表查出后按 resume_id 分别查两张从表列表场景先把本页 resume_id 收集成 List再一次性查从表并按 resumeId 分组。MyBatis-Plus 的 selectList 加 in 条件就是干这个的ListLong resumeIds entityPage.getRecords().stream() .map(ResumeFileEntity::getId).toList(); ListResumeSkillEntity skills resumeSkillMapper.selectList( new LambdaQueryWrapperResumeSkillEntity() .in(ResumeSkillEntity::getResumeId, resumeIds)); MapLong, ListResumeSkillEntity skillMap skills.stream() .collect(Collectors.groupingBy(ResumeSkillEntity::getResumeId));in 查询是一次网络往返拿回整页数据groupingBy 在内存里按简历 ID 分组VO 组装时直接从 Map 取值。这个写法在简历系统里比 MyBatis 的 collection 嵌套映射更直白也更容易调试——SQL 日志里一眼能看到查了几次库。5. 用 Lucene 换掉 LIKE 前导通配符简历秒出简历系统的检索诉求其实很朴素HR 搜Java 微服务希望命中正文里同时提到这两个词的候选人。数据库 LIKE %Java 微服务% 的问题出在前导百分号B 树索引对它完全失效表里几万份简历、每份 content_text 几万字就是几个 GB 的串行扫描。Java 生态里做全文索引的常规武器就是 Lucene它把 content_text 倒排成词项查询时先查词典再取倒排链复杂度和 LIKE 不是一个量级。更关键的是中文分词交给 smartcn不会出现简历被切错词导致搜不到。把 Lucene 接进来依赖只需两块dependency groupIdorg.apache.lucene/groupId artifactIdlucene-core/artifactId version9.11.1/version /dependency dependency groupIdorg.apache.lucene/groupId artifactIdlucene-analysis-smartcn/artifactId version9.11.1/version /dependency写入索引的核心片段IndexWriter writer new IndexWriter(indexDir, new IndexWriterConfig(new SmartChineseAnalyzer())); Document doc new Document(); doc.add(new StringField(id, resumeId.toString(), Field.Store.YES)); doc.add(new TextField(content, contentText, Field.Store.NO)); writer.addDocument(doc); writer.commit();id 用 StringField因为 Lucene 里数值字段要精确匹配通常转成字符串content 用 TextField这样 analyzer 会分词建倒排。Field.Store.NO 的意思是索引里不存原文——简历正文已经在 MySQL 的 content_text 里没必要在 Lucene 里再存一份。查询侧的核心片段DirectoryReader reader DirectoryReader.open(indexDir); IndexSearcher searcher new IndexSearcher(reader); QueryParser parser new QueryParser(content, new SmartChineseAnalyzer()); Query query parser.parse(keyword); TopDocs topDocs searcher.search(query, 20); for (ScoreDoc scoreDoc : topDocs.scoreDocs) { Document hit searcher.doc(scoreDoc.doc); Long resumeId Long.valueOf(hit.get(id)); // 回表查数据库组装完整简历 }QueryParser.parse 把用户输入转成 Query搜出来的是简历 ID 列表再回表查 MySQL 补全展示字段。用 search(query, 20) 而不是 search(query, Integer.MAX_VALUE)是防止命中几百份时把内存打爆。最后一个容易忽略的坑是索引一致性。简历被修改或者淘汰后Lucene 里的旧文档不会自己消失。实用做法是更新时先删再加同一线程内完成writer.deleteDocuments(new Term(id, resumeId.toString())); writer.addDocument(doc); writer.commit();解析 PDF 获取 contentText 在 Service 层做PDF 用 pdfbox 的 PDFTextStripper 提文本doc 用 poi 的 HWPFDocument 或 XWPFDocument 提文本提完再交给 Lucene。把 deleteDocuments 放在简历更新的同一个业务方法里、再兜底一个每天凌晨的全量重建任务这套简历系统的检索部分就算闭环了。本文还有配套的精品资源点击获取