链路追踪

定时任务

image-e83adfd1 
@echo off

echo 正在启动中...

call E:\chu\python310_ve\Scripts\activate.bat

cd /d E:\chu\qzclawler

git pull

python main.py -m cp -f 51

1. 任务启动指令拆解

命令：python main.py -m cp -f 51

  • python main.py: 启动主程序。
  • -m cp: 参数 m 通常代表 mode（模式）。cp 极大概率对应 "Company"，即“公司官网抓取模式”。
  • -f 51: 参数 f 代表 file。它直接指令程序去读取 setting_com_51.ini 这个配置文件。

2. 链路追踪：本次任务在做什么？

当这个任务运行时，程序会根据 setting_com_51.ini 里的配置，依次对以下企业进行“地毯式”扫描：

  1. 松山湖材料实验室 (com_00075)
    • 目标：扫描校招、社招和海外招聘链接。
    • 手段：使用 template_01005 规则，并运行 gen_00005_3 自定义函数。
  2. 四三九九网络 (4399) (com_00498)
    • 目标：抓取其官网的社招和校招岗位。
    • 关键点：使用了 template_50150。注意其 json_domain 指向了微信端接口 (wx-hr.img4399.com)，这意味着爬虫是在模拟手机端请求以获取更干净的 JSON 数据。
  3. 科捷智能 (com_00499)
    • 平台：该公司使用的是飞书招聘 (ATS)。程序会针对飞书的页面结构进行解析。

3. 完整的自动化流水线

这个定时任务配合之前上传的 API 模块，形成了一个完整的闭环：

  1. 代码同步 (git pull)：确保脚本和 .ini 配置文件是最新的（比如你在另一台机器修改了 51 号文件里的 URL，这里会自动生效）。
  2. 环境激活 (activate.bat)：进入隔离的 Python 3.10 环境，确保 PaddleOCR、requests 等依赖库版本正确。
  3. 读取配置 (-f 51)：加载 4399、松山湖等公司的抓取规则。
  4. 网页抓取：程序访问配置文件中的 urls。
  5. 数据清洗与比对：
    • 调用 quanzhi_api.py 里的 check_cloud 接口。
    • 逻辑：如果该职位在服务器上已经有了，就跳过；如果是新出的（如 2025 春招新岗位），则继续。
  6. 结构化处理：
    • 如果是文本，直接处理。
    • 如果遇到招聘海报（图片），调用 ocr_api.py 识别文字。
    • 调用 openai4o_api.py 或 doubao_api.py 将乱七八糟的描述转化为标准的 JSON 字段（薪资、地点、要求）。
  7. 入库 (ann_add)：最后通过 quanzhi_api.py 将结构化好的数据 POST 到正式环境服务器 (121.36.63.42)。

4. 关键观察点

  • 并发性：从提供的 image_437de9.png 来看，文件夹里从 01 到 51 有几十个配置文件。这说明你的系统采用了分片处理。
  • 任务分工：
    • -f 01 可能负责腾讯、阿里等大厂。
    • -f 51 则负责像 4399、松山湖实验室这些特定领域的企业。
    • 这种设计允许你开启多个定时任务并行工作，互不干扰。

1. 启动入口：main.py

当你运行 python main.py -m cp -f 51 时，程序从 main.py 的 if __name__ == "__main__": 块开始执行。

  • 参数解析：使用 argparse 模块接收参数。
    • -m cp：指定运行模式。根据 main.py 逻辑，cp 模式会进入公司数据抓取流程。
    • -f 51：指定配置文件后缀。程序会拼接成 setting_com_51.ini。
  • 实例化：程序会同时创建三个核心类的实例：
    • s = SpiderSch(args.file) (学校爬虫)
    • cs = SpiderCom(args.file) (公司爬虫)
    • d = SpiderData(s) (数据处理)

2. 配置读取：从 setting_com_51.ini 到内存

配置是在 SpiderCom 类初始化或运行初期读取的。

  • 读取位置：在 spider_com.py 中，通常会在构造函数 __init__ 或 run 方法里使用 configparser 加载 setting_com_51.ini。
  • 去向：配置信息会被解析成一个字典或对象。例如，日志中看到的 com_00220（OPPO）的 URL、模板 ID（template_...）、函数名（gen_...）等，都是从这个 .ini 文件中提取的。

3. 核心执行链路（Data Flow Link）

根据 Traceback 日志，链路如下：

  1. main.py -> run_periodically / clawler_main： 这是调度层。它根据 -m cp 参数决定调用 cs.run()（即 SpiderCom 的主逻辑）。
  2. spider_com.py -> run()： 遍历 .ini 文件中定义的所有公司编号（如 com_00220, com_00221...）。
  3. spider_com.py -> get_page_data()：
    • 使用 Playwright 打开公司招聘的列表页（如 OPPO 的职位搜索页）。
    • 根据模板找到所有的职位链接（link）。
  4. spider_com.py -> get_page_detail_data()： 针对列表页抓取到的每一个职位，循环调用详情页抓取逻辑。
  5. spider_com.py -> get_page_detail_content()：
    • 深度抓取：打开具体的职位介绍页面。
    • 提取内容：抓取 JD（职位描述）、要求、地点等。
    • 报错点：你看到的报错就在这一层，尤其是详情页加载后的等待（time.sleep）阶段。

4. 数据落地链路

  • 本地临时存储：抓取到的原始 JSON 数据会存放在 E:\chu\clawler_data/data/tmp/公司编号/ 下。
  • 云端上报：在 spider_data.py 或通过 api/quanzhi_api.py，程序会将解析后的结构化数据通过 requests.post 发送到华为云服务器（121.36.63.42）。

总结流程图

  1. 输入：命令行参数 -f 51
  2. 加载：读取 ./setting_com_51.ini 里的公司列表和规则
  3. 循环：
    • 打开列表页 -> 获取多个详情页URL
    • 逐个打开详情页 -> 提取 JD文本
  4. 处理：调用 SpiderData 进行清洗或 OCR
  5. 输出：写入本地 JSON，并调用 quanzhi_api.py 上传到正式环境数据库

项目分区导航：项目导航 ⬅️ | 01-链路追踪 | ➡️ 全链路流程梳理