1. 先想清楚：猎头公司的管理系统到底在管理什么
做猎头公司的管理系统，和做普通企业OA完全是两码事。猎头业务的本质是撮合——左手握着海量候选人简历，右手接着五花八门的职位需求，中间还夹着客户企业、合同、推荐进度、面试反馈、Offer谈判甚至后续的入职回款。这套基于Java+SSM+Flask的猎头公司管理系统，表面上看是一个常规的Web后台，但实际上它要解决的三个核心问题是：人才资源怎么沉淀、推荐流程怎么跟踪、业绩数据怎么归因。
1.1 猎头业务的三条核心链路
我接触过不少准备做毕业设计或者公司内部小系统的朋友，上来就急着建表、写接口，结果做着做着就发现业务逻辑绕不进去。所以先把业务链路理顺。
猎头公司的日常运作可以拆成三条线：
第一条是客户线。BD同事签下企业客户，约定职位需求、服务费率、付款节点。客户的招聘需求有明确属性：职位名称、薪资范围、工作地点、学历要求、经验年限、关键技术词。这条线是收入的来源，所有后续动作都围绕客户需求展开。
第二条是候选人线。猎头顾问通过招聘平台、人脉推荐、简历库搜索等方式获取候选人，电话沟通、约面、整理简历、做评估。候选人的核心数据是基本信息、工作经历、技能标签、期望薪资、离职状态、求职意向。这条线是弹药库，没有优质候选人，猎头什么也做不了。
第三条是撮合线。顾问把候选人推荐到客户职位下，形成推荐记录，然后跟踪面试（一面、二面、终面）、定薪、Offer、入职、过保。每一步都有关键节点和状态流转，而且每一步都需要时间戳记录，因为顾问的提成和公司的回款都以这些节点为依据。
1.2 为什么在Java生态里还要掺一个Flask
很多人看到这个项目标题会有一个疑问：SSM本身就能搞定Web开发，为什么要再加Flask？最初我也觉得这是为了拼技术栈亮点，但实际做下来发现，Flask在里面确实有位置。
主系统用Java+SSM，负责的是核心事务型业务：用户管理、客户信息、候选人档案、推荐流程状态、合同业绩。这些模块要求事务性强、状态机明确、并发下的数据一致性有保障，Spring的声明式事务和MyBatis的灵活SQL正好合适。
但猎头系统里还有一类场景是Flask的强项：数据统计、文本匹配、报表生成、爬虫采集。比如根据简历文本自动抽取出技术关键词，根据职位JD和候选人简历做关键词相似度匹配，这些逻辑用Python写明显更加顺手，尤其是分词和相似度计算。Python生态里有现成的Jieba分词、difflib库、Pandas数据处理，而在Java里要实现同样的功能，代码量要翻好几倍。
所以这项目的架构思路是：SSM管理端跑核心业务，Flask作为辅助服务跑算法和统计类需求，两边通过HTTP接口通信。我见过更激进的设计是直接用Spring Cloud微服务，但对一个猎头管理系统的体量来说，这完全是杀鸡用牛刀。SSM+Flask的轻量级混合方案，结构清晰、部署简单、演示效果好，课程设计或中小型公司内部系统完全够用。
1.3 系统模块划分与用例视角
把业务链路翻译成系统模块，大致分成这么几块：
人才库管理：候选人的增删改查、简历附件上传、技能标签维护、按关键词检索。这是猎头系统的核心资产，每天顾问都在这个模块里进进出出。
职位需求管理：客户企业的在招职位信息维护，包括职位描述、薪资区间、硬性要求、紧急程度，以及该职位的推荐进度看板。
推荐流程管理：创建推荐、记录面试反馈、更新Offer节点、跟踪入职和过保结果。这里需要清晰的待办提醒，比如今天哪些候选人该跟进、哪个职位三天没有新推荐。
客户与合同管理：企业客户信息、合同费率、回款记录。这块一般不会做太深，因为涉及财务的系统复杂度会上一个量级，但基本的合同信息和回款状态还是要有的。
系统管理：用户分角色登录。猎头公司里角色很简单：管理员、顾问、访客（比如企业HR被临时开了只读账号看推荐进度）。
从这里就能看出，这个系统的功能虽然没有ERP那么庞杂，但一个小型猎头团队或者一个人力资源外包部门的日常工作闭环，它是能完整覆盖的。
2. 数据库建模：用最少的表撑起猎头业务闭环
数据库设计决定了一个系统能走多远。猎头系统最忌讳的就是把简历内容直接塞进一个大字段，然后全靠LIKE查询。我建表的原则是：简历原文本可以冗余存储，同时要把简历里最有检索价值的字段（技能标签、岗位名称、工作年限、期望城市）单独拆出来建索引。
2.1 核心实体与关系梳理
我的库表设计大致是十张表。用户表ACCOUNT存登录账号和角色；企业客户表COMPANY存客户公司信息；职位表POSITION存客户发布的在招岗位；候选人表CANDIDATE存简历基本信息和归档简历文件路径；标签表TAG和关系表CANDIDATE_TAG做候选人的技能标签多对多关联；推荐表RECOMMENDATION存候选人-职位的推荐记录，状态字段一路走下去；面试反馈表INTERVIEW存放每次面试的反馈历史；合同表CONTRACT和回款表PAYMENT管客户签约和回款。
就拿状态字段来说，推荐表的状态变化就是猎头业务的生命线。我推荐的候选人和职位，怎么把状态机做清晰了，这点设计的时候要想好。
CANDIDATE表里我预留了简历原文的CLOB字段，放的是候选人简历转成的纯文本。这样做的目的是什么？一是可以做全文检索，二是给Python服务做关键词匹配时直接取文本处理，不用来回拼字段再还原。开始我觉得CLOB字段很浪费，但实际跑下来，一个JSON格式的完整简历文本也就几十KB，即便存十万个候选人，也不过几个GB，完全在MySQL可承受范围内。
2.2 人才库里的技能标签与检索设计
技能标签是猎头系统的隐含核心。比如一个Java后端候选人的简历里可能提到Spring、MySQL、Redis、RabbitMQ、分布式、高并发，这些关键词直接决定了顾问搜索时能不能找到他。
我的做法是在候选人录入或导入时，后台自动提取技能关键词写入TAG表。用Python服务做这件事很舒服：Jieba分词之后结合自带的Java技术栈关键词库做匹配，命中就写入关联关系。CANDIDATE_TAG表是简单的双字段关联，但查询时JOIN一下效率极高：SELECT candidate_id FROM candidate_tag WHERE tag_id IN (1,2,3) GROUP BY candidate_id HAVING COUNT(DISTINCT tag_id) >= 2，顾问搜“同时掌握Java和Redis的候选人”一条SQL就出来了。
真实使用中，可能有顾问录简历时偷懒不写标签，我就在CANDIDATE表里配了自动生成标签的按钮，同时录入简历时如果选了“自动解析”，前端会把原始简历文本发到Flask服务，服务端处理完回写标签，然后刷新页面就能看到。
2.3 推荐匹配逻辑的表设计支撑
自动推荐候选人这功能，系统里不是让机器完全替代人工，而是做初筛排序。逻辑很简单：职位的需求标签集合，和候选人的标签集合计算相似度。技术实现上，职位表POSITION里同样关联了一个POSITION_TAG表，职位的需求标签是HR或顾问录入的，甚至可以从JD文本里自动提取。
匹配度计算放在Flask服务里做：读取候选人的标签集合、职位的标签集合，算一下Jaccard相似系数（交集大小除以并集大小），再加上一个基础评分，然后按分值倒序返回。我在Position实体里直接存储了匹配度分值字段，这样在推荐列表里才容易做排序和筛选。
这套逻辑的表支撑不需要额外建表，只要有候选人的标签关联和职位的标签关联，服务端在内存里算完输出一个JSON就行。
2.4 字段设计里容易被忽视的几个细节
第一个是时间字段一定要用DATETIME并设默认值CURRENT_TIMESTAMP，所有业务节点的记录时间都要有，后面做统计报表全靠它。第二个是金额字段，合同金额、回款金额这类字段用DECIMAL(10,2)，永远不要用DOUBLE，否则算提成时出现0.1+0.2不等于0.3的精度问题，会被财务骂死。第三个是文件路径，面试官和顾问会上传简历附件，我的做法是路径存相对路径（如uploads/2024/06/xxx.pdf），而不是存完整绝对路径，不然换服务器全部失效。
3. 核心功能实现：从登录到推荐的一条龙实操
这个系统的编码实现，我按SSM的标准分包来做：Controller层接收请求、Service层写业务逻辑、Mapper层操作数据库。新人上手SSM最大的障碍是配置，我建议直接上Spring Boot风格的工程结构，或者用Maven管理依赖，避免手工拷贝jar包。
3.1 SSM整合与一个请求的生命周期
我用的是比较经典的SSM版本组合：Spring 5.2.x + SpringMVC 5.2.x + MyBatis 3.5.x，JDK 1.8，Tomcat 8.5，MySQL 5.7。工程结构上按controller / service / mapper / entity / vo 分包，resources目录下放Spring配置、MyBatis映射文件和mapper XML目录。
一个完整请求走的是这样的链路：前端页面发Ajax请求到Controller，Controller接收参数后调用Service接口，Service实现类里用@Transactional控制事务边界，调用Mapper接口写SQL，MyBatis映射XML里写具体SQL语句，结果集通过实体类返回，Controller把返回值包装成JSON（用的是Jackson或者Fastjson），前端拿到JSON之后渲染表格或表单。
我这边Controller返回格式统一是一个Result对象：code、message、data三个字段。code为200表示成功，500表示业务错误。这样前端Ajax判断逻辑就简单了，统一走success回调，失败时弹错误信息。这个小封装强烈推荐，能省掉不少重复的错误处理代码。
3.2 SQL与MyBatis映射文件的几个实用写法
MyBatis的XML映射是我花时间最多的部分。第一个实用场景是批量插入：候选人标签关联表CANDIDATE_TAG，新增候选人时可能同时有七八个标签，用foreach标签循环INSERT，一条SQL搞定，避免了N次数据库连接。
第二个实用场景是动态查询。职位搜索页面有多个筛选条件：城市、薪资范围、学历、经验年限、关键词。用 标签配合 动态拼SQL，完美避免写死SQL导致的匹配问题。关键词搜索用CONCAT('%', #{keyword}, '%')做模糊匹配，虽然效率不是最优，但数据量没到千万级别时完全够用。
第三个实用场景是一对多映射。查询推荐详情时要连带查出候选人的基本信息、职位信息、最近两条面试反馈，用resultMap做嵌套映射。MyBatis的association和collection是处理这种复杂查询的关键，配合懒加载配置可以避免一次性查太多无用数据。
3.3 最关键的推荐流程怎么落地
推荐流程的实现是系统的重头戏，状态流转代码写清楚是核心。我的RECOMMENDATION表里status字段存的是当前节点：0待推荐、1已推荐待面试、2面试中、3面试通过、4Offer已发、5已入职、6已过保、-1已淘汰。
Service层里我针对每个状态转换写一个专门方法，比如submitRecommend（创建推荐）、updateInterviewFeedback（更新面试反馈）、sendOffer、confirmOnboard。每个方法里除了更新状态之外，还要做三件事：校验前置状态（比如只有状态是1的推荐才能记录面试反馈）、写入INTERVIEW反馈表、更新职位表的最近推荐时间。这三件事放在同一个事务方法里，任何一步失败都会回滚，保证数据一致性。
在页面交互上，前端我会做时间线展示，把推荐节点的每次变更按时间轴排列。这个功能看着高端，实现其实就是查一下INTERVIEW表按时间排序返回列表，前端用时间轴组件渲染一下。
3.4 Flask在系统里具体承担哪块
Flask服务在这个项目里的角色有两个：文本匹配和统计报表。我给它划分了三个接口：
第一个接口POST /api/parse_resume接收简历文本，返回提取的技能标签列表。实现是Jieba分词加自定义词典（我维护了一个Java技术栈关键词表），分词后逐个匹配关键词表，命中就返回。这里有个小坑，Jieba默认分词会把“springboot”切成一个旅游词，必须往自定义词典里塞项目名和框架名。
第二个接口POST /api/recommend_candidates接收职位ID，返回匹配的候选人ID列表和匹配度分值。实现思路是从数据库读取候选人标签集合、读取职位标签，逐一计算Jaccard相似系数后排序，取Top20。这个接口不需要操作数据库表，因为它直接从主库读数据，Flask服务的DB连接配置和SSM共用同一个MySQL实例。
第三个接口GET /api/stats/recruit_pipeline接收时间区间，汇总每个状态节点的推荐数量。我用Pandas读数据之后做group by，返回前端直接渲染折线图或柱状图，对比Java里写SQL再循环组装数据要快很多。
有人会问，那SSM系统怎么调用Flask接口？我有两个办法：直接用RestTemplate（Spring自带）调用HTTP接口，或者用Feign风格封装一个HttpClient工具类。考虑到Flask服务和Java主服务大概率部署在同一台服务器，我直接用Java的HttpURLConnection封装了一个小工具类，几行代码搞定，不用引额外的HTTP客户端依赖。
接口调用失败时的降级处理我踩过坑，Flask服务挂了不能影响主系统的推荐列表加载，正确的做法是：Java端调用Flask超时设置3秒，超时或异常时返回空列表并记录日志，页面展示一个提示说“自动推荐暂时不可用，请手动筛选”。这是一个上线跑过之后才体会到的点。
4. 调试与部署：源码、文档、脚本三者怎么配合用
这种带源码、LW（论文）、调试文档和讲解视频的项目包，拿到手之后最重要的就是按顺序来，千万别一看源码就急着改。我按自己配置一个全新环境跑通这套系统的操作顺序来写。
4.1 从零到能开机的标准启动顺序
第一步先装基础环境，我这套是JDK 1.8、Maven 3.6、MySQL 5.7、Tomcat 8.5、Python 3.8以上、Redis（如果做了缓存的话）。版本号我建议严格匹配，JDK 11也能跑Spring 5，但某些日志依赖会有版本冲突，没必要给自己添堵。
第二步准备数据库，把项目doc目录下的init.sql脚本导进去，里面包含建库、建表、初始化数据。注意MySQL的字符集要设置成utf8mb4，千万不要用utf8mb3，不然会议纪要里的特殊字符存不进去。导入时如果遇到外键报错，先关闭外键检查：SET FOREIGN_KEY_CHECKS=0，导入完再打开。
第三步启动Flask服务。进入flask_app目录，用pip install -r requirements.txt安装依赖，然后python app.py启动，默认监听5000端口。先单独访问http://localhost:5000/stats/recruit_pipeline看能不能返回JSON，确认Flask没问题再连Java端。
第四步启动Java主服务。用Maven打包出war包放到Tomcat的webapps目录，或者直接在IDEA里配置Tomcat运行。启动成功的标志是Tomcat日志里出现Spring容器初始化完成的信息。然后用浏览器访问http://localhost:8080/，跳转到登录页就说明环境通了。
我见过很多朋友卡在第三步和第四步之间，Flask起来了但Java端连不上。这个问题几乎都是配置文件里的Flask服务地址写错了，很可能配的是localhost，但Tomcat和Flask部署在不同的环境变量或容器网络上。总之要确保Java端里flask.api.base-url配置是Flask实际监听的IP加端口。
4.2 部署时最容易踩的坑
第一个坑是JDBC驱动版本。MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver，MySQL 5.7的是com.mysql.jdbc.Driver；代码里写错了会直接ClassNotFound。还有8.0和5.7对时区的处理不一样，驱动连接串里必须加serverTimezone=Asia/Shanghai。
第二个坑是文件上传路径。简历附件上传时，Java端保存到本地磁盘的绝对路径，我遇到过Linux部署后找不到路径的问题。解决方案就一条：别写死绝对路径，在application.properties里用配置项指定upload.dir，上传接口创建目录时用File.mkdirs()，不存在就自动建。
第三个坑是Tomcat 8.5对JSP的依赖。如果你用SpringMVC的InternalResourceViewResolver做页面跳转，WebContent下有JSP页面，但Tomcat 8.5已经不再默认包含Jasper解析器，需要额外引一个tomcat-jasper.jar依赖。这个问题在配置新项目时绝对会遇到。
4.3 调试文档与讲解视频的正确使用姿势
调试文档我建议这样看：先看环境准备章节，核对版本号；再看数据库导入步骤，对照自己的MySQL版本；最后看常见异常排查表，把自己遇到的报错对号入座。不要上来就找功能代码在哪，那本调试文档的主要价值就是让你环境快速跑通。
讲解视频的价值在于理解设计思路，尤其是数据库E-R图讲解和核心功能流程演示这两段。看视频时重点听两个部分：一是推荐流程的状态流转为什么这样设计，二是Flask接口在业务中的定位。搞懂设计意图之后再改代码，才不容易把逻辑改崩。
关于论文（LW）部分，我建议如果你要交作业，优先把需求分析、ER图、系统设计这几章和实际代码对一遍，看图和表是否一致。论文里描述的功能点和实际编码实现的小细节可能会对不上，答辩老师一眼就能看出来。
5. 我这个项目里实际踩过的坑与解法
做这个系统前前后后跑了两周，遇到的坑不少，挑几个最值得记的写下来，如果你也在做类似的东西，大概率能帮你省下不少时间。
5.1 跨域与端口问题
Java端跑在8080端口，Flask跑在5000端口，前端页面在8080上，浏览器Ajax直接请求5000的接口必然会有跨域问题。我的解决办法是配置CORS，在Flask端用after_request钩子给所有响应加上Access-Control-Allow-Origin等头。用pip装flask-cors扩展也行，但手写钩子更直观，还能自定义异常处理。
另一个替代方案是Java端做反向代理，通过Controller转发请求的方式去访问Flask。这个方案能解决跨域，但增加了Java端的接口数量，我最后没采用，只是在代码注释里说明了两套方案的取舍，让维护者明白为什么选CORS。
5.2 标签匹配的精度问题
一开始用的是简单的全词包含匹配，后来发现简历里写“Spring Cloud”和职位需求里写“SC”根本对不上，匹配度虚高。我的改进办法是人工维护一个同义词表：核心名词和它的别名映射关系，匹配前先做同义词归一化，再计算相似度。
同义词表不用太复杂，我自己维护了大概一百条主流的Java技术栈术语，这个表放在Flask服务的一个py文件里，效果立刻好很多。如果你要做更精确的，可以试试把维基百科的词向量模型拉进来做语义相似度计算，但个人项目完全没必要，维护一个同义词表性价比最高。
5.3 事务边界放错了位置
推荐创建那个方法，我最初是所有代码都写在Controller里，状态更新、写反馈、刷新职位时间全在三行SQL里，没加事务。后来发现中途网络超时回滚不了，数据就脏了。重新按分层规范把逻辑收到Service层，加@Transactional注解，才算解决。
这个坑给我的教训是：任何跨多表写操作，必须放到Service层方法加事务；Controller里只做参数接收、调用、返回结果，绝不在Controller里直接写多条SQL。这个规范对新手特别重要，答辩的时候老师也爱问事务边界的问题，答上来就加分。
5.4 金额字段用错了类型
我最早把合同金额字段定成DOUBLE类型，结果算回款率的时候，0.1+0.2的经典精度问题直接暴露。后来统一改成DECIMAL(10, 2)，同时在Java实体类中对应字段声明为BigDecimal，所有计算用BigDecimal的add方法来做。这个坑在猎头、人力资源这类含财务数据的系统里非常典型。
5.5 简历附件存储的教训
最初我把简历PDF以二进制BLOB形式存进表里，后来发现一个是数据库体积涨得飞快，另一个是下载预览性能很差。后来改为文件存服务器磁盘，数据库只存文件路径。这个坑我记录在调试文档的“系统优化建议”里。
5.6 日志与排查经验
最后分享一个独门实用技巧：在SSM整合阶段，千万不要怕看日志。Spring启动时的控制台日志就是最好的排查工具。正常情况下会有Spring容器初始化成功的输出，如果中途报Bean创建异常，先看Caused by那一行，基本就能定位是哪种问题。还有MyBatis的Mapper映射如果报绑定异常，优先检查XML文件路径和namespace是否和接口全限定名完全一致，这两个点占了Mapper报错原因的九成。
Flask端排查相对简单，开启debug模式，app.run(debug=True)，报错信息会直接打在页面或控制台里。建议开发期就开着debug模式，上线之前再关掉。
我个人在实际操作里的体会是：这套Java+SSM+Flask的猎头公司管理系统，技术栈不复杂，难点全在业务逻辑的梳理。像推荐状态机、标签匹配、跨服务调用这些点，你花时间把它们想透，编码一天就能完成大半。如果有朋友要做类似的系统，我的建议是不要急着写代码，先把ER图、模块图、状态流转图画出来，多花半天做设计，后面写代码和调试的时间能省出一倍不止。最后再提醒一下，项目包里那些带调试文档和讲解视频的资源，环境跑通之后先别删，答辩或者改需求的时候回去翻一翻，比自己重新排查要快得多。
