auto_api

这是大公司招聘API直连爬取模块，与之前兴业银行的"Playwright拦截响应"方式不同，这里大部分公司是直接调用其招聘后台API接口获取数据。

整体结构

baidu_data_proc_api.py 里的 api_proc 是总入口路由，按公司编号分发：

三种不同的数据获取方式

各公司技术方案不同，对应三种截然不同的爬取策略：

① 直接POST接口（百度、软通动力）

直接构造 HTTP 请求调用招聘后台 API，拿到分页 JSON 数据。百度额外引入了代理池（getProxy），通过递归重试最多3次获取可用代理，用于绕过IP限制。软通动力则需要处理两套不同的 API 响应格式（社招返回 code/data/list，校招返回 results/count），在 get_isoftstone_job_json 里做了格式自动适配。

② 解析JS文件（金蝶）

金蝶的职位数据不是通过接口返回，而是直接写在一个静态 JS 文件里（jobs.js）。用正则从 JS 文本里提取 jobs = [...] 数组，再解析成 JSON。这是一种比较少见的数据发布方式，通常是静态站点为了避免 API 被滥用而采用的方案。

③ Playwright渲染详情页（软通动力）

列表数据通过API拿到后，详情页是动态渲染的 SPA，必须用 Playwright 打开浏览器等待 JS 执行完（wait_for_load_state("networkidle") + 额外等5秒）才能拿到完整内容。软通动力同时用了 ThreadPoolExecutor 避免与外层已有的事件循环冲突。

每个公司处理完数据后的统一落盘流程

无论哪种获取方式，最终都走同一套处理逻辑：

获取到职位列表 JSON
        │
        ├─ 已存在同名文件？
        │   └─ 只更新文件 mtime（标记"本次爬到了"），跳过
        │
        ├─ transform_job_json
        │   把各公司私有字段名 → 系统统一字段名
        │   写入 detail_xxx.json
        │
        ├─ 生成 / 获取 HTML 文件
        │   百度：requests 直接拉详情页 HTML
        │   软通：Playwright 渲染后保存
        │   金蝶：本地用 generate_html 拼一段完整 HTML
        │
        └─ detail_xxx.html + detail_xxx.json 落盘
               │
               └─ 进入后续 ann_md → ann_model 解析流水线

几个值得注意的设计细节

文件名用 URL 的 MD5 哈希：hashlib.md5(_fullurl.encode()).hexdigest() 作为文件名，保证同一个 URL 永远映射到同一个文件，天然实现去重。

更新 mtime 而不是跳过：已爬取的文件不重新下载，但会调用 os.utime 更新修改时间。这样系统可以通过文件修改时间判断"这条数据在本次爬取中是否仍然有效"，过期的文件会被下游清理任务识别并删除。

金蝶的 generate_html 设计思路与兴业银行一致：API 返回的是干净 JSON，但为了复用后续解析流水线，故意把它重新渲染成一段格式化 HTML 再落盘。

翻页策略有两档：默认爬5页（快速模式），配置 method=cp_full 时爬全量（最多100页）。百度爬取间隔30秒，软通1秒，体现了对不同网站反爬强度的针对性处理。

项目分区导航：xingye_proc ⬅️ | 00-auto_api | ➡️ baidu_data_proc_api