JobMatch：岗位表合并了，报名人数却可能跟错岗位

JobMatch 后来收窄为一个浏览器里的岗位表筛选工具：读取岗位表和报名统计，按条件筛选，再导出结果。旧目录保留过后端与其他入口，当前入口不需要把这两张表发送给项目后端。

我与 AI 编程工具围绕这个使用流程推进实现。这里主要回看 2026 年 4 至 5 月的版本，同时记录本轮源码复核发现的差异。没有招录资格认定或录用结果数据。

第一关是找到真正的表头

表格前面可能有标题和说明，列名也可能写成“岗位代码”“职位代码”或更短的“代码”。若固定读取第一行或固定列号，解析出的对象可能从一开始就错位。

当前实现会在前几行中寻找包含多个已知列名的表头，再通过同义词定位字段。它适配了一些输入形态，也仍有范围：报名统计读取第一张工作表，表头搜索范围有限，复杂合并表头与新列名需要继续核对。

因此，导入后的行数只是检查入口。还需要抽样看岗位名称、单位、代码和报名人数是否保持对应。

旧 README 和实际关联规则并不完全一致

旧说明写过“代码加岗位名称复合关联”及“补前导零”。本轮核对 joiner.js 后，能确认的规则是：优先用代码，没有代码时回退到单位与岗位；标准化会去空格、统一全半角和大小写，没有补齐前导零。

所以 0123 与 123 仍可能不匹配。同键统计行还会在 Map 中由后写入的覆盖前一条，当前没有给出重复键冲突处理。未匹配项显示为零值时，必须结合 hasStats 判断，不能直接读成“没有人报名”。

这部分没有在本轮修复。我把差异写出来，避免从功能介绍推出已经实现的保障。后续应先保留未匹配和重复键样本，再决定何时允许自动合并。

清空表单，也要重新取得默认值

历史复盘还记录过默认对象被响应式状态污染，导致清空后仍不干净的问题。改进方向是用工厂函数创建新状态，再重新挂载筛选组件，避免依赖整页刷新。

浏览器内处理减少了服务端接触文件的范围，却不能推成“零隐私风险”：本地存储、共享设备和导出文件仍要由使用者管理。筛选结果也只是整理线索，最终报考条件仍需回到原公告核对。

本文依据固定版本关联实现与本地源码，未重新运行真实表格或测试。下一步最小验证应覆盖前导零、重复代码、无匹配和多工作表，先让关联可核查，再讨论扩大筛选能力。

JobMatch: a successful spreadsheet import can still join the wrong records

JobMatch narrowed to a browser-based tool: read job and registration spreadsheets, filter them, and export results. Older directories retain other approaches; the current workflow does not require sending these sheets to the project’s backend.

I worked with AI coding tools on that flow. This article revisits the April–May 2026 version and adds findings from the present source review. There is no evidence of official eligibility determination or hiring outcomes.

Find the actual header

Titles and instructions can precede the header, and equivalent columns have different names. The implementation searches the first few rows for multiple recognized labels, then maps fields through synonyms.

That supports some formats, with limits: statistics use the first worksheet and a bounded header search. Imported row counts cannot establish that units, codes, and applicant counts align. Samples need inspection.

Check the implementation behind the README

Earlier documentation claimed composite code-and-name joins and restored leading zeros. The current joiner.js instead prefers a code, falling back to unit and position when no code exists. It removes spaces and normalizes width and case, but does not restore leading zeros.

0123 and 123 can therefore remain unmatched. Repeated keys overwrite earlier rows in a Map, without explicit conflict handling. An unmatched row also carries zero values, so hasStats matters when interpreting them.

I did not fix these issues during article writing. The useful next step is to retain unmatched and duplicate-key examples before expanding automatic merging.

Reset state and privacy claims carefully

Historical notes also describe a shared-default-object reset bug. Fresh state from a factory and remounting the filter component address the reset path without reloading the page.

Browser processing reduces server exposure, but local storage, shared devices, and exports still matter. Filtering also provides leads rather than official eligibility decisions.

This account reviews the fixed-version join implementation and local code without rerunning real spreadsheets. Leading zeros, duplicate codes, missing matches, and multiple worksheets are the next focused verification cases.