企业官网建设流程全解析

1. 为什么要做这个求职就业平台：需求切口与项目定位

高校就业工作这些年有个很尴尬的现实：学校就业指导中心手里的企业资源不少，学生也急着找工作，但两边就是接不上。企业HR把岗位信息发到邮箱、微信群、纸质海报，学生投简历靠手动下载模板再发邮件，整个过程既没有统一入口，也没有流程追踪。等学生问起来“我投的那家到底看了没有”，HR也说不清楚，就业老师更是一头雾水。

我做的这套“某高校学生求职就业平台”（项目代号24440246），核心就是想解决这个信息断层问题。它不是要做成智联、前程无忧那种面向全社会的大而全招聘网站，而是把边界收在“高校”这个场景内：学生、企业、就业办老师三方共用一个系统，岗位发布有审核、简历投递有记录、面试安排有提醒、就业数据有统计。

从技术角度讲，这个题目出得也很典型。Spring Boot做后端骨架、MyBatis Plus操作数据库、Shiro或Sa-Token管权限，前端用Vue或Thymeleaf都行。麻雀虽小五脏俱全，几乎覆盖了Java后端开发日常会用到的所有基本功：表结构设计、文件上传、权限拦截、定时任务、数据统计、异常兜底。所以这个项目不只是“一个系统”，更是练手和校招简历上都能拿得出手的完整闭环。

再说直白一点，这种平台最适合谁来用。某高校就业指导中心的老师，想要一个不需要额外付费、能自己维护、数据能导出的工具；校内学生需要的是能看见真实审核过的岗位，而不是全网搜罗的垃圾信息；合作企业需要的是一个能快速发布岗位、收简历、约面试的窗口。这三方诉求叠在一起，就是系统的核心原型。

这期内容我不打算只贴代码，而是把整个项目从零到一的决策过程、表结构设计、权限处理、推荐逻辑、搜索优化、通知机制这些实实在在的落地细节都拆开讲，包括哪些坑我踩过、哪些方案我换过三版才定下来。无论是准备课程设计、毕业设计，还是想给自己的作品集加一个完整项目，这篇都有参考价值。

2. 技术选型背后的取舍：Spring Boot生态与配套组件怎么定

2.1 后端框架：为什么锁死Spring Boot而不是SSH或SSM

用Spring Boot几乎是没悬念的选择。这个项目要同时处理用户认证、RBAC权限、文件上传、数据统计报表、定时任务推送，如果还像早年SSH那样写一堆XML配置，光配置文件就够喝一壶。Spring Boot的自动配置、starter机制、内嵌Tomcat，能让我把精力全部放在业务代码上而不是环境搭建上。

不过有一点必须说清楚，用Spring Boot不代表不用理解底层。比如自动配置虽然省事，但它的优先级机制还是得懂——我们自己定义的Bean和自动配置的Bean冲突时，默认我们自己的生效。这个特性在二开某个通用组件时会非常有用。另外，Spring Boot版本我选了2.7.x系列，原因很简单，Spring Security和Sa-Token对这代版本的兼容性验证最充分，JDK用的是1.8/11，不追新，稳定压倒一切。

2.2 持久层与数据库选型：MyBatis Plus与MySQL的组合逻辑

持久层我直接用了MyBatis Plus。有人可能问为什么不直接用MyBatis，或者上JPA。我的理由是：这个系统有大量单表CRUD操作，比如学生表、简历表、投递记录表、企业表，用MyBatis写XML太啰嗦；JPA的自动建表和懒加载坑对新手又不太友好。MyBatis Plus就在中间取了个平衡——单表查询零SQL，复杂统计用XML手写，分页插件一插就好。

数据库选型MySQL 8.0，是因为这个项目里会有不少统计类查询，比如按学院统计就业人数、按月统计岗位发布量，MySQL 8.0对JSON字段、窗口函数的支持比5.7强很多。后面做就业趋势分析时，直接一条SQL就能算出月度同比，我用窗口函数写的时候就直呼当初选对了。

2.3 权限管理：Sa-Token替代Shiro的实战理由

权限这块是我踩坑最多的部分。最初用Shiro，但发现和Spring Boot 2.7整合时还需要自己配Web过滤器链、SessionDAO、密码匹配器，登录会话的并发控制也得手动设计。后来换成Sa-Token，体验提升非常明显：登录、登出、Token校验、踢人下线、权限注解，几乎都是开箱即用。

用Sa-Token的另一个原因是它的注解权限控制底层是AOP切面实现的，和Spring Boot配合特别顺。比如我需要一个“企业HR只能操作本公司岗位”的校验，按传统写法要在每个接口里写业务判断，现在直接用自定义注解加Sa-Token的路由拦截，一行@SaCheckPermission("company:job:edit")就能搞定。

这个项目里我把权限模型设计成三大角色：学生、企业端（HR）、就业办管理员。学生角色能看到岗位、投递简历、管理个人简历；HR能发布岗位、查看收到的简历、发起面试邀请；管理员拥有全系统最高权限，包括企业资质审核、岗位内容审核、就业数据导出。注意，这里没有给普通学生任何后台管理权限，一开始就把权限收敛清楚，后面所有业务都能顺畅很多。

3. 数据库表结构核心设计：学生、企业、岗位、简历、投递五张核心表的边界划分

3.1 三端用户模型：用一张user表还是分三张表

这是这个项目里第一个值得认真思考的设计问题。学生、企业HR、管理员三者之间，共有的属性是登录名、密码、头像，不同的是各自的业务字段——学生要存学号、专业、毕业年份；企业要存公司名、统一社会信用代码、行业类别；管理员字段最少。

我用的是“一张独立账号表 + 三张扩展详情表”的模式。账号表只存登录凭证和角色ID，扩展表通过主键关联账号ID。好处在于认证逻辑统一：登录时只查账号表，认证通过后再按角色去取详情，不用写三套登录逻辑。缺点是连表查询变多，但项目规模不大，完全可接受。这比一张user表塞所有字段，或者完全分三张表互相独立可维护性强得多。

实际建表时几个关键字段：

• 账号表：id、username、password（加盐哈希）、role_id、status（禁用/启用）、create_time。
• 学生扩展表：id与账号表主键一致、student_no、real_name、school_name、major_name、degree、graduate_year、phone、email、resume_id。
• 企业扩展表：company_name、credit_code（统一社会信用代码，可以做唯一校验）、industry_type、company_size、address、intro、license_url（营业执照附件）、audit_status（0待审核、1通过、2驳回）。

这样划分之后，管理员在后台审核企业资质时，只需要拿audit_status做筛选，不需要动登录账号的数据，逻辑非常干净。

3.2 岗位表与简历表：业务主数据的设计要点

岗位表是企业的核心产出物。字段要覆盖标题、类别、工作城市、薪资区间、学历要求、经验要求、发布时间、状态。这里容易踩的坑是：薪资别只用一个字符串存“面议”，最好拆成salary_min、salary_max两个整数，后面做薪资筛选才能走索引范围查询。

简历表我拆成了主表和详情两个部分。主表存学生的基本信息快照，比如姓名、手机号、邮箱、院校专业、求职意向、期望城市、自我评价；详情表存教育经历、实习经历、项目经历、技能标签这种多条结构的数据。为什么不直接一个JSON字段搞定？因为“投递后简历被HR查看”的场景里，HR需要在一屏内纵向浏览学生完整履历，分表存，前端渲染和后续扩展（比如导出PDF简历）都比JSON方便。

3.3 投递记录表：B端与C端交互的枢纽

投递表是整个系统里数据增长最快、也是最能产生统计价值的表。表结构包含：student_id、job_id、company_id、resume_snapshot_id（简历快照）、status、deliver_time、read_time、interview_time。

status字段的状态流转是核心设计，我用整数递增来表示：0=已投递、1=被查看、2=已邀请面试、3=已录用、4=已拒绝、5=学生主动撤回。每次变化都通过一个状态机校验，比如职位已下线就不能再从”已投递“走到”已邀请面试“。状态机校验写在校验服务里，维护起来很清晰。

另外一个容易被忽略但在“查看投递详情”时很关键的字段是resume_snapshot_id。学生投递时，系统会把当前简历内容做一份快照存储，这样即使学生之后修改了简历，HR当时看到的版本依然不会丢。这个设计完全是从实际招聘场景推出来的——用人单位如果只看到最新的简历，其实对候选人真实成长过程的判断反而不全面。

4. 职位推荐的匹配逻辑：从基础SQL到可解释的加权评分

4.1 一次性把需求聊透：推荐到底要解决什么问题

很多做简历系统的项目在“推荐”这块就是装样子，比如按发布时间倒序输出就算完事。但要满足就业场景，推荐必须解决三个问题：学生打开首页能不能快速看到和自己相关的岗位；岗位列表能不能按要求过滤；推荐结果能不能解释为什么推这个岗位给我。

我采用的是一套“基础过滤 + 推荐评分排序 + 人工置顶干预”的策略。基础过滤从硬条件开始：学历要求、毕业年份、工作城市。比如一个本科生不会看到要求硕士及以上的岗位，不符合城市预期的也不会展示。这个过滤在SQL层完成，保证推荐池干净。

然后进入评分排序阶段。评分不是玄学，而是把它拆成可计算的维度：

• 专业匹配度：岗位要求的专业标签和学生本专业做文本匹配，完全匹配40分，部分匹配20分，不匹配0分。
• 技能匹配度：岗位技能关键词列表和学生技能标签列表的交集数量，每交集一个加15分，上限30分。
• 活跃度权重：企业最近7天内是否更新过该岗位，更新的加20分，超过30天未更新的扣减10分。
• 时间衰减：投递时间按小时做指数衰减系数，越新的岗位加权越高（权重上限10分）。

最终得分score = 专业分 + 技能分 + 活跃分 + 时间分。排序时score降序，同一分数按发布时间降序。这个公式看上去简单，但因为每个维度的计算都可以在前端点开看到明细，学生问“为什么这个岗位排在最上面”时，我可以直接告诉他——你的专业匹配了，技能交集有3个，而且这家公司昨天刚更新过岗位。

4.2 推荐召回与排序落地：SQL、内存、本地索引的组合

推荐实现没有引入Elasticsearch，原因是项目规模不值得再扛一套中间件。岗位表全量数据在万级以内，本地内存足够。具体做法是：启动时用ApplicationRunner把岗位表相关字段加载进内存，构建一个ConcurrentHashMap作为推荐索引，分类维度建一个倒排Map（key是专业名或技能标签，value是岗位ID列表），推荐时先按学生资料做两个倒排取交集，再进入评分阶段。

这个方案的好处是查询性能极好，几十万个并发请求压测下来平均响应在几十毫秒以内，相比直接查数据库的关联表，体验差距还是很明显的。缺点是需要自己维护内存和数据库的一致性，好在岗位发布频率不高，定时任务每5分钟同步一次增量即可。

如果想要更简单的方案，不做内存索引、直接在SQL里JOIN打标也可以。只是数据到三万条左右时，多个LIKE条件会让查询变慢；内存索引方案能撑到几十万量级不换技术栈。

4.3 冷启动和推荐干预：新学生、新岗位怎么处理

冷启动问题在实际使用中非常常见：一个刚注册的大三学生，资料还没填完，系统没有他的简历、没有专业标签，首页的推荐很可能是空的。处理办法是默认展示“最近更新岗位列表”，等到简历资料完整度超过70%后再启用个性化推荐。

推荐干预方面，需要支持就业老师把某个重点企业的岗位强制置顶。实现上：岗位表加了一个top_weight字段，置顶权重为100，在score之后二次排序，保证置顶优先。这个操作放在管理后台的“岗位运营”模块里，方便老师按月份、按重要企业做手动调整。

5. 搜索功能与查询性能优化：日期范围、复合筛选与缓存策略

5.1 搜索需求拆解：用户到底想要什么结果

平台搜索功能主要集中在岗位搜索和人才搜索两块。学生的搜索主要集中在岗位，按关键词、城市、薪资范围、学历、发布时间做筛选；HR搜索则是在庞大的人才简历库里按专业、学校、技能、求职意向找人。最初我直接在MySQL里用LIKE '%关键词%'，但在后台数据量起来之后就明显吃力。

一个有效优化方法是：构建一张独立的“检索辅助表”，核心字段是job_id、title、tags_string、major_names_string、city、salary_min、salary_max、degree、publish_time。把多个业务表的冗余字段压成一张宽表，索引全部建在这张表上。搜索一律从这张表走，业务主表只负责详情查询。宽表通过监听业务表变化来同步更新。

这张表的索引设计也很有讲究：城市、学历、薪资上下限建普通索引，发布时间建降序索引；关键词搜索因为用了前缀匹配，建(title, tags_string)的联合索引依然可以命中。在这种设计下，搜索查询的响应时间一般能控制在100毫秒以内。

5.2 缓存设计：Redis到底缓存什么、不缓存什么

这个项目里Redis主要干三件事：岗位详情缓存、首页热点数据缓存、验证码。岗位详情因为会被多次点击，缓存在Redis里用Hash结构存，过期时间设为10分钟，过期后回源数据库并回填。首页的热门推荐列表缓存一份按JSON序列化后的列表，5分钟过期，避免每次打开首页都去内存索引里重新计算评分。

需要注意的是，缓存里坚决不存用户敏感信息，比如简历详情、手机号、邮箱。这些数据宁可每次查库，也不能为了性能牺牲私隐性。所以这里给项目里也定了条铁律：一切需要登录才能看到的数据，一律不过Redis。

验证码这块用的是带过期时间的缓存匹配策略。图形验证码内容存Redis，键是UUID，值用MD5加密存储，有效期120秒，登录成功后立即删除。这样既防止验证码反复使用，又避免数据库压力。

5.3 大列表与大分页：覆盖百万级数据量的深分页优化

平台上线稳定后，岗位表和投递记录表增长速度很快，MySQL在深分页时会出现明显的性能下降，比如翻到第二万条记录时，LIMIT 20, 20仍然会把前两万条全部扫描一遍再丢弃，效率很低。

优化方案是改走“延迟关联”：先用覆盖索引找到目标ID，再用主键关联回原表取详情数据。实践下来，100万条数据的环境下，深分页响应时间从1.2秒下降到40毫秒左右。核心SQL是这样的：

-- 优化前（深分页慢） SELECT * FROM job_info WHERE status = 1 ORDER BY publish_time DESC LIMIT 200000, 20; -- 优化后（延迟关联，速度快十几倍） SELECT a.* FROM job_info a INNER JOIN ( SELECT id FROM job_info WHERE status = 1 ORDER BY publish_time DESC LIMIT 200000, 20 ) b ON a.id = b.id;

这个操作原理其实很简单：子查询里只用主键ID做排序和分页，走的是覆盖索引，不会回表；外层再按主键批量取数据，每行最多一次回表。成本大幅度下降。

6. 权限与安全落地的几个细节：Sa-Token集成、密码存储与操作日志

6.1 Sa-Token的路由拦截与角色权限校验

引入Sa-Token之后，第一步是登录接口签发Token，然后通过拦截器对所有请求做登录状态校验。这里有个很重要的设计：拦截全部请求，包括静态资源和OpenAPI，不符合条件的直接返回401，而不是在Controller里各自判断。统一拦截才能保证不遗漏。

角色权限用的是@SaCheckRole("company")这类注解。比如岗位发布接口，就加@SaCheckRole("company")；后台审核岗位接口，就加@SaCheckRole("admin")。注解不生效的原因八成是没写SaInterceptor到WebMvcConfigurer里，记得注册拦截器并设置注解鉴权开关。

6.2 密码安全：MD5不安全，直接用加盐哈希

这是个所有项目都要过的关。明文存储密码是绝对不可接受的，即使用MD5也有巨大风险，因为彩虹表早就把常见的密码都算好了。正确做法是加盐哈希，我用的方案是：用户注册时生成一个随机盐值（例如8字节），将盐值 + 密码拼接后做10万次SHA-256迭代，最终存储的格式为盐值$哈希值。登录校验时从数据库取出盐值，再按同样方式计算比对。

比SHA-256更稳妥的是直接用BCrypt，但我考虑到项目可能有老系统迁移过来的场景，不能保证所有历史密码都重新生成，所以采用了自定义哈希处理器兼容新旧密码。这里不纠结，反正记住一点：不允许任何明文或MD5值出现在用户表里。

统一密码策略做了强制校验，包括长度至少8位，必须包含数字和大小写字母。注册时直接拦截校验，防止弱口令进系统。这个不复杂，但能从源头杜绝大量安全风险。

6.3 操作日志：谁在什么时候对什么数据做了什么

平台的敏感操作很多：企业驳回岗位、管理员审核企业、学生撤销投递……一旦出问题追溯不到就非常被动。所以我加了一套操作日志切面，基于Spring AOP，用一个@OpLog(module = "岗位管理", action = "审核")注解标记在需要记录的方法上，切面统一把当前登录人ID、操作模块、操作类型、请求参数、耗时、IP地址存库。

这套方式对业务代码几乎零侵入，审计查询页面直接按照操作人、模块、时间范围筛选就能定位问题。

实际排查案例：某公司HR反馈岗位被莫名下线了，查操作日志迅速定位是某管理员在审核时误点了下线按钮，操作时间、操作人、请求参数全部清晰可见，很快处理完纠纷。如果没有操作日志，只能去猜，甚至可能要翻好几套系统的数据才能找到原因，那体验太糟糕了。

7. 面试通知与站内消息：推送、阅读状态闭环的设计

7.1 通知渠道选择：站内信为主，邮件为辅

面试邀请、投递状态变化这类通知，最靠谱的方式是站内消息。因为校内学生基本都会登录系统看进度，站内信既能保证不被手机邮件App的垃圾箱吞掉，又能维护一个消息列表让学生按时间回看。

站内消息表设计字段比较简单：receiver_id、sender_type、content、type（1=投递状态、2=面试邀请、3=管理员通知）、is_read、read_time、create_time。

邮件通知我作为辅助渠道接入了JavaMailSender。触发点是：学生注册成功时发欢迎邮件、简历被查看时给HR发提醒邮件。之所以没有把通知主流程放在邮件上，是因为第三方邮件服务对单日发送量有限制，且延迟不可控，做为辅助渠道可以防止主渠道挂掉时用户完全没感知。

7.2 定时任务与状态驱动的通知触发

通知的触发机制我选择“由业务流程直接驱动”和“定时任务兜底”双轨运行。什么是直接驱动？比如HR把投递状态从“已投递”改为“已邀请面试”，在状态变更的服务方法里直接调用消息发送组件，插入站内信。

那定时任务兜底干什么？处理两类场景：一是岗位下线时要批量通知所有投递该岗位的学生；二是简历超过7天未被查看时，系统自动给HR发一次“你有一份简历待处理”提醒。定时任务我用Spring的@Scheduled实现，配置了一个每5分钟执行一次的扫描方法。

一个真实的教训：最初我把所有通知都交给定时任务批量轮询，结果任务执行频率太低，学生投递简历后很久才收到“已查看”状态更新，体验很糟糕。改成事件驱动后，状态变更毫秒级就能推送到站内信，定时任务只用处理低频兜底场景。这个改动虽然逻辑上复杂了一点点，但对用户感知的提升非常明显。

8. 简历上传与解析：文件存储、格式校验和预览的实现选择

8.1 简历上传的技术选型：OSS还是本地存储

学生简历我做了两种提交方式：在线编辑（表单）和文件上传（PDF/Word）。在线编辑的数据直接进简历详情表，文件上传则涉及存储选型。

考虑项目的“高校本地化”属性，我选择存本地磁盘，没上对象存储OSS。理由：上传量不会非常大（一个文件平均2MB），服务器磁盘充足，而且本地存储可以方便地走内网映射给就业办做下载备份。如果用OSS，每年流量费用反而成了额外开销，运维成本也高。

本地存储的目录结构为：/data/resume_files/YYYYMM/用户ID_简历.pdf，文件名包含用户ID和时间，可以避免重名覆盖问题。上传接口限制为5MB，格式只放行application/pdf、application/msword、application/vnd.openxmlformats-officedocument.wordprocessingml.document三种MIME类型。

8.2 文件预览和转换：PDF统一方案

文件预览本身有兼容性问题。Word文件在浏览器低版本下没法直接打开，PDF则相对通用。我的方案是用户上传的任何Word文件都转成PDF存储预览副本，预览时统一只访问PDF。转换工具用的Apache POI + OpenOffice服务，按队列方式异步处理。

转换层设计了一个任务表：file_id、origin_path、preview_path、status、error_msg、create_time。上传成功后先插队，定时任务扫描待转换记录，调用服务转换，把路径回填。转换失败不阻塞上传成功流程，只记录错误，管理员可以在后台看到失败原因重试。

这个设计在真实环境中帮了大忙——有个学生上传的Word实际是空模板，POI解析直接抛异常，如果没有任务表记录错误，他永远不知道自己的文件转不出来，只会不停换后缀重传。有了任务状态和错误提示，问题就能被主动暴露和修复。

9. 数据统计报表：就业办管理员的统计需求怎么落地

9.1 统计维度拆解：从“一页看全貌”到“按条件下钻”

就业办的问题往往是：领导突然要一个“今年全校就业率”、“各学院签约人数排名”、“专业对口率”。如果每天都让管理员去导出一堆Excel再手工加工，那系统的价值就被大打折扣。

我建的统计模块分三个层级：总览卡片（今日新增岗位、本周投递量、在校生简历完善率）、趋势图（近12个月投递量折线）、分类报表（按学院、专业、学历分层统计就业数据）。

底层统计SQL的写法要考虑效率。比如按学院统计就业人数时，需要关联学生表、投递表、岗位表，并且限定“当前在职（status >= 2）”。这个查询除了加复合索引外，我还用缓存服务把统计结果缓存30分钟，因为报表数据不要求秒级实时，完全不用每次刷新都查库。

9.2 报表导出：EasyExcel解决大批量数据流式导出

后台报表导出功能用EasyExcel实现。它的核心优势在于流式导出，不会像POI一次性全量加载到内存那样把JVM撑爆。

示例代码，按条件导出投递明细：

public void exportDeliverRecords(Long companyId, HttpServletResponse response) { String fileName = "投递记录_" + System.currentTimeMillis() + ".xlsx"; response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setCharacterEncoding("utf-8"); response.setHeader("Content-Disposition", "attachment;filename=" + URLEncoder.encode(fileName, "UTF-8")); // 从数据库按流式查询 List<DeliverRecord> records = deliverRecordMapper.selectListByCompany(companyId); ExcelWriter writer = EasyExcel.write(response.getOutputStream(), DeliverRecord.class).build(); WriteSheet sheet = EasyExcel.writerSheet("投递记录").build(); writer.write(records, sheet); writer.finish(); }

唯一要提醒的是，导出接口必须做权限校验，否则企业HR可以随意拉全站数据。我的校验是：公司ID必须等于当前登录用户所属公司ID，从根源上杜绝串数据。

10. 部署与上线心得：内网穿透、HTTPS、反向代理和日志监控

10.1 部署架构：一台服务器如何撑起整个平台

项目部署用的是基础的单机架构，一台8核16G的云服务器足够。Nginx做前端静态资源服务和反向代理，Spring Boot应用挂载在8080端口，MySQL和Redis分别占3306、6379。监控部分用spring-boot-actuator暴露健康检查接口，配合定时脚本做进程存活检测，挂了自动重启。

前后端分离部署时，跨域问题很典型。我在后台配置了统一的CORS允许源，但更稳妥的做法是把前端和后端都挂在同一个域名下，用不同路径区分访问，这样浏览器同源策略直接规避跨域。Nginx配置里做了两段转发：/api/开头的请求转发到后端8080端口，其他路径直接走前端静态文件。

10.2 HTTPS与安全配置

项目上线必须启用HTTPS。证书我用的免费证书（有效期90天），配置在Nginx层，证书到期前需要写个脚本自动续期，否则到期后整个站会突然无法访问。这个问题我曾亲眼见过某服务因为忘续证书，所有客户端全部报证书错误，排查了几小时才发现原因。

Nginx反向代理到后端时还需要设置几个响应头：X-Content-Type-Options: nosniff防MIME嗅探攻击、X-Frame-Options: DENY防点击劫持、Strict-Transport-Security强制走HTTPS。这三个头加上之后，安全报告里的高危项基本能清掉一半。

10.3 日志监控与问题排查经验

后端日志采用logback，按天滚动，保留30天。日志格式里要带上traceId，这样排查问题时能从请求入口一路追踪到业务层和SQL。大流量时日志量很大，磁盘空间不够是常态，所以日志按级别拆文件：error.log单独存储，只保留7天，方便快速抓错。

平台运行后遇到过两次比较有代表性的线上问题：

第一次是某个查询接口突然从快变慢，排查发现某个学生上传了一份超大的简历文件，导致某条统计SQL扫描的行数暴涨。解决方案是在代码里对简历文件大小加硬限制，并给简历表的大字段加全文索引，问题直接消解。

第二次是内存持续走高、频繁Full GC。查GC日志发现是岗位推荐的内存索引每次全量加载时把旧引用都留在老年代，改成增量同步之后内存占用直接下降40%。这种问题在压测阶段根本发现不了，只有在真实流量和长时间运行之后才会暴露，日志和监控早接好非常关键。

11. 开发排期与建议：从0到1做这套系统的合理节奏

最后聊聊开发节奏。一个完整的求职就业平台，如果只有一个人开发，比较合理的排期是6周左右。需求调研和原型设计1周、数据库设计加核心表创建0.5周、用户认证和权限管理1周、岗位发布和投递流1.5周、简历上传和预览0.5周、搜索推荐和统计1周、联调和部署上线0.5周。

如果是团队开发，建议再压缩需求调研时间，提前把接口文档定义清楚。这里有个实际经验：早期接口定义模糊，前后端联调时经常返工。后来改为后端先生成OpenAPI格式的接口文档，前端按文档同时开发，整体节省了至少一周的联调时间。

给后续开发者几个具体建议：

• 不要一上来就抄一个完整的开源系统，那不是你的东西，遇到问题你根本不知道怎么改。从空项目起步，一步步加模块，掌握的深度完全不同。
• 安全功能不要放到最后才补，登录、密码加密、权限校验要从第一个接口就带着做。最后补安全的项目很容易出现漏洞。
• 数据统计报表模块看上去简单，实际最耗费时间。各类统计口径非常容易搞混，前期就要和就业办老师对齐“就业率”“投递转化率”这些名词的精确定义。

我做完这套系统最大的感受是：它不是一个“交差项目”，它真的可以在学校里顶一段时间用。从导师验收、学生试用、再迭代，到最后管理员每天都开着它查看后台数据，这种正向反馈对项目完成度的提升非常大。如果你也准备做类似的东西，核心建议只有一条——真的去把某个学校、某个就业办的真实业务跑一遍，比你自己凭空想象的系统有生命力得多。