先把问题解决
明细表可以按“订单号＋行号”判断同一行，但必须先核对业务规则。表格批处理按所选字段的完整值组合比较，重复时保留先出现的记录；任一键字段为空的行会保留。本例六行按订单号得到四行，按订单号加行号得到五行，仍需人工处理冲突内容。
用六行小样本暴露误删
以下是自编练习，不是真实订单。把列名保留为 Order、Line、Item，六条记录按表中顺序保存为 CSV。编号是标识文本，不是可求和的数量。第三行故意把商品描述写成 corrected，用来观察保留的是首条还是后出现的版本。
Microsoft 的重复值说明建议先查看重复项、保留原数据，并根据列选择删除重复值。这支持“先确认规则再删”的做法；下文关于空键和保留顺序的行为专指本站表格批处理，不能据此推断所有表格软件的行为。
| Order | Line | Item |
|---|---|---|
| O-01 | 1 | Red mug |
| O-01 | 2 | Blue mug |
| O-01 | 1 | Red mug corrected |
| O-02 | 1 | Plate |
| （空） | 1 | Unknown A |
| （空） | 1 | Unknown B |
先确认表头和记录单位
在表格批处理上传副本，确认选中的数据源、表头映射和预览。先不选去重字段生成一次合并结果，输入与输出都应为六行。若导入第一步就少行，先排查解析和数据源选择，不要把缺行解释为去重成功。
多个文件的列名不一致时，先按表头合并检查方法确认同一字段映射到同一列，再选择去重字段。修改映射或数据源后要重新查看去重设置；不要假设旧勾选仍然代表新的表结构。保留来源列便于找到被保留记录的原文件和行号。
对比单列键与组合键
展开“可选：按字段去重”，先只勾选 Order，再点“生成合并预览”。这轮会留下 O-01 的第一项、O-02 的一项和两条空编号，总计四行。O-01 的 Blue mug 并不是重复商品行，却因为只比较订单号而丢失，说明键选得过粗。
随后增加 Line，保持输入顺序不变，再生成一次。此时 O-01/1 的第三条被识别为同键，O-01/2 得以保留，结果为五行、移除一条。检查 Red mug 是否仍是首条文字；工具不会因为另一条含有 corrected 就自动判断它更新、更正确。
同一输入，两个不同的判断单位
只选 Order：4行；O-01/2 丢失
选择 Order＋Line：5行；保留 O-01/2
| 设置 | 结果行数 | 需要解释的变化 |
|---|---|---|
| 不去重 | 6 | 保留完整练习输入 |
| Order | 4 | 误丢不同Line的同订单商品 |
| Order＋Line | 5 | 首条O-01/1保留，两条空Order均保留 |
空键、大小写和更新记录怎样处理
键字段任一值为空或仅含空白时，本工具保留这一行，不把所有“未知订单”合成一条。因此五行结果中的 Unknown A、Unknown B 都应在。空编号需要后续补齐或单独核查，不能把保留下来理解为它们已经确认互不重复。
非空键按原始文本值比较，不做大小写、空格或近似拼写的自动归一化。若业务把 O-01 与 o-01 视为同一订单，先明确规则并保留原值再清理。若目标是“保留最新”，需要可信时间字段和冲突处理规则；当前的“保留首条”不能替代这种判断。
把冲突交给明确规则
同键、内容不同
列出冲突双方及来源，确认谁有权决定正确版本，再整理待合并输入。
键缺一部分
保留待查队列，补齐依据后再运行，避免把未知值当作共同身份。
视觉相同、文本不同
先记录统一大小写或空格的规则；清理后再检查是否产生新的同键冲突。
导出后重新核对五条记录
点击导出 XLSX，使用新的文件打开。不要只看到“移除1条”就完成验收：应有 O-01/1、O-01/2、O-02/1、空订单的 Unknown A 和 Unknown B，且首条仍是 Red mug。来源列应能把它追溯回输入，而不是指向被移除的 corrected 行。
这类导出用于整理值，不应假设原工作簿的公式、样式和复杂布局都原样保留。后续还需按部门或订单分组交付时，再阅读按字段拆表与清单验收，检查分组行数之和，而不是在本轮同时加入多个操作。
本例验收清单
- 原始副本六行完整保存，未直接覆盖。
- 去重字段为Order和Line，重新生成后的结果为五行。
- Blue mug、两条空编号都存在，O-01/1保留首条。
- 实际XLSX的五行与来源列和预览一致，冲突项另有处理结论。
用门店样例复算完整处理流程
下方的门店样例用于练习从合表到复盘的完整流程，不替代上文的重复记录案例。8 条样例记录的编号各不相同，正确处理应保留 8 条，不能因为门店名称相同就删除交易。先按金额字段转换数字、去除门店两端空格，再检查清洗前后的编号集合和来源行。
清洗结果应保留全部 8 个原始编号。按 2026 年 10 月 1–7 日与 10 月 8–14 日求和后，虚构样例为 3,000 与 3,600，增长 20%。总额相符仍不能代替逐行核对：删去一条记录并加入同额记录，也可能得到相同合计，因此还要对照来源与编号集合。
去掉一行之前，给它写一条处理理由
本页独立订单练习包保留上文六行顺序，并提供两种规则的预期CSV和处理账本。先用未去重结果做基线，再分别只选Order、选择Order＋Line；不要连续在已删过的结果上实验。包内的答案文件用于比对，不能和原始orders.csv一起合并。
O-01/1的第三条写了corrected，但样本没有更新时间或权威状态。因此五行是“按完整键保留首条”的算法答案，不是“正确业务版本已确定”的答案。真实业务若决定保留第三条，需要有版本证据、明确优先级和逐行确认；不能通过随手交换文件顺序来暗中改变取舍。
| 源数据行 | Order＋Line判断 | 保留首条结果 | 仍需做的业务决定 |
|---|---|---|---|
| 2：O-01 / 1 / Red mug | 完整键首次出现 | 保留 | 与第4行比较版本证据 |
| 3：O-01 / 2 / Blue mug | 另一条商品行 | 保留 | 不能只因Order重复而删 |
| 4：O-01 / 1 / corrected | 完整键重复，文字不同 | 移除 | 先核实corrected是否可信 |
| 5：O-02 / 1 / Plate | 另一个完整键 | 保留 | 正常记录 |
| 6–7：空Order / 1 | 键不完整 | 两条都保留 | 补编号或单独待查，不视为同一单 |
别把“键相同”“整行相同”“版本更新”混在一起
按Order＋Line去重回答的是“这个订单行键出现过没有”。按所有业务列比较回答的是“内容是否逐格相同”。选择最新版本则需要时间、版本或状态规则。三者可能得出不同结果：本例两条O-01/1的Item不同，整行去重会全部保留；组合键去重会保留首条；没有版本证据时无法判定最新。
交付时记录输入6行、保留5行、按规则移除1行、仍有2行空Order待查，并标出一个同键文字冲突。不要写“已清除全部重复和错误”。接着做长编号与文本类型核对，确认业务键在导入和导出之间没有变化。
可以亲自复算的示例
两份虚构门店 CSV，共 8 条记录。统一表头并清洗金额后：10 月 1–7 日合计 3,000，10 月 8–14 日合计 3,600，增长 20%。这组样例没有需要删除的重复记录。
压缩包内附字段映射、日期范围与预期合计。文件均为虚构数据，无需账号。
常见问题
组合键越多就越准确吗？
不一定。加入可变化的描述列，可能让同一业务记录的两个版本不再被识别为重复。应选择能定义记录身份的字段，而不是为了让移除数量好看而增加列。
后出现的记录会覆盖首条吗？
不会。当前工具对完整同键记录保留先出现的一条。需要保留最新版本时，先确认可信时间和业务冲突规则，再整理输入，不能依赖文件名或corrected字样。
空订单为什么没有去掉？
任一所选键为空的行会保留，避免把未知身份误合并。它们依然需要人工核查与补齐；保留并不等于证明这些记录唯一。
参考资料与延伸阅读
按步骤开始处理
进入对应工具，预览处理结果，检查导出的文件。
