SpringBoot+Hadoop+AI大模型兼职聚合推荐平台设计与实现

这是一类非常典型的“大而全”毕业设计/项目实战题：基于SpringBoot+大数据爬虫Hadoop+智能AI大模型的兼职聚合与个性化推荐平台。我前前后后带人搭过几版类似的东西，看到标题里的“精品源码+精品论文+上万数据集+答辩PPT”，基本能猜到你想要的是一个既能过答辩、又能真正跑起来的完整闭环。这篇文章就把这个项目从零到一的设计思路、技术选型、核心实现、常见坑全捋一遍，同时也会说清楚哪些地方是“看起来高级”但没必要死磕的，哪些是必须扎扎实实做好的。适合准备做毕设、或者想拿这套技术栈练手做实战项目的同学参考。

1. 项目定位与总体架构拆解

1.1 这个项目到底在解决什么问题

市面上的兼职信息散落在一堆不同的App、网站、公众号里，学生想找个周末兼职、远程兼职、短期实习，往往要来回切换好几个平台，而且很难判断一条兼职信息靠不靠谱，薪资是否合理，跟自己的专业、技能、可工作时间匹不匹配。所以这个项目的核心价值就两个：聚合和推荐。

• 聚合：通过网络爬虫把多个公开渠道的兼职信息抓到本地，经过清洗、去重、结构化，统一存起来，做一个可供检索的兼职信息库。
• 推荐：基于用户的基本信息（技能、城市、可兼职时间、期望薪资）和历史行为（浏览、收藏、投递），利用协同过滤、内容匹配，甚至引入大模型做语义层面的理解，把“可能合适的兼职”推给用户。

从毕设/项目评审的角度看，这个题目比单纯的CRUD管理系统值钱得多。它不是简单堆功能，而是把一条完整的数据链路打通了：采集->存储->清洗->服务->推荐。评委会特别关注各层之间的衔接，而不是单点功能。

1.2 整体架构：五层模型

我帮人搭这类项目，习惯把架构分成五层，既能应付讲解，又方便代码拆分：

1. 采集层：爬虫模块，负责抓取公开兼职数据。这里的技术栈可以是Java HttpClient+Jsoup，也可以是Python requests+lxml，项目里不建议完全脱离开来，通常是一个独立模块，产出的数据落到临时目录或消息队列。
2. 存储层：Hadoop HDFS做分布式文件存储，主要存放原始抓取数据和处理后的中间结果；关系型数据库如MySQL负责存用户、职位、行为等在线业务数据;（如果数据量真的大，还可以引入Elasticsearch做搜索，但这属于加分项，不是必备项）。
3. 计算层：Hive或MapReduce做离线清洗与统计，比如去重、字段补全、兼职分类的标签提取。这一层体现的是“大数据处理”的核心。
4. 服务层：SpringBoot提供RESTful API，处理前端请求、用户认证、职位查询、收藏投递、推荐结果返回。
5. 智能推荐层：既可以作为SpringBoot内的一个服务，也可以独立成Python微服务。包含用户画像、职位画像、离线召回、在线排序，以及可选的AI大模型接口，用于生成个性化推荐理由、做语义匹配。

下面是我常用的一种简化部署形态：

[爬虫模块] -> (原始数据) -> [HDFS] | [Hive清洗] | [MySQL/Redis] | [前端/Vue] <-> [SpringBoot API] <-> [推荐服务/Python] | [MySQL业务库]

很多同学一上来就被“分布式爬虫”“Hadoop集群”“AI大模型”这些词吓住了。实际上，毕设环境完全可以用伪分布式Hadoop，推荐服务也可以用轻量模型+在线API的方式实现，关键是每层之间的数据流要说清楚。

1.3 技术选型背后的核心原因

《基于SpringBoot+大数据爬虫Hadoop+智能AI大模型的兼职聚合与个性化推荐平台》这个题目的技术选型是有讲究的：

• SpringBoot：当前Java后端的事实标准，起步快、生态成熟，用来做API层和业务层是最稳的。Controller、Service、Mapper三层结构在论文里也好画图，答辩也好讲。
• Hadoop：对应“大数据”这个关键词。实际上海量兼职数据的处理量级可能达不到真正用上集群的程度，但你有了Hadoop这套数据采集+离线计算的链路，项目的高度就不一样了。尤其“上万数据集”这个条件，正好卡在能用数据库处理但用Hadoop处理也让合理的区间，属于讨巧的设定。
• 爬虫：数据从哪里来，这是整个系统的血液。没有真实数据，推荐算法再牛也是空中楼阁。
• AI大模型：这是最近两年最热的加分项。它不需要你去训练一个大模型，更多的是用大模型做三件事：抽取兼职文本标签、理解用户自然语言画像、生成解释性推荐文案。说白了，是站在大模型的肩膀上做一些轻量应用。

2. 数据采集层：爬虫设计与合规采集

2.1 爬虫模块的定位与职责

兼职聚合平台的数据源头一般有：主流招聘网站、本地生活服务网站、校园论坛兼职版块、企业官方发布的兼职招聘信息。需要注意，爬虫不是乱爬，要遵守目标网站的robots协议，也要控制抓取频率，不要给目标站点带来压力。这是职业素养问题，也是保护自己的方式。

在设计爬虫模块时，要先划分清楚数据流向：

种子URL -> 列表页解析 -> 获取详情页URL列表 -> 详情页内容抓取 -> 字段解析 -> 清洗 -> 输出

如果只抓几个渠道，用单线程循环也够；为了体现“分布式爬虫”的亮点，可以用一个生产者-消费者模型：一个模块负责从列表页提取详情链接，多个Worker线程从任务队列取链接并发抓取详情页。在Hadoop集群加持下，还可以把待抓取URL列表放到HDFS上，由多个节点分担抓取任务——不过毕设里这样做的意义不大，写论文的时候提一句“可扩展设计”就行。

2.2 技术栈选择：Java还是Python

项目既然主打SpringBoot，爬虫模块用Java写会显得技术栈统一，但Python在页面解析和文本处理上确实更顺手。我的建议是：主爬虫用Java写，放到SpringBoot工程里作为一个独立模块；如果需要一些特殊的JS渲染页面，再额外用Python脚本辅助。

Java爬虫常用组合：

• HttpClient + Jsoup：适合静态页面。
• Selenium + WebDriver：适合需要模拟点击、翻页、等待异步加载的页面。注意Selenium非常吃资源，不要在服务器上开一堆浏览器实例，控制好并发数。
• Hutool的HttpUtil：做简单抓取很方便，但不适合重试逻辑复杂的场景。

Python辅助爬虫常用组合：

• requests + lxml + XPath
• scrapy：如果用到了scrapy，可以考虑“分布式爬虫”这个关键词，配合scrapy-redis实现多节点抓取。但在毕设里引入scrapy会分散精力，建议谨慎。

举个例子，用Java抓取一个列表页，解析职位名称和链接：

String url = "https://example.com/jobs/list?page=1"; HttpClient client = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .followRedirects(HttpClient.Redirect.NORMAL) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(url)) .header("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64)") .header("Accept", "text/html,application/xhtml+xml") .build(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString()); Document doc = Jsoup.parse(response.body()); Elements items = doc.select("div.job-list-item a.job-title"); for (Element item : items) { String title = item.text(); String link = item.absUrl("href"); // 存入待抓取队列 }

2.3 数据字段设计与清洗

爬到的数据结构化做得越早，后面Hive清洗和推荐建模就越省事。兼职信息至少要有以下字段：

洗数据的规则也很直接：

• 去重：先按URL去重，再按“标题+公司+城市”做模糊去重，防止同一条兼职在不同渠道重复抓。
• 薪资解析：爬到的可能是“200-300/天”，需要拆成salary_min、salary_max、salary_unit。
• 城市归一化：比如“北京市”“北京”“朝阳区（北京）”统一成北京。
• 标签抽取：从title和description里用正则或关键词表打标，比如“家教”“辅导”“助教”归类到家教类。

2.4 合规采集的几个注意事项

这个必须多说几句。爬虫无法完全避免被反爬，但不能因此去搞破解验证码、绕过登录这类手段。规范的做法是：

1. 控制频率。同一域名下请求间隔至少1到3秒，并发数不要超过5。
2. 设置合理的User-Agent，并标记爬虫身份，方便站点管理员联系。
3. 只抓公开信息，不碰用户隐私数据、不碰非公开接口。
4. 如果目标有明显的“禁止爬取”声明，就换一个数据源。

反爬应对方面，可以做的常规操作包括：随机请求头、使用Cookie池、支持断点续抓（用Redis或MySQL记录已抓URL）、动态调整抓取间隔。

3. Hadoop数据存储与离线处理

3.1 HDFS目录规划和文件格式

搞大数据项目，第一件事不是急着写代码，而是把HDFS上的目录结构规划好。我用下面这套，简单清晰：

/user/hadoop/兼职数据/ ├── raw/ 原始抓取数据 │ ├── 20250101/ │ ├── 20250102/ ├── clean/ 清洗后数据 ├── dwd/ 明细数据 └── ads/ 统计和应用层数据

raw下存的原始抓取结果，建议直接用JSON格式一行一条，方便后续Hive解析。clean下是清洗后的结构化字段，推荐用Parquet或ORC格式，压缩率高、读取快。如果没有特殊强迫症，CSV也不是不能用，但真要体现大数据感觉，还是得落到列式存储。

3.2 Hive建表和离线清洗

Hive是Hadoop生态里最好用的OLAP工具，写SQL就能做数据清洗，上手成本低。比如在Hive里建一张兼职明细表：

CREATE EXTERNAL TABLE dwd_job_info ( job_id STRING, title STRING, company STRING, salary_min DOUBLE, salary_max DOUBLE, salary_unit STRING, city STRING, district STRING, job_type STRING, schedule STRING, description STRING, source STRING, publish_time STRING, crawl_time STRING ) PARTITIONED BY (dt STRING) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde' STORED AS TEXTFILE LOCATION '/user/hadoop/兼职数据/dwd';

然后通过一条INSERT OVERWRITE把清洗逻辑跑出来：

INSERT OVERWRITE TABLE dwd_job_info PARTITION(dt='2025-06-01') SELECT job_id, trim(title) AS title, trim(company) AS company, salary_min, salary_max, salary_unit, city, district, CASE WHEN title LIKE '%家教%' OR title LIKE '%辅导%' THEN '家教' WHEN title LIKE '%促销%' OR title LIKE '%导购%' THEN '销售促销' ELSE '其他' END AS job_type, schedule, description, source, publish_time, crawl_time FROM clean_job_info_temp WHERE title IS NOT NULL AND title != '';

这里体现的是“清洗+转换”的过程。答辩的时候一定要把这条SQL讲清楚，因为这就是Hadoop在实际项目中发挥的作用——离线批处理。

3.3 从Hadoop到业务库：怎么服务线上系统

Hive处理完的数据最终要在SpringBoot接口里被查询，你不能让线上接口直接去查Hive，延迟太高。常规做法是：

1. 离线计算结果同步到MySQL。用Sqoop同步，或者写一个DataX任务，把ads层数据导入MySQL。
2. 如果数据量真的很大，MySQL扛不住，可以引入Elasticsearch做搜索。但大部分毕设/sprint项目里，MySQL加索引就够用了。
3. 推荐离线结果同理：离线算好每个用户的TopN Job，写入Redis或MySQL的recommend表，在线接口直接读。

3.4 Hadoop部署：伪分布式就够吗

《Hadoop伪分布式搭建》《Hadoop和Zookeeper整合实战》这些都是热搜关键词。常用于配置：

• 如果你是课设/毕设，一台内存16G以上的电脑就足够了。伪分布式不需要Zookeeper，配置core-site.xml、hdfs-site.xml、yarn-site.xml，一个NameNode一个DataNode就能跑。
• 如果你要坚持集群模式，三台虚拟机即可，但每台至少4G内存，不然跑MapReduce会频繁OOM。
• 搭建的时候永远先确认$JAVA_HOME，hadoop-env.sh里不写JAVA_HOME会导致各种诡异问题。
• 启动完先执行jps看进程，NameNode、DataNode、ResourceManager、NodeManager都在，才叫启动成功。

一个实际经验：Hadoop 3.3以上版本跟Java 8/11/17的兼容性都还行，但Java 17会把一些反射警告刷屏，不影响使用。真实项目中建议用Java 8或11，稳定，网上资料也最多。

4. SpringBoot后端服务设计

4.1 工程目录与分层

SpringBoot服务是整个平台的中枢。既要给前端Vue提供接口，也要对内调度推荐服务。我建议按下面的模块划分：

job-platform/ ├── job-common/ 公共模块：统一返回结果、异常处理、工具类 ├── job-admin/ 后台管理模块 ├── job-api/ 面向C端用户的接口模块 ├── job-crawler/ 爬虫模块 ├── job-recommend/ 推荐服务模块 ├── job-datasource/ 数据库、Redis、消息队列配置 └── job-quartz/ 定时任务模块

简化版本也可以是一个单体Module，但至少Controller、Service、Mapper、Entity、DTO这些包要分开。这直接关系到论文里UML图的画法，也关系到代码分。分层清晰比多写几个功能重要得多。

4.2 核心表和接口设计

用户表：user(id, username, password, city, education, skills, available_time, expected_salary, tags) 职位表：job_info(id, job_id, title, company, salary_min, salary_max, city, job_type, schedule, description, publish_time, status) 行为表：user_behavior(id, user_id, job_id, behavior_type(view/favorite/apply), create_time) 推荐结果表：recommend_result(id, user_id, job_id, score, reason, create_time)

后端接口按这个清单来：

4.3 SpringBoot整合关键点

1. MyBatis-Plus + 动态数据源

如果离线数据从Hadoop同步到MySQL，业务表在MySQL；如果用了Redis做缓存，就需要配置多数据源。MyBatis-Plus的@DS注解可以切换数据源，推荐用。

2. Redis做热门兼职缓存

兼职数据访问热度差异大，热门前十的职位可能被反复查。用Redis缓存列表数据，可以明显降低数据库压力。

@Cacheable(cacheNames = "hotJobs", key = "#page + ':' + #size") public PageResult<JobVO> getHotJobs(int page, int size) { // 查询热门前职位 }

3. 消息队列提高采集异步性

用SpringBoot集成ActiveMQ或RabbitMQ，把爬虫抓到的数据先发到MQ，再由消费者异步写入HDFS或者MySQL。这样既解耦，又能体现工程设计的深度。如果不想引入队列，至少要用线程池异步处理，别让抓取逻辑阻塞接口调用。

4.4 API防爬防护与业务安全

题目热词里面反复出现“controller层如何防护防止爬虫”“前端防爬虫”。这说明大家都意识到，平台上线后，接口会被别人恶意爬取。防止他人爬我们的接口，手段一般是：

• 用户网关限流：用Spring AOP或拦截器，对单个IP、单个Token限制访问频率，比如1秒最多10次请求。超过就返回“请求过于频繁”。
• JWT认证：非公开接口必须带token，解析失败直接401。
• 参数签名：针对重点接口，前端传参时带sign = MD5(params + salt)，后端验签。用来防止参数被篡改和数据被恶意遍历。
• 验证码：登录、注册、批量查询接口加图形验证码或滑块验证。
• 敏感数据脱敏：手机号、邮箱等字段返回时打码。
• 防SQL注入：使用参数绑定，不要拼字符串。
• 防XSS：前端提交内容做HTML转义，后端的过滤器也可以统一处理。

给你一段拦截器的思路：

@Component public class RateLimitInterceptor implements HandlerInterceptor { @Autowired private StringRedisTemplate redisTemplate; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String ip = request.getRemoteAddr(); String key = "rate:limit:" + ip; Long count = redisTemplate.opsForValue().increment(key); if (count != null && count == 1) { redisTemplate.expire(key, Duration.ofSeconds(10)); } if (count != null && count > 20) { response.setStatus(429); response.getWriter().write("请求过于频繁，请稍后再试"); return false; } return true; } }

这套东西不是毕设核心加分项，但写进论文“系统安全设计”一章，比空泛地写“保证了系统安全”要硬很多。

5. 智能推荐与AI大模型落地

5.1 推荐系统的整体链路

推荐系统不是只有“协同过滤”这一种算法。在这个项目里，推荐链路需要设计成下面三层，缺一不可：

1. 召回层：从几万个职位里快速找出200个候选职位。冷启动时按城市、求职类型、薪资范围召回；有历史行为后，用基于物品的协同过滤，或者简单规则（相似用户投递过的职位）召回。
2. 排序层：对200个候选职位打分排序。排序可以分成两个阶段：先基于特征规则打分（城市匹配、薪资匹配、时间匹配、技能匹配），再混合模型排序。如果数据量不大，直接用规则+加权评分会有非常好的效果，也容易讲清楚。
3. 展示层：返回推荐的职位和推荐理由。推荐理由用大模型生成，这是项目里最有亮点的地方。

5.2 怎么用AI大模型做个性化推荐

“AI大模型”在就业平台里不是让你自己从零训练一个Transformer，而是做下面这几件事：

第一，结构化用户画像生成。

用户在注册时可能会填“我是英语专业学生，周末有空，想找跟英语相关的兼职”。这段描述是半结构化的，借助大模型可以抽取成标签：

输入：我是英语专业大二学生，周末和暑假有空，希望找线上或线下的英语助教工作，薪资要求不高。 输出（JSON）： { "major": "英语", "tags": ["英语助教", "线上兼职", "线下兼职", "教育"], "available_time": ["周末", "暑假"], "salary_expectation": "中等" }

第二，职位语义标签扩展。

爬虫抓到的职位标题可能很简短，比如“辅导机构招周末助教”。直接用关键词匹配，用户搜“英语助教”可能搜不到。用大模型对职位文本做语义理解，生成扩展标签：

• 原始标题：辅导机构招周末助教
• 扩展标签：英语助教、作业辅导、周末兼职、教育机构、学生兼职

这样推荐召回阶段就不容易漏掉候选。

第三，生成个性化推荐理由。

这也是最能打动评审的点。当用户看到推荐结果时，不再只有一个生硬的职位标题，而是一句解释：“这与你之前浏览的‘周末英语助教’相似，且薪酬在同类兼职中偏上，符合你的周末时间安排在朝阳区。”大模型可以通过职位信息、用户画像、推荐匹配点来生成这段话。

5.3 推荐服务具体怎么落地

推荐服务不一定要用重框架。我建议拆成一个独立的Python推荐微服务，SpringBoot通过HTTP接口调用它。

Python侧可以用FastAPI封装两个接口：

• POST /recall：传入userId，返回候选职位ID列表。
• POST /rank：传入userId和候选职位列表，按照相关性打分，返回TopN。
• POST /explain：传入userId和推荐职位ID，调用大模型生成解释文案。

Python里可以简单实现一个基于内容的召回：

def compute_score(user_profile, job_item): score = 0.0 if user_profile['city'] == job_item['city']: score += 0.3 if user_profile['job_type'] == job_item['job_type']: score += 0.3 if user_profile['salary_min'] <= job_item['salary_max']: score += 0.2 if any(tag in job_item['tags'] for tag in user_profile['tags']): score += 0.2 return score

当然这只是演示逻辑，真实项目里这个分数要经过归一化和模型融合。但毕设展示阶段，能把这条链路讲通比堆一堆“深度学习模型”更有说服力。

5.4 离线推荐与在线推荐

推荐结果不需要每次请求都现算，否则延迟高到没法用。项目里可以分两条线：

• 离线计算：每天凌晨用Spark或Python脚本跑一次全量用户推荐TopN，结果存入MySQL/Redis的推荐表。用户打开App直接读缓存。
• 在线兜底：如果用户是新用户或离线结果为空，走规则召回，实时算一个粗推荐出来。

这个双轨设计在论文里非常好写：离线部分体现“大数据处理”，在线部分体现“系统可用性”。

5.5 大模型API调用注意点

调用外部大模型API时，不要在前端直接暴露密钥，也不要让SpringBoot直接去调用。常规做法是做一个加密密钥中转层，所有大模型请求都走服务端，并且设置超时时间，避免第三方接口慢导致推荐接口超时。推荐服务里对模型调用要有降级方案：模型挂了就返回规则生成的推荐理由，比如“城市和求职类型匹配”。

6. 数据集、论文结构与答辩准备

6.1 “上万数据集”怎么构建才靠谱

很多同学问：上万条兼职数据从哪来？总不能真的抓一万条吧。其实有两种合规的方式：

1. 爬虫采集真实数据：多抓几个渠道，每个渠道抓几百到一千条，凑出3000到5000条基本数据，再通过数据增强（字段组合、薪资微调、城市分布调整）扩充到一万条以上。注意，这些数据仅用于学习演示，不用于商业用途。
2. 公开数据集+自造数据：网上有一些招聘公开数据集，可以下载做底子，再混合爬虫数据补充。

我在实际项目里，还会额外生成一批“模拟行为数据”：给用户分配标签，模拟浏览、收藏、投递行为，用于推荐算法的效果演示。否则系统上线当天没数据可推。模拟生成的时候要有倾向性，比如英语专业的学生更容易浏览家教类兼职，这样推荐结果看起来才合理。

6.2 精品源码的工程化要求

源码这东西，不是能跑就行。我整理了一份送给师弟们的最低标准：

• README要写清楚：JDK版本、Maven版本、Hadoop版本、MySQL版本、初始化脚本、启动顺序。
• 必须提供database/init.sql和样例数据导入脚本。
• 第三方依赖版本集中管理，用Maven的properties标签统一版本号。
• 配置项外置到application.yml，敏感信息至少要有占位符。
• 日志要分级。不能用System.out.println打点，至少用lombok的@Slf4j。
• 接口返回格式统一。推荐写一个Result<T>对象，code/message/data。

6.3 精品论文怎么组织

论文结构不用太标新立异，按标准硕士/本科论文套路来就行，但技术细节要写扎实：

1. 绪论：背景、国内外研究现状、研究内容、论文结构。
2. 需求分析：功能性需求、非功能性需求、用例图。
3. 相关技术介绍：SpringBoot、Hadoop、爬虫、推荐算法、大模型API。
4. 系统设计：总体架构设计、数据库设计、功能模块设计、推荐算法设计。
5. 系统实现：每个模块的核心代码讲解、核心界面截图。
6. 系统测试：功能测试用例表、性能测试数据。

答辩时最容易翻车的点就是“相关技术介绍抄了一大堆，但是跟后面的设计实现完全脱节”。写论文前先定好架构图，所有技术介绍都是为了解释你的架构服务。

6.4 答辩PPT与演示要点

答辩PPT一般15到20页，重点讲这几页：

• 系统架构图：一页讲清楚数据流。
• 爬虫模块截图：展示抓取的原始数据和清洗结果。
• Hadoop离线处理：展示Hive建表语句和清洗前后的数据对比。
• 推荐流程：展示推荐接口的返回JSON，里面要有推荐理由生成的部分。
• 测试结果：负载测试或压力测试数据，哪怕只是用JMeter简单跑一下，也比空口说系统稳定强。

还有一个非常实用的答辩经验：提前准备一个40秒的demo走场。从注册账号、补全画像、浏览职位、上报行为、刷新推荐，一条线走完。很多同学一紧张就随便点，点到哪个算哪个，结果把自己绕进去了。演示要准备两套：一套数据完整的主演示，一套数据缺失的空状态演示。

7. 常见问题与排查技巧实录

7.1 Hadoop篇：启动失败、内存不足、跑任务卡死

问题1：NameNode is not started/ 反复格式化

格式化HDFS前，先把NameNode进程停掉，然后清空dfs.namenode.name.dir配置的目录，再执行hdfs namenode -format，否则会有集群ID不一致的问题。

问题2：DataNode起不来，报磁盘空间不足

HDFS默认会保留一定空间，如果磁盘剩余不足，DataNode会自动退出。检查dfs.datanode.du.reserved参数，并确认/data/hadoop目录有足够空间。

问题3：跑Hive任务时内存溢出

Hive跑MR任务时，Map和Reduce的堆内存需要撑住。可以配置：

<property> <name>mapreduce.map.java.opts</name> <value>-Xmx1024m</value> </property>

如果机器内存只有16G，不要同时启动太多服务。Hadoop + Hive + MySQL + Redis + SpringBoot + 前端，占用大概12G左右，建议给虚拟机分配8G以上，或减少不必要的组件。

7.2 爬虫篇：抓不到数据、被限制、解析失败

问题1：页面是异步加载的，HttpClient抓的HTML里没数据

这种情况要用Selenium或Playwright渲染后再解析。优点是省事，缺点是慢。我习惯用Scrapy/Selenium混合模式：列表页用浏览器渲染，详情页如果静态就直接HttpClient抓。注意Selenium的WebDriver版本要和浏览器版本匹配，不然报SessionNotCreatedException。

问题2：请求过一段时间就被封IP

不要一味增加代理成本。先检查是不是请求头太规律、频率太高。最稳妥的方案是：限速+随机延迟，User-Agent尽量用真实的浏览器版本，或者直接用固定的浏览器UA而不是随机生成。

问题3：XPath写的没问题，但取不到值

大概率是HTML里面包含了命名空间，或者内容在iframe里。先右键检查确认元素位置，如果确实在iframe里，Selenium里要用driver.switchTo().frame()切进去。

7.3 SpringBoot篇：版本兼容、jar冲突、启动慢

问题1：SpringBoot版本太高，跟某些插件不兼容

这是一个非常常见的问题。比如SpringBoot 3.x要求JDK 17，老一些的MyBatis或者数据库驱动就不适配。最稳妥的组合是：JDK 8 + SpringBoot 2.7.x + MyBatis-Plus 3.5.x + Hadoop 3.3.x。不要一上来就追最新版，毕业设计求稳不求新。

问题2：Maven依赖冲突，启动报NoClassDefFoundError

优先用mvn dependency:tree查看依赖树，找到冲突的jar，然后在pom.xml里用<exclusions>排除。比如Hadoop的ZooKeeper版本跟项目里其他依赖冲突时，排除掉Hadoop传递的旧版本即可。

问题3：SpringBoot整合Flink或者整合Hadoop时启动变慢

Hadoop相关的依赖往往带了一堆传递依赖，启动时可能触发不必要的自动配置。解决方式是在@SpringBootApplication注解里排除自动配置类，或者在配置文件里关闭相关自动配置。

@SpringBootApplication(exclude = { org.apache.hadoop.security.UserGroupInformation.class // 不直接排除，仅示意 })

更合理的做法：不要让SpringBoot直接依赖Hadoop客户端，在SpringBoot里只通过Hive/Impala JDBC去查数，把Hadoop和业务服务解耦。

7.4 推荐与大模型篇：延迟高、效果差

问题1：推荐接口响应时间超过3秒

大概率是每次请求都实时算了推荐。解决方案是改成离线结果+定时任务，或者至少加一层Redis缓存。如果线上确实需要实时召回，对候选集加一层布隆过滤器或者减少候选数量。

问题2：大模型生成推荐理由太慢

大模型的在线调用一般在1到3秒，如果放在排序链路里会拖垮接口。推荐理由是异步加载的：主接口先返回职位列表，前端拿到职位后用空位展示，再通过/api/explain异步拉取推荐理由，或者干脆在离线阶段先生成好TopN题的推荐理由，存库直接取。

问题3：推荐结果一看就不合理，比如给北京用户推荐了上海的岗位

这是推荐特征没做好。位置、时间、技能、期望薪资四个硬条件至少要作为硬条件过滤，而不是作为可以权衡的软特征。硬过滤不过的职位不进入后续排序，否则推荐效果会明显偏离。

7.5 项目联调中的其他坑

• 端口冲突：Hadoop相关端口很多，NameNode 9870、DataNode 9864、ResourceManager 8088，SpringBoot是8080，MySQL是3306，Redis是6379。联调之前先列一张端口表，谁占用了谁好查。
• CORS跨域：前端Vue在5173端口，后端在8080端口，不配置CORS就会报跨域。SpringBoot里写一个WebMvcConfigurer统一处理。
• 数据时区问题：爬到的发布时间可能是带时区的字符串，入MySQL时统一转成LocalDateTime，存UTC，返回给前端时转成北京时间。

8. 最后分享一点实际做的体会

我在实际辅导这类项目时，最常跟人说的一句话是：不要在技术选型上搞“四不像”，要把每层技术用到“恰到好处”。这个题目真正的难度不在某一个单独的模块多深，而在把SpringBoot、Hadoop、爬虫、AI大模型、个性化推荐这五样东西串成一个完整闭环。你能把数据从采集到展示这一条链路讲清楚，把你处理过的数据样例展示出来，把推荐结果的前后变化说清楚，这比写出一个性能极高的算法更有价值。

另外一个建议是，答辩前把全套环境重启一遍，从头到尾走一遍流程。很多人平时开发是慢慢调试出来的，数据库里字段值被改乱了、缓存没清、爬虫任务没跑，一到演示就露馅。把系统做成“我昨天刚部署完，现在马上能跑”的状态，是很多答辩高分的真正秘密。

如果你是准备自己动手做这个平台，按照我上面说的顺序来推进：先搭Hadoop单机版，再抓数据、洗数据，然后同步到MySQL，接着写SpringBoot接口，最后做推荐和大模型封装。每完成一步都可以看到东西跑起来，不容易中途放弃。祝顺利。