开源职位扫描工具：多数据源定时采集与去重入库实践

找工作最耗时间的地方，往往不是投简历，而是每天在七八个招聘平台之间来回切换，反复输入同样的关键词，翻过一堆已经看过的岗位，还要手动记录哪些投过、哪些约面。这类重复动作占用的时间，比准备面试本身还多。

这次要聊的是一个偏工具型的开源项目：自动扫描职位、集中管理求职信息。它出现在 GitHub 快报第 412 期的推荐里，定位很明确——把分散在各个招聘渠道的岗位信息收拢到一个地方，用定时扫描代替人工刷新，用统一表结构代替截图和备忘录。

从项目定位看，它最值得关注的几个点是：支持多数据源配置、支持关键词订阅与定时任务、抓取结果统一入库并做去重、提供本地 Web 界面查看、预留接口便于对接通知渠道或自建脚本。它不是帮你"自动投递"的黑盒工具，而是把信息采集和整理这一段流程工程化，剩下的判断和沟通仍然由人完成。

这篇文章会按真实使用顺序走一遍：先看能力边界，再做环境准备，接着部署启动、配置数据源、验证抓取效果、测试接口调用，最后给资源占用观察方法和一套排查清单。

适合两类读者：正在集中求职、希望把信息收集自动化的开发者；以及想学习"定时采集 + 去重入库 + 接口输出"这套小型数据管道怎么落地的人。下面的命令和配置都以通用模板给出，实际项目目录、端口、字段名需要按仓库说明替换，不要直接照抄。

1. 核心能力速览

先给规格。需要说明的是，下面这张表里凡是涉及具体参数的地方，我都按项目定位做了保守描述，因为输入材料只给了项目标题和一句话定位，没有提供版本号、接口路径和实测数据，任何精确数字都不应该凭空写出来。

这张表里最需要强调的一点是：它没有显卡门槛。这一点和当下大量 AI 项目不同，你不需要考虑 CUDA 版本、显存够不够、50 系显卡兼不兼容。它的资源瓶颈在别的地方——网络请求频率、目标站点的反爬策略、数据库写入量和长期运行的日志体积。

从工程角度看，这类项目的价值不在于算法多复杂，而在于把"采集—清洗—去重—存储—展示"这条链路做完整了。很多人的做法是写个脚本抓一次，存成 Excel，过两天忘了更新，数据就烂掉了。一个可长期运行的工具，核心是增量抓取和幂等写入，这两点没做好，用一周就会积累大量重复记录。

另外要提前说清楚：本文讨论的所有抓取行为，都限定在个人求职用途、遵守目标站点服务条款与 robots 协议、控制请求频率的前提下。不做高频轰炸、不绕过登录与验证机制、不采集与求职无关的个人信息。这条边界必须先立住，后面的技术讨论才有意义。

2. 适用场景与使用边界

这类工具最适合的场景其实很窄但很刚需：你在一到两个月内集中找工作，关注的岗位类型相对固定，比如后端开发、数据分析、算法工程，城市锁定在一到三个。这时候每天手动刷十几个页面是纯浪费，交给定时任务跑，早上起来看一遍聚合列表就够了。

第二类适用人群是想学数据管道的人。一个完整的岗位采集项目，麻雀虽小五脏俱全：调度器、HTTP 客户端、HTML 解析、字段映射、去重指纹、数据库迁移、Web 展示、接口输出。把这套东西跑通一遍，比看十篇教程有用。你可以在这个基础上加自己的需求，比如按薪资区间过滤、按公司规模打标签、把结果推到自己的 IM 机器人。

不适合的场景也得说清楚。第一，不适合把它当成"自动投递机"。绝大多数招聘平台的服务条款明确禁止自动化投递，账号风险由你自己承担，而且批量投递的转化率通常极低。第二，不适合做大规模商业数据采集。个人求职的量级是每天几十到几百条，一旦上升到上万条的持续抓取，就涉及对方服务器压力、数据授权和合规问题。第三，不适合依赖它做唯一信息源。工具会漏抓、会因页面改版失效，人工复核仍然必要。

使用边界上有三条建议写进自己的操作规范里。一是只抓公开可见的岗位列表页，不碰需要登录才能访问的内容，不用自己的账号去做高频自动化请求。二是把请求间隔设在合理区间，比如单域名每秒不超过一次，批量任务之间加随机延时，遇到 429 或 403 立即退避而不是重试轰炸。三是采集到的岗位信息只用于个人求职决策，不转售、不公开二次发布、不用于训练商业模型。

还有一点容易被忽略：个人信息保护是双向的。你抓取的是公开岗位信息，但如果项目里包含简历管理、投递记录功能，那些数据里就有你自己的手机号、邮箱、工作经历。本地部署时要把数据库文件和数据目录放在非公开路径，接口服务不要绑定到 0.0.0.0 暴露到公网，需要远程访问就走内网或者加一层认证。

3. 环境准备与前置条件

环境这块不用想得太复杂。这类项目的技术栈大概率是 Python 或 Node.js，配套 SQLite 或 PostgreSQL，前端要么是服务端渲染的页面，要么是一个轻量 SPA。下面给的是通用检查清单，具体版本要求以仓库的依赖文件为准。

操作系统方面，Windows 10/11、macOS、主流 Linux 发行版都能跑。如果打算长期挂着定时任务，建议放在一台常开的 Linux 小主机或者云服务器上，Windows 桌面机休眠会打断调度。容器化部署能省掉大部分环境差异问题，这也是我更推荐的方式。

运行时方面，先确认语言版本。Python 项目看 pyproject.toml 或 requirements.txt 里的版本约束，Node 项目看 package.json 的 engines 字段。不要凭感觉装最新版，很多解析库对主版本敏感，Python 3.12 上跑不通的依赖在 3.10 上可能毫无问题。

bash复制# 通用环境检查，实际版本要求以项目依赖文件为准
python --version
node --version
git --version
docker --version

# 建议用独立虚拟环境，避免污染全局依赖
python -m venv .venv
source .venv/bin/activate      # Windows 用 .venv\Scripts\activate

磁盘空间要留够。采集类项目本身不大，但数据库会随运行时间增长，日志文件如果不做轮转，几个月下来能吃掉几个 G。建议单独划一个数据目录，把数据库、日志、导出文件分开放，方便备份和清理。

数据库选择上，SQLite 足够个人使用，零配置、单文件、便于迁移。但要注意 SQLite 的并发写入限制，如果你的抓取任务是多进程并发写同一张表，容易出现 database is locked。解决办法有两个：写入串行化，或者换成 PostgreSQL。个人场景下前者更简单。

端口方面提前规划。默认端口经常是 8000、8080、3000、5000 这几个，很容易和你机器上已有的服务冲突。启动前先查一下占用情况，别等页面打不开才回头找原因。

bash复制# Linux / macOS 查看端口占用
lsof -i :8000

# Windows 查看端口占用
netstat -ano | findstr :8000

最后是网络。抓取任务需要能正常访问目标站点，如果目标站点有频率限制，提前想好退避策略。代理配置这块只建议在公司内网或自有网络环境下按运维规范设置，不要用于绕过任何访问限制。

4. 安装部署与启动方式

部署路径有三条，按省事程度排序：容器启动、源码启动、一键包。一键包最省心但可控性差，容器最干净但需要理解挂载，源码最灵活但依赖问题要自己扛。下面三条都给出来，你按自己的习惯挑一条。

容器方式的核心是把配置目录和数据目录挂载进去，这样容器重建不会丢数据。注意下面的镜像名、端口、路径都是占位，必须换成仓库里实际的值。

yaml复制# docker-compose.yml 通用模板，镜像名与端口需按项目实际替换
services:
  job-scanner:
    image: your-registry/job-scanner:latest
    container_name: job-scanner
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - ./config:/app/config
      - ./data:/app/data
      - ./logs:/app/logs
    environment:
      - TZ=Asia/Shanghai
      - DATABASE_URL=sqlite:////app/data/jobs.db
      - LOG_LEVEL=INFO

这里有个细节值得说：ports 映射我写的是 127.0.0.1:8000:8000 而不是 8000:8000，区别在于前者只允许本机访问，后者会监听所有网卡。如果这台机器有公网 IP，后者等于把服务直接暴露出去。个人工具没必要冒这个风险，需要远程访问就加一层反向代理和认证。

源码方式适合需要改代码或调试解析逻辑的场景。标准流程是克隆、建虚拟环境、装依赖、复制配置文件、初始化数据库、启动。

bash复制# 源码启动通用流程，目录名与启动命令需按项目实际替换
git clone <repository-url> job-scanner
cd job-scanner

python -m venv .venv
source .venv/bin/activate

pip install -r requirements.txt

# 复制配置模板，按需修改数据源、关键词、通知渠道
cp config/config.example.yaml config/config.yaml

# 初始化数据库，命令名可能是 migrate / init-db / db upgrade
python manage.py migrate

# 启动服务
python app.py --host 127.0.0.1 --port 8000

启动之后先别急着配数据源，做一次健康检查。浏览器打开本地地址，看页面是否正常渲染；然后访问一个健康检查接口，确认后端和数据库连接是通的。这一步能提前区分"服务起没起来"和"服务起来了但业务逻辑报错"两种完全不同的故障。

bash复制# 服务可用性检查
curl -s http://127.0.0.1:8000/health
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/

# 查看启动日志，确认没有异常堆栈
tail -n 100 logs/app.log

如果项目提供了一键启动脚本，比如 Windows 下的 .bat 或者 Linux 下的 .sh，本质上就是把上面几步包了一层。用之前建议打开脚本看一眼它做了什么，尤其是会不会覆盖你的配置文件、会不会把依赖装到全局环境。看懂再点，比出问题再排查省事。

5. 数据源配置与抓取测试

这一步是整个项目能不能用起来的关键。数据源配置通常是一个 YAML 或 JSON 文件，里面定义每个站点的名称、入口地址、列表页选择器、详情页选择器、翻页规则、请求间隔。配置写错了，服务能启动，但抓回来是空数据，这比启动失败更难排查。

配置的核心思路是"每个源独立成块，能单独启停"。下面是一个结构示意，字段名必须按项目文档替换，不要直接复制。

yaml复制# 数据源配置示意，字段名与选择器需按目标页面结构实际编写
sources:
  - name: example-board
    enabled: true
    base_url: "https://example.com/jobs"
    list_selector: ".job-list-item"
    detail_selector: ".job-detail"
    pagination:
      type: query
      param: page
      max_pages: 5
    interval_seconds: 3
    fields:
      title: ".job-title"
      company: ".company-name"
      city: ".location"
      salary: ".salary"
      publish_time: ".publish-date"
      url: "a.job-link@href"

keywords:
  include:
    - "后端开发"
    - "Python"
  exclude:
    - "实习"
    - "外包"

schedule:
  cron: "0 8,12,20 * * *"

配置写完之后，先用手动单次触发验证，不要直接开定时任务。单次触发的好处是你能立刻看到输出，出问题能马上定位。如果项目提供了 --dry-run 或者 --once 这类参数，优先用它们，这类模式通常只抓取不入库或者打印而不写入，最适合调选择器。

bash复制# 单次抓取调试，具体参数名以项目 CLI 为准
python app.py scan --source example-board --once --dry-run

# 不指定 dry-run 时观察入库结果
python app.py scan --source example-board --once --limit 10

判断抓取是否成功，看三个指标。一是条目数量，抓 10 条出来至少要有 8 条以上，如果只有一两条说明选择器大概率错了。二是字段完整度，标题、公司、城市、链接这几个关键字段不能为空，空值率高说明详情页解析没命中。三是链接可访问性，随机抽三条拼出来的 URL 用浏览器打开，能跳到对应岗位页才算真的抓对了。

常见失败原因集中在三处。第一是页面结构变了，列表项从 div 改成了 li，选择器全部失效，这时候需要重新看页面源码。第二是动态渲染，列表内容由前端 JS 加载，直接请求 HTML 拿到的是空壳，需要换成接口请求或者用无头浏览器。第三是编码问题，中文字段出现乱码，通常是响应头没声明字符集，解析时手动指定 UTF-8 即可。

还有一个隐性坑：有些站点对 User-Agent 和请求头有要求，缺了某个头直接返回 403 或者一个验证页。调试时把响应状态码和响应体前 500 字符打出来，一眼就能看出是被拦了还是解析错了。这一步别省，比反复改选择器高效得多。

6. 职位去重、分类与集中管理

数据抓回来只是第一步，能不能长期用下去，取决于去重做得好不好。同一个岗位在列表页出现两次、隔天又刷出来一次、不同站点转载同一个职位，这些情况都会发生。如果不去重，跑一周你的列表就没法看了。

去重的核心是设计一个稳定的指纹。最直接的做法是对关键字段做归一化后拼接再取哈希。归一化包括去掉多余空格、统一大小写、把"北京市"和"北京"映射到同一个值、把薪资里的"万/月"这类单位统一。注意不要把发布时间放进指纹，否则每次抓取都会生成新记录，去重直接失效。

python复制import hashlib
import re

def normalize(text: str) -> str:
    if not text:
        return ""
    text = text.strip().lower()
    text = re.sub(r"\s+", "", text)
    text = text.replace("北京市", "北京").replace("上海市", "上海")
    return text

def job_fingerprint(job: dict) -> str:
    # 指纹只由稳定字段构成，不包含发布时间、抓取时间
    raw = "|".join([
        normalize(job.get("company", "")),
        normalize(job.get("title", "")),
        normalize(job.get("city", "")),
    ])
    return hashlib.sha256(raw.encode("utf-8")).hexdigest()[:16]

数据库层面配合做唯一约束，是比代码判断更可靠的兜底。写入时用 INSERT OR IGNORE（SQLite）或者 ON CONFLICT DO NOTHING（PostgreSQL），即使代码逻辑有疏漏，数据库也不会产生重复行。

sql复制-- SQLite 建表与唯一约束示例
CREATE TABLE IF NOT EXISTS jobs (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    fingerprint TEXT NOT NULL UNIQUE,
    title TEXT NOT NULL,
    company TEXT NOT NULL,
    city TEXT,
    salary TEXT,
    source TEXT,
    url TEXT,
    publish_time TEXT,
    first_seen TEXT NOT NULL,
    last_seen TEXT NOT NULL,
    status TEXT DEFAULT 'new'
);

CREATE INDEX IF NOT EXISTS idx_jobs_city ON jobs(city);
CREATE INDEX IF NOT EXISTS idx_jobs_status ON jobs(status);
CREATE INDEX IF NOT EXISTS idx_jobs_first_seen ON jobs(first_seen);

注意这里我加了 first_seen 和 last_seen 两个时间字段，而不是只存一个抓取时间。这两个字段的用处很大：first_seen 让你能筛出"今天新出现的岗位"，last_seen 让你知道某个岗位是否还挂着。如果某个岗位连续多天没有被再次抓到，大概率已经下架，可以标记为失效而不是直接删除，保留投递记录的可追溯性。

分类和状态管理是第二个容易被忽略的点。建议至少给每条记录维护一个状态机：new（新发现）、viewed（已看过）、applied（已投递）、interview（已约面）、rejected（已结束）。配合简单的前端筛选，你每天的工作就变成了"只看 new 状态"，处理完就改状态，不会重复劳动。

关键词过滤也要在入库前做，而不是入库后再删。包含词和排除词分开配置，排除词尤其重要——"实习""外包""派遣"这类如果你不想要，一定要在写入前过滤掉，否则数据库里全是噪音，后续清理成本更高。

7. 接口 API 调用与批量任务

能不能接到自己的工具链里，决定了这个项目是"一个网页"还是"一个系统"。从项目定位看，它大概率提供了本地接口，用于列表查询、状态更新和手动触发扫描。下面给的是通用调用模板，路径和字段名必须按实际接口文档替换。

python复制import requests

BASE = "http://127.0.0.1:8000"

# 查询新岗位，参数名需按实际接口调整
resp = requests.get(
    f"{BASE}/api/jobs",
    params={"status": "new", "city": "北京", "limit": 20},
    timeout=30,
)
resp.raise_for_status()
data = resp.json()

for job in data.get("items", []):
    print(job.get("title"), job.get("company"), job.get("url"))

bash复制# 手动触发一次扫描任务
curl -X POST http://127.0.0.1:8000/api/scan \
  -H "Content-Type: application/json" \
  -d '{"source": "example-board", "keywords": ["后端开发"]}'

# 更新岗位状态
curl -X PATCH http://127.0.0.1:8000/api/jobs/123 \
  -H "Content-Type: application/json" \
  -d '{"status": "applied"}'

批量任务这块要分两种情况说。第一种是批量抓取，即多个数据源依次扫描。这种任务的坑在于串行太慢、并行容易触发限流。稳妥的做法是串行加间隔，每个源之间 sleep 几秒，整体耗时换来的是稳定性。如果非要并行，就按域名分组，同一域名串行，不同域名并行。

第二种是批量处理，比如把新岗位批量推送通知、批量导出、批量打标签。这类任务的关键是幂等和可重试。每条处理结果都要落日志，记录成功、失败和失败原因，重复执行时跳过已成功的记录。

python复制import time
import logging

logging.basicConfig(
    filename="logs/batch.log",
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)

def run_batch(items, handler, max_retry=3):
    ok, failed = 0, []
    for item in items:
        for attempt in range(1, max_retry + 1):
            try:
                handler(item)
                ok += 1
                logging.info("ok id=%s attempt=%s", item.get("id"), attempt)
                break
            except Exception as exc:
                logging.warning(
                    "fail id=%s attempt=%s err=%s",
                    item.get("id"), attempt, exc,
                )
                if attempt == max_retry:
                    failed.append(item.get("id"))
                else:
                    # 指数退避，避免连续冲击目标服务
                    time.sleep(2 ** attempt)
        time.sleep(1)
    return ok, failed

接口服务的安全边界要单独提一句。个人工具的接口通常没有认证，如果监听在 0.0.0.0 且机器有公网地址，等于任何人拿到地址就能读你的求职数据、触发扫描任务。最小措施是只监听 127.0.0.1，需要外部访问时加一层带鉴权的反向代理，并在代理层做请求频率限制。

8. 资源占用与性能观察

这类项目的性能观察和大模型项目完全是两套指标。不用看显存，重点看四个数：CPU 占用、内存常驻、数据库体积、单轮抓取耗时。

观察方法很朴素。Linux 上用 top 或 htop 看进程，Windows 上用任务管理器，容器部署用 docker stats。建议在启动后空闲观察一次、抓取过程中观察一次、连续运行一天后再观察一次，三个时间点的数据对比才能看出有没有内存泄漏。

bash复制# 容器资源实时观察
docker stats job-scanner --no-stream

# 数据库体积与记录数，SQLite 示例
ls -lh data/jobs.db
sqlite3 data/jobs.db "SELECT COUNT(*) FROM jobs;"
sqlite3 data/jobs.db "SELECT status, COUNT(*) FROM jobs GROUP BY status;"

内存方面，纯 HTTP 采集加 HTML 解析的项目，常驻内存通常在几十兆到几百兆区间，具体取决于并发数和是否用了无头浏览器。如果用了 Playwright 或 Selenium 这类方案，单实例内存开销会明显上升，因为每个浏览器上下文都要占内存，这时候并发数就别开太高。

耗时方面，单轮抓取的瓶颈几乎全在网络。一个源抓 5 页、每页 20 条、每条间隔 3 秒，光等间隔就要 5 分钟。想提速的正确做法不是缩短间隔，而是减少不必要的详情页请求——列表页能拿到的字段就别进详情页，只对命中关键词的条目做二次抓取。

磁盘增长主要来自三处：数据库、日志、导出文件。日志一定要配轮转，按大小或按天切分并保留最近若干份，否则半年后一个日志文件几个 G 很常见。导出文件建议单独目录并按日期命名，定期清理。

降低资源占用的几个实操建议：把抓取频率从"每小时"降到"每天三次"，求职场景完全够用；列表页只存必要字段，详情页内容按需懒加载；数据库定期执行 VACUUM（SQLite）回收空间；给容器设置内存上限，避免异常时把宿主机拖垮。

进程残留也是常见问题。调试时反复 Ctrl+C，有时候端口没释放，再启动就报 Address already in use。养成习惯：停服务用正常退出方式，异常时先查端口占用再启动，别盲目重启。

9. 常见问题与排查方法

下面这张表覆盖了我认为出现概率最高的几类问题。排查顺序建议统一遵循"先看日志、再看网络、最后看代码"，绝大多数问题在日志里都有明确提示。

几个补充说明。关于"抓取结果为 0 条"，这是最高频的问题，八成的排查时间花在这里。我的建议是把它拆成两步看：先确认 HTTP 请求本身成功了没（状态码 200），再确认解析出了东西没（选择器命中数）。前者是网络问题，后者是解析问题，混在一起查最浪费时间。

关于"定时任务不执行"，时区问题比想象中常见。容器默认时区经常是 UTC，你配了早上 8 点，实际在本地时间下午 4 点才跑。解决办法是在容器环境变量里显式设置 TZ=Asia/Shanghai，并且在配置里确认调度器读取的是本地时间。

关于"批量任务卡住"，根因基本都是缺超时。一个 HTTP 请求不加 timeout，遇到对端不响应就会一直挂着，整批任务卡在第一条。所有网络调用都必须设超时，并且超时要短于批次的总预算，这样失败能快速暴露而不是静默挂起。

10. 最佳实践与使用建议

第一次用，别一上来就把所有数据源全开、把频率调成每小时。正确的顺序是：先用一个源、抓一页、十条数据，确认字段完整、链接可访问、指纹不重复，再逐步加源加量。这个"最小可运行配置"要保留下来，以后改坏了能快速回退对比。

目录结构建议从一开始就分清。配置、数据库、日志、导出、临时文件各占一个目录，不要全堆在项目根目录。这样做的好处是备份和迁移时边界清晰——配置文件需要版本管理，数据库需要定期备份，日志可以随时删，导出文件按需保留。

批量任务一定要有日志和失败重试，这一点前面代码里已经体现。这里补充一条：失败记录要能单独导出重跑，而不是只能整批重来。一个好的批次设计是"输入清单 + 结果清单 + 失败清单"三份文件，任何一份丢了都能从中断处恢复。

接口服务的安全设置再强调一次。默认只监听本地，需要远程访问走代理加认证；接口不要返回完整简历内容之外的敏感信息；如果项目支持多用户，务必确认权限隔离，个人工具不建议开放给他人使用。

合规方面，涉及个人信息的功能要格外小心。如果你在工具里记录了投递历史、HR 联系方式、面试反馈，这些都属于个人信息，要控制访问范围，不随意分享数据库文件，不在公开仓库里提交真实数据。使用第三方通知渠道推送到 IM 时，注意推送内容不要包含完整的联系方式。

最后是发布与商用的边界。这个项目本身是求职辅助工具，个人使用没有问题；如果想把采集结果整理后对外发布，或者做成面向他人的服务，就必须重新评估目标站点的服务条款、数据授权和当地法规要求。技术上能做到，不等于可以随便做，这条线要自己守住。

11. 总结与下一步

回到最初的问题：这个项目值不值得试。我的判断是，如果你正在集中求职，且每天花在"刷岗位"上的时间超过二十分钟，那它值得花一个小时部署一次。它的技术门槛很低，不需要显卡，不需要复杂环境，主要成本是配置数据源和调选择器。

最该先验证的功能只有一个：单个数据源的单次抓取。这一步跑通，说明网络、解析、入库整条链路是通的，后面加源、加定时、加通知都是在这个基础上叠加。这一步跑不通，别急着配十个源，先把一个源调对。

最容易踩的坑有三个。一是选择器失效，页面改版后静默返回空数据，所以一定要有"抓取条数为 0 时告警"的机制。二是去重指纹设计不当，把时间字段带进去导致重复入库，数据库很快就脏了。三是定时任务的时区问题，配置看着对，实际执行时间差八小时。

后续可以扩展的方向也不少。比如加一个简单的评分逻辑，按关键词命中数、薪资区间、公司规模给岗位打分排序；比如把新岗位推送到自己的 IM，早上直接看推送；比如加一个投递看板，用状态机管理从"新发现"到"已约面"的全流程；再比如把采集层抽象出来，同一套调度和去重逻辑复用到其他信息聚合场景。

工具能解决的是信息获取的效率问题，判断和沟通仍然要自己做。把重复劳动交给脚本，把时间留给准备面试和了解公司，这才是这类项目真正的价值所在。配置和排查的细节建议收藏备用，改数据源的时候大概率还会翻回来。