手机号码批量去重 在业务嘴里是“把这张表洗一下”。在系统里它必须是一个任务：有 ID、有阶段、失败了知道停在哪、成功了能把三类结果再下载一次。做成同步请求——上传完浏览器转圈到超时——名单一大就废。
量级到百万时表格本身会先垮，见 百万号码批量去重。本文只谈任务怎么设计，不管你用哪种队列中间件。
一个任务里实际有五段，不要合成一个 “processing”
建议状态至少包括：已接收、解析中、规范化中、比对中、导出中、成功、失败。失败要带阶段和原因。
合成一个 processing 的后果是：值守的人只看到转圈，开发只看到“超时”，没法判断是 xlsx 太大还是库锁住了。分段耗时也是性能优化的前提，见 号码快速去重软件为什么慢。
接收文件时先记哈希和元数据
用户连点两次上传，或网络重试，会制造两个任务、两份写入。接收时记下：
- 文件哈希
- 原文件名、大小、行数（解析后再回填准确行数）
- 操作人、默认地区、任务模式（常规 / 严格）
- 规则版本
同一哈希在短时间内重复提交，应提示“已有任务”，而不是再跑一遍。这不是小优化，是防止底库被同一包写两套来源。
解析和比对必须可停、可续
50 万行在 30 万处进程被杀，是常态，不是异常。任务要按分片或游标前进：
- 已规范化的行进临时表或分段文件
- 重跑从上次 checkpoint 继续
- 成功前不要把临时结果标成正式底库写入（或写入带 batch_id，失败可按批撤回）
“失败就整包重来”在演示里能接受，在生产里会让运营不敢点重试。自建库的回滚，见 自建号码数据库系统怎么做。
文件内去重和对库去重要出两列状态，不要一个布尔值
批量结果最少：
in_file_dup：本文件先出现的行算通过，后出现的算文件内重复in_db_dup：键已在底库invalid：规范化失败
一行可以既格式异常又不该进库。不要用“重复=1/0”覆盖所有情况。导出给渠道对账时，他们要的是文件内重复；给销售停拨时，他们要的是历史重复。功能为什么要这样拆，见 手机号码去重工具开发功能。
和前台查询隔离
批量任务会打满磁盘和 CPU。同一时刻有人在页面上查 1 个号，不能跟 80 万行导入抢同一条写路径。
常见做法：导入走 worker，查询走索引好的主路径或只读副本；任务有并发上限，超出排队。多人同时用时的权限和队列，见 号码去重复软件如何多人查重。
导出是任务的一部分，不是事后手点数据库
任务成功后应留下可重复下载的产物：通过 / 重复 / 异常三份，或一份带状态列的明细。下载权限跟角色走，当次结果可以给运营，底库不能给。
不要要求业务“自己到服务器上拿 csv”。那不是系统，是脚本。
制作时两个容易偷懒的点
进度百分比按文件大小估。 xlsx 解析和后面比对的时间不成比例，进度会在 20% 停很久然后突然跳完。按行数和阶段报更老实。宁可慢，不要假进度。
成功后立刻删原文件。 出了误判你需要对照原单元格。原文件按保留期存放（对象存储即可），过期再删。审计要能回答“这批原始文件是哪一份”。
第一版任务模型可以很小
不必上复杂工作流引擎。一张任务表 + 一个 worker 循环 + 对象存储，就能跑。等并发和地区分片真成为问题，再拆。过早引入分布式任务框架，规则版本和批次回滚会更难讲清楚。系统能力对照见 在线号码去重系统应具备哪些能力。
常见问题
批量去重能不能做成纯脚本，不做任务表？
自己偶尔跑可以。团队用、要回看、要权限、要对账，就必须有任务记录。脚本的日志在服务器上，业务看不见。
一条任务失败，已经写出的通过号还能用吗？
默认不能。半截结果当最终，渠道会按错误名单触达。要么整批撤回，要么明确“部分完成”并标出最后一行游标，让人决定要不要续。
哪里可以看到任务状态长什么样？
在线 Demo 走上传和结果。要在自己环境按任务跑正式名单，联系 Telegram @imchat。功能入口：核心功能。