Excel 一导入就重复：批量导入功能怎样约定校验、覆盖与撤回

客户、商品、库存调整、订单和员工名单，都可以放在表格里，但不能共用一套重复判断。

客户可能以内部客户编号识别，商品可能以商品编码和规格识别，订单则可能以来源渠道与外部订单号识别。名字相同不一定是同一个客户，电话变化也不一定意味着新增客户。

导入前要问清三件事：对象的识别依据是什么，这个依据是否稳定，判断是否需要限定公司、门店或渠道。同一个编码在两家公司分别使用时，不能因为文字一样就合并。

还要区分主数据和业务流水。更新商品名称与重新录入一笔库存增加，对业务的影响不同。后一种如果重复执行，数量可能被增加两次，不能只看后台有没有多出一行。

开发方可以帮助设计识别方式，业务方仍需确认它是否符合现实。一张干净样表不够，最好准备几条同名、换手机号、跨门店和历史停用的记录，一起判断它们到底是什么关系。

业务人员最容易遇到的麻烦，是表格看起来没问题，系统读到的值却不符合预期。

编号需要保留前导零，日期需要固定解释方式，金额需要明确单位。单元格为空，可能是“不修改原值”，也可能是“主动清空”，这两种意图应该有不同表达。

模板还应带版本说明。系统新增必填字段后，旧模板能否继续用，需要有明确规则。不能让员工拿着半年以前的表格反复试错，再由技术人员猜测他们用了哪个版本。

首期可以只支持一种文件格式和固定列顺序，也可以允许用户映射列。两种方案工作量不同。无论选择哪种，都要把“不支持什么”写进模板说明和错误提示。

直接上传、立即入库，操作很快，误操作也很快。对会覆盖原数据的导入，先预览再确认通常更容易控制风险。

预览需要显示新增、更新、跳过和失败的数量，并让用户查看关键变化。例如电话将从旧值变成新值，地址是否保持，所属门店有没有变化。只展示原表格缩略图，不能证明系统理解了用户的意图。

校验最好同时考虑文件内部和系统已有数据。表格内同一个订单号出现两次，与后台已经存在这个订单号，是两类问题。需要分别提示，不能全部归为“重复”。

校验还可以分成几个层次：文件能否读取，字段格式是否正确，引用对象是否存在，以及当前业务状态是否允许修改。一个格式正确的日期，也可能落在已经关闭的业务期间。

预览结束后到正式提交前，其他人可能修改了记录。因此预览结果不是永久通行证。正式执行时仍需核对权限、记录状态和重要变化；发现冲突，就按约定拒绝或交给用户重新确认。

有的系统遇到同编号就全部覆盖，有的系统全部跳过。两种做法都可能适用，但不能藏在程序里让员工猜。

可以按业务提供明确模式：只新增；新增并更新指定字段；只更新已有记录。每种模式都说明遇到已有对象和缺失对象时怎样处理。

尤其要约定覆盖范围。销售只能更新客户联系信息，不代表他能通过表格改掉客户归属、信用额度和审批状态。页面里不能改的字段，也不应该借导入绕过去。

空值是最容易产生争议的地方。假设原记录有地址，新表格只填了电话，空白地址到底是否清空，应在确认页明确展示。如果业务确实需要批量清空，可以使用专门标记或独立操作，避免把漏填和主动删除混在一起。

还要说明同一文件里出现两个不同新值时如何处理。可以拒绝冲突行，也可以采用经确认的优先规则，但不能默认“最后一行算数”，又不给用户任何提示。

一批资料有一行错误，系统可以全部不执行，也可以执行正确行、留下失败行。应根据对象关系和业务风险选择，不能只为了显示更多“成功”就采用部分提交。

客户联系资料可以考虑逐行处理；一个必须保持完整的业务单据，表头与明细就不宜随意拆开。涉及库存、金额和关联关系时，业务确认的处理单位可能是一整单，而不是 Excel 的一行。

结果页要把成功、失败、跳过分别列出。失败原因应指出行号、字段和可改方向，例如“门店编码不存在”，比“数据错误”更容易处理。

如果允许下载错误明细，还要确认下载权限和包含哪些信息。员工处理自己导入的资料，不应因此拿到无权查看的其他门店数据。

修改后重传，也需要明确处理范围：只上传失败行，还是允许重传整个文件。后一种方式必须识别已经成功的操作，否则员工按提示再试一次，就可能把成功部分重复执行。

网络慢时，用户重复点击提交；页面超时后，用户换个浏览器再上传。文件有没有重复，与业务有没有重复，是不同问题。

系统应为导入任务保留可查询的批次记录，说明谁提交、何时提交、用了哪个模板、最终处理了哪些对象。任务还在执行时，用户能查看进度；页面断开后，也能找到最终结果。

同一批次重复提交，不应该再执行一次相同业务动作。相同文件隔几天再次上传，则可能是误操作，也可能是用户确实想更新，不能只依据文件名字决定。

首期不一定要做复杂任务中心，但至少需要稳定的批次编号和结果记录。技术上采用什么机制，由开发方决定；老板验收的是重复操作不会形成重复业务结果，失败后能够解释发生了什么。

“导错了就撤回”听起来合理，但撤回不能忽视之后的业务变化。

新增客户还没有被使用，可以按规则移除；客户已经关联订单，就不能直接删除。某个电话导入后又被销售改过，也不能无条件恢复旧值，把销售后来做的工作一起覆盖掉。

撤回前也应预览影响范围，撤回后保留操作人、原因、对象和未能处理的冲突。某些高风险数据只允许作更正，不提供整批撤回，也可以是合理设计，前提是需求与操作提示说清楚。

因此，报价里的“支持撤回”，要写成有条件的能力。需要保存哪些历史值、保存多久、怎样处理冲突和关联记录，都影响开发与存储成本。

只用十条整齐数据试一次，很难发现日常导入的问题。可以准备一份脱敏样本，包含正确行、重复行、空值、错误编码和已经存在的记录，事先写下预期结果。

至少验证：同一文件内部重复与后台重复能否区分；编号是否保留约定格式；无权限字段能否被拦住；部分失败后重试是否安全；重复提交是否产生重复业务；撤回遇到后续修改是否提示冲突。

还要约定文件大小、行数、任务耗时和超限提示。OWASP 文件上传指南强调文件类型校验、大小限制和授权等基础控制。这些要求保护上传入口，业务重复识别与撤回规则仍然需要单独设计。

导入后的列表、详情、报表和导出结果也要核对。数据进了数据库，不代表员工在每个页面都能看到同一种解释，可以结合管理系统报表口径与字段一致性检查。

在软件项目验收资料中保留模板版本、处理规则、测试样本和批次结果，员工以后才能知道该怎么用，接手团队也能解释历史操作。

华茂思捷提供企业管理系统开发与技术顾问服务。如果你准备增加批量导入，可以带上实际使用的表格和几条重复、覆盖、撤回的例子，联系我们把操作入口变成可核对的业务功能。

• OWASP：File Upload Cheat Sheet，用于核对上传类型、大小、授权和文件处理的基础要求。

文中的客户、订单和字段变化是需求示例，没有对应真实客户事故；本文没有执行线上导入或撤回，也不承诺任何系统能在任意后续操作之后恢复整批数据。