【免费下载链接】freehirefreehire — the open-source search engine for job seekers项目地址https://gitcode.com/GitHub_Trending/fr/freehire点击查看免费下载freehire 是一款开源的职位搜索引擎the open-source search engine for job seekers它每天索引数十万条职位却有一条铁律从不硬删除任何职位。一个职位是否活着只由jobs表里的closed_at一列决定——closed_at IS NULL即视为开放。写入这个字段的不是一个人而是六个各管一段的自动化机制像接力一样覆盖职位下线的所有场景。为什么选择软关闭而不是删除对用户来说删除是最干净的做法但对搜索引擎来说删除是危险动作链接不能断职位详情被外链、被收藏、被邮件引用过。freehire 的规则是——列表、搜索、公司页都过滤closed_at IS NULL但详情页仍然服务已关闭的职位历史链接永远不 404。可以免费重开爬虫是有罪推定偶尔会误判。职位一旦被错误关闭下一轮爬取把它再次看到时upsert 会自动清空closed_at将其重开见 TouchJob 中的closed_at NULL逻辑。删除的行则永远找不回来。数据可以审计freehire 曾在早期有一个cmd/prune命令批量硬删不属于 IT 职位板的条目后来目录扩展到 IT 之外就退役了相关记录归档进独立的pruned_jobs表。项目甚至明确拒绝让closed_at兼职表达被清理的含义——迁移 0071_jobs_closed_reason.sql 的注释写道复用一列表达两种含义会腐蚀三个机制已经在写的信号。一句话总结关闭是状态删除是事故。六个机制逐一拆解这六条路径互不重叠五个基于证据关闭一个基于猜测关闭前四个盯的是单个职位后两个盯的是整块看板的长期病史。完整约定见 docs/agents/job-lifecycle.md。机制一ingest 清扫——48 小时没再见就关unseen这是主力机制跑在每次爬取之后。爬虫每次成功看到一个职位都会刷新它的last_seen_at时间戳清扫任务CloseUnseenJobs位于 cmd/ingest/随后把该来源下超过 48 小时没再出现的职位标记关闭。它故意保守只关本次运行真正爬到的公司的职位宁可漏关也不误关。若单条UPDATE因坏行失败还有逐行兜底CloseUnseenJobByID把整批继续走完。机制二liveness 探针——连续两次过期才判死probe_expired有些职位手动导入、URL 解析进来的不在任何爬取范围内机制一永远够不到它们。cmd/liveness工作器会直接抓取这些孤儿职位的 URL用纯启发式规则HTTP 404/410、跳转到列表页、多语言已关闭措辞等判断页面状态连续两次读到expired才关闭liveness_strikes计数器一次健康探测即清零。它只凭正面证据行动且从不主动重开——倾向于少关。机制三流式源的自我关闭feed_removed像jobtech瑞典公共就业局这类提供增量变更流的来源会在订阅流里直接推送该职位已下架事件。ingest 管道收到Removed: true后调用CloseJobBySourceExternalID按(source, external_id)精确关闭。这类来源因此被排除在机制一之外——它们的流只报告变化的职位靠last_seen_at反而会把仍在线的职位误关。机制四年龄规则——唯一的猜测式关闭expired这是六个机制里唯一没有证据可查的telegram来源的职位 URL其实就是那条帖子本身招聘结束后帖子依然在线任何探测都读不出已下线。于是 freehire 采用 45 天年龄规则超过 45 天直接按expired关闭CloseStaleUnsignalledJobs跑在 cmd/liveness/ 中。正因为它是猜测项目刻意把来源列表交给调用方显式传入——新数据源不可能不知不觉滑进年龄关闭。也正因如此它被单独打标让误关的 46 天仍在招人的职位可以作为一个集合被找回。机制五僵尸看板兜底board_unreachable机制一/三都很保守但有一个没有上限的盲区一块看板如果彻底死了上游退役、封禁我们、迁移域名它的职位会永远开放着却没人能证实它们还存在。cmd/close-chronic-boardscmd/close-chronic-boards/读取board_health表——每次爬取的成功/失败史都记录在这里——对连续 60 天CHRONIC_BOARD_CLOSE_WINDOW_DAYS无法触达的看板整体关闭closed_reason board_unreachable见 0147_jobs_closed_reason_board_unreachable.sql。执行前还会在 SQL 语句内部二次校验看板健康度防止读取到关闭之间的时间窗口里看板恰好复活。机制六空 Feed 兜底feed_empty这是机制五的镜像盲区看板能访问、每次都返回 HTTP 200但里面一条职位都没有。真实事故中曾有 107 条职位对着一个已清空的 Feed 开放了一个月。board_health.last_yield_at记录看板最后一次真正产出职位的时间。同一个工作器的第二遍扫描对可达但 30 天EMPTY_FEED_CLOSE_WINDOW_DAYS零产出的看板整体关闭打上feed_empty标签0159_jobs_closed_reason_feed_empty.sql。 除以上六条自动化路径外还有两类人工关闭审核员处理举报时的moderated以及雇主在自助面板下架自己发布职位的employer_closed0175_jobs_closed_reason_employer_closed.sql——不同角色、不同信任级别用不同标签区分。closed_reason给每次关闭盖一个责任章2026 年的迁移 0071_jobs_closed_reason.sql 为jobs表增加了closed_reason列用数据库 CHECK 约束限定其取值并且每次关闭必须写明是哪个机制写的标签写入者含义unseeningest 清扫48h 没再从看板上看到probe_expiredliveness 探针连续两次页面探测过期feed_removed流式来源变更流报告职位下架expired年龄规则超过 45 天无证据可查board_unreachable僵尸看板兜底看板 60 天无法触达feed_empty空 Feed 兜底看板 30 天可达但零产出moderated/employer_closed审核员 / 雇主人工关闭这一列的价值在注释里说得很直白一条规则如果证明过于宽泛现在可以单独被审计、单独被撤销。存量行统一保留未知——事后猜测给历史数据贴标签等于发明历史。重开时标签会被清空有集成测试 job_close_reason_integration_test.go 守着这条契约避免一个复活的职位还挂着上次的死亡证明。值得留意的是迁移 0071_jobs_closed_reason.sql 特意用了no-transactionNOT VALID拆分约束的做法——生产库jobs表约 660 万行普通加约束会长时间持有排他锁排队在后面的每个读者都会一起卡死。关闭之后搜索摘除与免费重开职位关闭后要立刻从搜索结果里消失否则会出现搜到已下线职位的尴尬。freehire 的答案是search_delete_outbox删除队列0113_search_delete_outbox.sql原子性每条关闭 SQL 都用 CTE 把UPDATE ... RETURNING id的结果直接灌进删除队列——关了就入队回滚了就什么都不入队。无外键删除队列刻意不建指向jobs的外键否则职位关闭 → 入队 → 行被清理 → 队列入被级联删掉会让脏文档永久滞留在索引里。生产环境实测每天约 19,827 条职位关闭若不等全量重建这些职位会在索引里多活 3 小时。而重开完全是免费的职位重新出现在爬取结果中时upsert 的ON CONFLICT分支清空closed_at顺便重置 liveness 失败计数下一轮搜索重建时它自然回到结果里——无需任何人工介入。小结freehire 的软关闭设计可以浓缩成三句话一列定生死closed_at IS NULL即开放六个机制清扫、探针、流事件、年龄规则、双兜底分段协作任何一条路径误判都能被下一次的再出现自动纠正死亡必须有名字closed_reason让为什么关永远可审计、可单独回滚连猜测式关闭都被明确打标永不硬删关闭的职位保留public_slug、富化数据与用户收藏引用链接永不断裂重开只是清一个字段。这套用状态代替删除、用标签代替遗忘的生命周期设计值得任何管理海量时效性数据的开源项目参考。赞分享【免费下载链接】freehirefreehire — the open-source search engine for job seekers项目地址https://gitcode.com/GitHub_Trending/fr/freehire点击查看免费下载相关推荐终极指南如何用Fay Agent打造你的24小时智能管家终极指南如何用Fay Agent打造你的24小时智能管家 想象一下每天早上醒来你的智能管家已经为你安排好了一天的日程当你工作忙碌时它主动提醒你重要的会RDP Wrapper 完整指南3 步免费解锁 Windows 多用户远程桌面RDP Wrapper 完整指南3 步免费解锁 Windows 多用户远程桌面 周五晚上家里的 Windows 10 是家人追剧用的。你想远程连回去取一份文Midway 生命周期Life Cycle完全指南从应用启动到优雅关闭的六个阶段Midway 生命周期Life Cycle完全指南从应用启动到优雅关闭的六个阶段 生命周期Life Cycle是 Midway 框架中把初始化与后端微服务云原生上一篇从语言模型卷到 K 线模型金融大模型赛道现在有多拥挤下一篇如何为Android项目配置GitHub Actions CI流水线Parchment的Lint、构建与测试自动化实战创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考