招聘会官网二期，报名那套一期已经跑顺了，这次要处理的是简历。
重复长什么样
一场活动收了 2000 多份投递。翻数据的时候发现几类重复：
- 同一个人投了 3 个岗位，填了 3 次，手机号一样。
- 有人先传了一版 PDF，半小时后又传了改过的一版，两个文件都在。
- 还有一批姓名相同、手机号不同的，是真不同的两个人。
所以按姓名去重肯定出事。最后定的主键是手机号加邮箱，两个都为空的才退回到姓名加学校，并且标成「需人工确认」，不自动合。
文件怎么合
简历文件本身按内容算 SHA-1，哈希相同的只存一份，投递记录都指向它。不同版本的 PDF 不覆盖，按上传时间排，后台默认展示最新一版，旧版折叠在下面，HR 想看能点开。
第一版我们直接把旧版删了，被 HR 拦下来，说有人面试时会问「你上一版怎么写的」。留着，占不了多少空间。
待确认那张表
自动能判的自动合，判不了的进一张表：手机号相同但邮箱不同、邮箱相同但手机号不同、姓名加学校撞了但联系方式对不上。那次剩了 40 多行，HR 两天内核完。
后台给了个「合并」按钮，合并前把两条记录并排显示，哪条留、哪条归档、谁操作的，全写日志。没做自动合并，这种事错了不好追。
那 40 多行待确认，HR 怎么核的
待确认表里最费时间的是「手机号相同、邮箱不同」那一类，一共 19 行。有的是换了公司邮箱，有的是填了配偶的，还有两行是同一个人故意投了两个不同岗位、怕被看出重复。HR 没合并，标成「同一人多投」，面试时照样两个岗位都通知，但只算一份简历。
「姓名加学校撞了、联系方式对不上」那类有 8 行，最后确认是 3 组同名同校的不同人，另外 2 行是同一人换了手机号。自动判断在这类上最不可靠，所以我们从一开始就没让它自动合，只排序、只并排显示。
合并按钮的日志后来真用上一次。有个候选人说自己的投递记录少了，翻日志看是 HR 上周合并过，合并前的两条都还在归档里，点开就找着了。要是当时硬删了，这就说不清。
文件那点空间
有人担心留着旧版 PDF 会占地方。算过：2000 多份投递、重复版本不到 200 个，平均一份 300K，加起来 60M 不到。跟「面试时能调出上一版」比，这点空间不值一提。SHA-1 去重挡掉的是完全相同的文件，改过一个字的还是各存各的，这正是我们要的。
手机号那列
导出把手机号设成文本格式，是踩过两次之后才写进模板的。第一次 HR 打电话发现号码变成 1.38E+10，第二次更隐蔽，11 位末尾全变成了 0，因为 Excel 只存 15 位有效数字。设成文本之后，第三版导出再没收到过这类反馈。
那 9 列后来加过一列「来源渠道」，是客户市场部要的，加完导出脚本没动，只多取了一个字段。那份 40 多行的待确认表，HR 核完导出留了档，文件名带「已核」，后来再没出现过需要自动合并的场景。
导出
按岗位分 sheet，一个岗位一页，每页固定 9 列：姓名、手机号、邮箱、学校、学历、投递岗位、简历版本、投递时间、状态。HR 各自拿自己那几页，不用在 2000 行里翻。
有个细节：手机号列设成文本格式，不然 Excel 会把 11 位数字显示成科学计数法，HR 打电话时得一个个改回来。这个坑踩过不止一次。
3 月 7 号
上线当天导入历史数据，跑完预览页跳出 6 行「联系方式都为空」，是早期一批没做校验时收的。手工补了。
后来客户加了一个「按学校筛选」的下拉，改动不大。导出那 9 列没再动过。
