数据导入重复处理，先要回答两条记录为什么被认为是同一个对象，再决定跳过、覆盖还是合并。名称相同不一定重复，名称不同也可能是同一对象更名。判断依据不清楚，后面再精细的确认框也无法防止改错记录。
重复处理应在写入前展示识别规则与关键差异。用户需要知道文件中的哪一条匹配站内哪一条，哪些值会改变、哪些不会改变，以及处理结果怎样追踪。导入的目的如果只是新增，就不应默默把重复项当作更新任务执行。
重复依据应对应业务身份，不只比较显示名称
先由业务负责人确认每条记录代表什么对象，以及能用于识别它的稳定信息。产品编码、业务编号或经过确认的组合条件，都可能适用；具体选择依真实数据决定，不能为所有对象套一个名称或手机号规则。
用于匹配的字段还要确认格式含义。前后空白、字母大小写、分隔符或前导字符是否影响身份，需要按规则定义；不能为了让重复数量更少而随意标准化，也不能让用户在界面上看到相同内容，系统却按未说明差异另建记录。
有外部来源时，来源标识可能只在其本身范围内唯一。两个来源使用相同编号，不一定是同一对象。识别规则要能说明来源与站内身份之间的关系，不把一个外部编号直接当成全系统通用身份。
同一文件内部的重复，与文件和既有记录重复，也要分别检查。文件里两行指向同一对象但值不同，若只查站内是否存在，就可能在本次导入中反复覆盖。预检应覆盖整个待处理文件，展示这些冲突如何进入后续决策。
匹配规则本身更改，也应给出版本与适用范围。过去按一个组合字段识别，今天改为另一组合，重试旧文件时可能得到不同对象关系。先核对历史处理怎样衔接，再采用新规则，不让规则变化把已成功记录变成新的未匹配数据。
无法确定身份时，采用待核对状态，不强行选择一条相似记录。可以给审核者查看必要识别信息和来源，按真实分工确认。匹配越模糊，越不适合默认进行不可预期的更新。
让用户看到旧记录、新内容和会变的字段
预检摘要可以先说明新建、重复、冲突与无法识别的数量，再按实际对象查看详情。匹配详情至少包含文件位置、站内对象身份、采用匹配依据和关键差异，不只写“第十行重复”。
多个站内对象都匹配同一输入时，单条匹配结果不够用。应说明身份存在歧义，进入核对而不是任意取第一条。界面可以提供必要对象信息帮助负责人判断，但不能在这种情况下默认覆盖，让一个模糊规则改变不可预期的记录。相关操作可参阅《SaaS 后台表格为什么越做越难用？数据表真正的问题不是“信息太多”，而是任务没有优先级》。
差异展示优先支持决定。值相同的重复项可以简洁说明无需改变；值不同的项展示旧值与新值，并解释候选动作影响。长文本或附件可以分层查看，不把每条完整数据全部铺开，使关键变更反而难找。
空值要单独定义。文件中的空白可能表示没有提供新信息，也可能表示要求清空已有值；两种结果不同，不能由导入工具自行猜。字段规则应说明采用哪种含义，更新预览也要体现是否会清空。
某些字段由站内流程维护，例如审核状态、负责人或历史记录，不一定允许外部文件覆盖。展示变化时按真实权限和规则区分可更新、保持原值与需另行处理，避免整行覆盖把业务关系一起改掉。
来源较旧时也不能只凭上传时间将它认成最新。新上传文件可能导出自旧系统快照，应核对数据形成时间与适用范围。处理方案需要反映真实资料关系，不让“最后上传者获胜”成为未经确认的业务政策。
三种动作各自承担不同任务
跳过适合不希望改变既有对象，或者本次仅新增的任务。它保留旧记录，也意味着文件中的新值不会被采用。界面说明跳过数量和原因，不能把跳过写成已更新成功，让用户误以为新内容生效。
覆盖适用于明确需要用新来源替换允许更新字段，并且采用范围已经确认的情形。需要说明覆盖整条还是特定字段，空值怎样处理，以及关联内容是否受影响。不可只给一个“覆盖重复”选项，却让用户不知道会改掉什么。
合并适用于存在可解释的字段组合规则，例如只补缺失信息或合并允许的标签。它不是系统替用户判断哪个值更好。相互冲突的关键字段仍需要采用规则或人工确认，不能用“智能合并”掩盖未知决定。
一个批次可以按不同对象采用不同处理，但选项应控制在能解释的范围。如果规则复杂到每行都必须重新猜，先处理资料问题或拆分批次，再导入。操作自由并不必然带来可靠结果，清楚默认与影响更有价值。
新增任务的默认应遵循其目的。没有明确更新授权时，先预检并拒绝或跳过重复更符合新增边界；需要更新的任务另行确认采用方案。哪种策略适用，由业务与实现共同决定，不把任意覆盖当成导入的自然行为。
确认方案后，记录每条实际处理结果
导入确认应对应一个确定的文件、规则与预检结果。预检之后改了文件、匹配条件或处理方案，就应按实际能力重新核对，不能沿用旧摘要。用户需要批准的是本次真实采用范围，而不是前一次相似文件。
预检到执行之间，既有记录也可能改变。实施应按已确认的冲突处理规则判断实际写入，结果反馈说明哪些与预期不同。界面不能把预检预计成功数直接当成执行成功数，最终以实际记录为准。
结果明细可以包含文件行或身份、站内对象、实际动作、改变字段及失败原因。保留来源与批次关系，方便后续核对。只是记录“导入成功”，无法说明重复项是被跳过、更新还是另建。
部分成功时，成功、跳过、冲突与失败分别列出，并给能够继续处理的范围。用户修复后重试，要避免再次创建已经成功的新对象；具体防重复能力由实现确认，界面说明再次采用什么身份和规则。
没有撤销能力就不提供保证恢复的文案。可以记录变更前后与处理关系供核对，是否能够恢复由实际数据和后续流程决定。高影响覆盖在写入前需要足够确认，不能把“出错再撤销”当成默认安全网。
用小批可辨识样本验证规则，而不是拿正式库碰运气
准备两条名称相同身份不同的记录、两条名称不同身份相同的记录、文件内部重复、空值冲突和关联字段变化等样本。每条写清预期匹配对象与动作，使用构造数据在受控环境核对。
先查看预检是否能解释这些关系，再执行已经确认的小批次，检查实际记录。预检发现重复不代表处理结果准确，只有最终对象、字段和明细对应，才说明方案落实。测试范围可以小，但需要覆盖真实规则边界。
重试同一批样本，核对已成功对象不会因重试身份失效而新增；修改一条待处理数据，再查看是否只按预期范围改变。一次成功导入只能证明正常路径，重试才能检查重复处理是否可持续。
让业务审核者根据差异预览说明自己会采用哪个方案，实施者据此核对实际影响。若双方对“覆盖”理解不同，先修正术语与字段范围，不急于进入正式批次。清楚的决策语言能减少后续争议。
完成标志是重复依据有业务身份，文件内外冲突都可见，跳过覆盖合并影响明确，实际结果与来源可追踪，重试不会无依据地另建。数据导入重复处理应让对象与变化可以解释，而不是让一个按钮决定全部数据命运。相关操作可参阅《数据导入功能怎么设计？模板、校验、进度和失败修复》。
常见问题
名称完全相同，能直接当作重复吗？
只有名称本身被确认用于唯一识别时才适用。多数业务仍需核对稳定身份或组合条件，不能因为展示名称相同就把不同对象合并。
跳过重复为什么没有采用文件里的新信息？
跳过通常意味着保持旧记录。本次如果需要采用新值，应先确认更新任务与允许字段，再选择准确方案，不能把跳过状态理解为已经同步。
合并是否一定比覆盖更安全？
不一定。合并规则不清同样可能改变重要字段。先说明如何处理相同值、冲突值与空值，再判断是否适用，不凭动作名称推断风险。
文件里重复两行，只导入第一行就可以吗？
要看两行是否完全一致及业务规则。值冲突时应预检展示，明确采用依据；第一行位置本身不证明它是正确版本。
导入失败后重新上传，怎样避免成功项再次新增？
按已确认业务身份和批次结果识别，保留成功明细，再针对待处理范围重试。具体能力需实现验证，不能只靠提示“请不要重复上传”。
链接复制成功
